Wyvern: 1st-Order Decentralized Exchange Protocol

Wyvern is a Tier 1 decentralized exchange protocol. Compared with other protocols, such as Etherdelta, 0x and Dexy, they are of order 0, that is, each order specifies the transaction of two decentralized assets.

And Wyvern changes the order to a predicate that specifies a state transition, that is, defines the order as a function that maps the manufacturer’s call, the counterparty’s call, and the order unit data to Boolean values. Any asset or any combination of assets representable on Ethereum can be exchanged through Wyvern orders.

In this way, any commands that can be expressed by simpler protocols can be expressed, and gas can be optimized to reduce useless calls. Because the components of the protocol are isolated, it is also conducive to security.

But also because the definition is too thin, it is not friendly to developers, and it is difficult to support user-level tools.

As a result, Wyvern later released version v3, which reorganized several core components of the protocol to enable users deploying Wyvern’s distributed ledger to trade freely.

The following are Wyvern’s protocol features:

Assertion registry

Order generators can check that they and their counterparties are using a valid registry.

assert calldata

Most of the logic in the order is to construct predicates on the call and reverse call. The static callback (predicate function) for each order receives all parameters for the call, counterparty call and order unit data (ETH value, timestamp, matching address) and must decide whether to allow the order to match, and if so, how much to fill.

Call

The first call is performed by the order maker through their proxy contract. Static callbacks receive all parameters, call target, call type, call data, etc., and must verify that the call is one the manufacturer is willing to perform (for example, transferring a specific asset or group of assets).

Countercall

The second call is performed by the counterparty, which is called “countercall” in the source code for convenience. Static callbacks receive all parameters, have a countercall target, countercall type, and countercall data, and must verify that the call is one the manufacturer is willing to accept in exchange for their own call (eg transferring a specific asset or set of assets).

asserted state

The static call is executed after the call (if the static call fails, the entire transaction is resumed), so it is possible to assert that a specific state has changed, rather than asserting properties of the calling data.

metadata

The metadata includes the pending order time, the pending order expiration time, the reverse pending order pending order time, the ETH transferred in the call, the current order transaction value, and the matching address.

Generalized Partial Fill

The order signs the maximum deal, the static call returns a uint that specifies the updated deal value if the order matches. The current execution of an order can also be manually set by the maker of the order through a trade (this also allows order cancellation). Setting an order’s fill to a non-zero value also implicitly authorizes the order, since the authorization of partially filled orders is cached to avoid unnecessary signature checks.

Authorized order

Orders must always be authorized by the address that owns the proxy contract that will execute the call. Authorization can be done in three ways: signed message, pre-approval, and game-time approval.

signed message

The most common way to authorize an order is to sign the order hash off-chain. It’s cost-free, and orders of any number can be signed, stored, indexed, and perhaps listed on a website or automated order book. To avoid the need to cancel orders that are no longer needed, manufacturers can sign orders with expiry times in the near future and re-sign new orders as long as they wish to continue soliciting deals.

pre-approved

Orders can be authorized by sending a transaction to the contract. This approach may be of particular interest to orders constructed by smart contracts, which cannot themselves sign messages off-chain. On-chain delegation emits an event that can easily be indexed by the order book that contains the order in its database.

Authorization by sending a matching transaction from the order address when there is an instant build order (possibly matching an existing previously signed or approved order) that matches. This is convenient and saves a bit of gas if the maker intends to send a transaction that matches the order itself (since sending a transaction implies calldata validation).

Construct matching invocation data

Matching call data can be constructed off-chain in any way. The protocol does not care how the final calldata is obtained, only that it completes the predicate function of the order. In practice, order book maintainers (relayers) may store additional metadata along with orders that can be used to construct data for possible matching calls.

asymmetrical

To the extent possible, the protocol is designed to be symmetric so that orders do not need to be on any particular “side”, and restricts itself to matching orders on the other “side”.

The first asymmetry is ordering. One call must be executed first, and executing that call may change the result of the second call. The first call passed in is executed first.

The second asymmetry is ether in a special case. Due to Ethereum’s design limitations, Ether, unlike ERC20 tokens, can only be sent from an account through transactions from that account. For ease of use, Wyvern supports special-case ETH as much as possible: the matcher of an order can choose to pass the value along with the matching transaction, which is then passed to the counterparty and passed as a parameter to a predicate function (which can assert, for example, that a specific amount has been sent) .

Changes in Wyvern v3

Orders cannot be matched on their own. But two separate orders from the same manufacturer can match each other.

Taking advantage of the additional expressive power provided by two-way call matching, Wyvern v3 “pushes” nearly all auxiliary aspects of the protocol onto orders, rather than implementing them in exchange contracts, reducing the complexity of the protocol for users and relayers Flexibility, and reduce gas costs.

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/wyvern-1st-order-decentralized-exchange-protocol/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-06-22 09:59
Next 2022-06-22 10:01

Related articles