0xProject / ZEIPs

0x Improvement Proposals
Apache License 2.0
91 stars 24 forks source link

OrderSignerRegistry #84

Closed alexkroeger closed 3 years ago

alexkroeger commented 3 years ago

Summary

Add orderSignerRegistry to the NativeOrdersFeature to allow market makers using v4 orders to store funds in a contract and delegate signing to a normal Ethereum address.

Type:

CORE

Motivation

Currently, in order to market make on 0x v4, you must hold balances in a normal Ethereum address. 0x Labs has gotten feedback from market makers that it would be useful to be able to store funds in a contract to be able to more easily reuse funds for different market making strategies (e.g. on-chain quoting strategies) and to allow for more complex funds management.

Specification

We propose a new interface for specifying an address that can sign on behalf of the address that calls it:

    /// @dev Register a signer who can sign on behalf of msg.sender
    ///      This allows one to sign on behalf of a contract that calls this function
    /// @param signer The address from which you plan to generate signatures
    /// @param allowed True to register, false to unregister.
    function registerAllowedOrderSigner(
        address signer,
        bool allowed
    )
        external;

This allows the signer to produce signatures for the caller (msg.sender) of the above function. The caller can be a contract.

Signatures produced by an allowed signer will be considered valid when settling fills.

Signers will also be able to cancel orders for which the caller is the maker.

Implementation

See https://github.com/0xProject/protocol/pull/195.

Designated team:

0x Labs

Notes

The change will be spot-checked by Consensys Diligence

mintcloud commented 3 years ago

Provisional vote dates: start vote: Wednesday 21APR, 5PM GMT (10am PST) end vote: Saturday 24APR, 5PM GMT (10 am PST)

gabririgo commented 3 years ago

hey @alexkroeger V3 has custom checks for valid signatures, with 2 types for smart contracts (i.e. validity check on the smart contract or on a delegated validator smart contract). I believe gas savings led to choosing the different model proposed for v4. However, would it make sense to let smart contracts validate signatures with internally built custom methods (as is now possible in v3) or is there just no demand for this feature?

alexkroeger commented 3 years ago

hey @alexkroeger V3 has custom checks for valid signatures, with 2 types for smart contracts (i.e. validity check on the smart contract or on a delegated validator smart contract). I believe gas savings led to choosing the different model proposed for v4. However, would it make sense to let smart contracts validate signatures with internally built custom methods (as is now possible in v3) or is there just no demand for this feature?

Yes, the thinking against the static call into a user-defined validation function was to reduce the gas variability of a fill (since the validation function could contain arbitrary logic). Right now it doesn't seem like there's enough demand to move forward with support for the static call, when the feature as currently written allows for contract usage.