Smart contract interactions with guaranteed limit price

[fedgiac]

Smart contract interactions with guaranteed limit price

[fleupold]

call the function including the right settlement price without involving the solver.

What exactly does this part mean?

You mean that SC orders have a way to "guaranteed" receive the same price as the EOA signed orders, right? I was confused since these prices also rely on the solvers. However the attack would be that a solver settles signed orders with price p1 and smart contract orders with p2.

[josojo]

My fear is the attack (as I understand from @fleupold) that there is nothing preventing a solver from specifying a different price for this kind of order (by having the same token with two separate prices in the settlement).

Yes, nothing is preventing them, besides the dao rules. And in order to make the dao-rules easily enforceable, we need to know which smart contract orders are allowed to be called with arbitrary call-data and which ones not. Especially for this distinguishment, I think it is nice to have this interface defined.

But If there is another easy way to distinguish these two types of smart contract orders, I am happy to not implement this feature.

[josojo]

If we would not implement an "official interface for smart contract orders dealing with the current clearing price", how would we distinguish a smart contract order that wants to trade "all the time" and another one trading only at the current clearing price?

I think that the additional protection for smart contract orders is not significant, as it could also be enforced by the dao. Though, if we end up not implementing it, then we need another way to mark these orders.

The use-case that I could heavily benefit from the features is CMMs designed to pocket surpluses.

[nlordell]

The use-case that I could heavily benefit from the features is CMMs designed to pocket surpluses.

My fear is the attack (as I understand from @fleupold) that there is nothing preventing a solver from specifying a different price for this kind of order (by having the same token with two separate prices in the settlement). In that sense, it doesn't really offer any additional protection as the solver specifying the price as part of the encoded calldata.

[nlordell]

I think, another approach would be to have another kind of interaction that is called 3 times with the same data, pre-,mid-,post- settlement. This allows things like the CMM use case to provide funds upfront and then revert if it did not receive enough funds at the end of the settlement.

[nlordell]

Closing for now based on discussion. Additionally, SC orders can be currently implemented using something like EIP-1271 where a pre-interaction registers an order with a limit price.