Crypto Basics

News

Governance

Guides

Product Info

George Hristov

CoW Protocol’s native order types are limited to  _partially-fillable limit buy_  and  _limit sell_  orders. While this expression language covers most retail use cases, it misses some more-powerful advanced order types such as:

-   Good after time orders
-   Stop loss orders
-   Automated rebalancing portfolio orders

… to just name a few.

Adding new native order types to CoW Protocol would involve changing and redeploying the smart contract logic of the core protocol, and is therefore something we want to avoid for the time being.

While the above-mentioned order semantics could be communicated to the protocol/solvers without a smart contract change (e.g. by using additional fields in the  **app_data**), they couldn’t be enforced by the settlement logic and would therefore be subject to “off-chain consensus” (misbehavior would result in slashing by the DAO). This limits the amount of value that can be exchanged using these order types and puts more risk and trust on the solvers.

Smart orders are a clever way of achieving the above-mentioned semantics in a completely trust-less way without requiring a protocol change. Smart orders are based on  [ERC1271](https://eips.ethereum.org/EIPS/eip-1271)’s contract signature scheme and allow smart contracts to decide  **at settlement time**  if an order that is placed in their name is satisfying their trade preference or not.

While regular orders are signed by their owner ahead of time and statically verified using  [**ecrecover**](https://soliditydeveloper.com/ecrecover), smart contract orders implement interactive signature verification by asking the author at settlement time if they are okay with the proposed trade. This verification allows the author to decide just-in-time if they are happy with the proposed trade, so that their approval can be conditioned on any on-chain information (e.g. block time, oracle prices, current balance, etc.).

**In essence, this allows developers to create smart autonomous agents that trade according to predefined rules and strategies, entirely on-chain.**

For example, an automated rebalancing portfolio order (a smart contract that aims to have equal $ value of all its tokens) could perform the following check:

    def checkSignature(order): 
	    buyBalanceAfterTrade = order.buyToken.balanceOf(self) + order.buyAmount
	    sellBalanceAfterTrade = order.sellToken.balanceOf(self) + order.sellAmount
		
		buyBalanceValue = oracle.value(order.buyToken, buyBalanceAfterTrade)
		sellBalanceValue = self.oracle.value(order.sellToken, sellBalanceAfterTrade)

		# Check we only trade portfolio tokens
		assert(order.sellToken in portfolio and order.buyToken in portfolio)
		# Check we don't over-balance
		assert(sellBalanceValue >= buyBalanceValue)
		return  True

Note that the concrete CoW Protocol order that is verified by the smart order contract conforms to the native CoW Protocol order type (i.e. it is a partially-fillable limit order).

However, by incorporating additional information into the interactive verification step (e.g. check the oracle price and only accept if ETH trades below X), the smart order can add additional conditions to the trade.

In fact, the “tricky” part is finding the correct native CoW Protocol order parameter for which the smart contract’s signature verification passes. For this, order placement can happen either:

-   By solvers that are aware of smart orders in the form of just-in-time liquidity (orders that are not part of the official auction set and therefore don’t contribute to the object value)
-   Permissionlessly via the public CoW Protocol API (since ERC1271 doesn’t require a private key signature, anyone can place orders on behalf of a smart contract)

The former option is better suited for very complex order types where the correct order parameters may depend on the outcome of the optimization problem itself. Solvers are incentivised to include these orders since they might allow them to generate more surplus for public user orders.

However, aside from reaching out to solvers directly, there isn’t a great way to inform solvers about this type of custom liquidity today. Therefore, for the purpose of this tutorial, we will focus on the simpler type of order placement: smart orders that are included via CoW Protocol’s public API and available to all solvers by default.

## How do you build a smart order?

We developed an experimental framework for creating smart orders, which proposes a standard interface for conditional smart orders. Orders that implement this interface can be automatically picked up by our supporting infrastructure to place orders without the need for individual operational maintenance:  [https://github.com/cowprotocol/conditional-smart-orders](https://github.com/cowprotocol/conditional-smart-orders)

The core idea is that the smart order contract not only verifies if it is happy to trade a given order. It also proposes (via a separate view method) a concrete CoW Protocol order that it would be willing to accept.

Upon instantiation, the smart order triggers an event. This event is indexed and adds this contract to a registry that an external  _watchtower_  is constantly monitoring by querying the implemented view method. Upon seeing an order candidate, the  _watchtower_  places this order into the CoW Protocol API.

From a developer perspective, all you need to do is implement a single method (**getTradableOrder**), which provides logic for what order parameters your contract would accept given the current state of the chain. The default implementation of the signature verification logic would be as simple as checking that the given order is indeed the one returned by  **getTradableOrder**  (less strict checks are of course also possible in case it’s hard to reliably reproduce the exact order params in between calls).

As soon as  **getTradableOrder**  returns an order, our  _watchtower_  will forward it to the CoW Protocol API, a solver will pick it up and, via the settlement logic, ask your contract to verify it as part of the settlement transaction.

We implemented the registry indexing and  _watchtower_  logic using two [Tenderly Web3 Actions](https://docs.tenderly.co/web3-actions/intro-to-web3-actions):

1.  One to index order creation events and add contracts to the watch registry
2.  Another one to periodically check contracts in the registry if they are willing to trade at the current block

There are other ways to run this off-chain infrastructure, but we found Tenderly’s framework the most convenient without the need for our own cloud setup.

The repository also comes with a few suggested order types (use at your own risk). We would highly appreciate contributions to this repository (you can also apply for  [Grants](https://grants.cow.fi/)  for specific order types).

## How do you deploy a smart order with your Safe?

While the conditional-order framework makes it quite easy to implement custom verification logic, there is usually some amount of custody overhead logic involved that needs to be implemented in such a contract (e.g. how do I get my funds back when I want to exit the strategy). This logic can be complex, expensive to audit and prone to errors. Thankfully, there is a proven smart account abstraction standard out there ([Safe](https://safe.global/)) that allows for a very flexible custody solution and that is already securing many billions of dollars in funds.

In this tutorial we will therefore use a Safe as our main “smart agent” contract and delegate to the conditional smart order logic only for signature verification.

Safe supports ERC1271 signatures out of the box, but also allows the owner to set a custom ERC1271 implementation (e.g. the one your smart order implements). Safes implement ERC1271 via a so-called “fallback handler”, a component that is called whenever the Safe is invoked on a method it doesn’t implement directly (e.g.  **isValidSignature**). Therefore, by setting our smart order implementation as the Safe’s custom fallback handler we replace the default ERC1271 implementation with our own and make our agent trade according to our custom rules. Note that a Safe with such a fallback handler will only be able to ERC1271 sign off on CoW Protocol orders (no other 3rd party dApp related signatures will be valid). Normal Safe transactions with owner signatures will continue to work as usual.

So let’s get started! Most smart orders in our conditional smart order framework come with a  [factory](https://soliditydeveloper.com/clonefactory)  that allows instantiating new instances directly from the Safe UI. The plan of attack is therefore to:

1.  Create a new Safe
2.  Approve the tokens in the CoW Swap app
3.  Create a new smart order instance (targeted at this Safe specifically)
4.  Set the smart order’s address from the previous step as the Safe’s fallback handler
5.  Fund it with the token(s) to be traded. Wait and see the Safe trade automatically

## Step-by-step guide

### 1. Create a new Safe

Head over to [https://app.safe.global/welcome](https://app.safe.global/welcome)  and follow the prompts for “Create new Safe”. Feel free to leave the owner structure simple, e.g. 1/1 signer.

![1-create-new-safe.webp](https://celebrated-gift-f83e5c9419.media.strapiapp.com/1_create_new_safe_11947cfc37.webp)

### 2. Approve the tokens in the CoW Swap App

Inside your Safe, head over to Apps →  [CoW Swap](https://swap.cow.fi/#/1/swap/WETH?utm_source=docs.cow.fi&utm_medium=web&utm_content=header-nav-link). At the top-left of the app, click on Account → Tokens and select the token that needs to be enabled.  [Swap](https://swap.cow.fi/#/1/swap/WETH?utm_source=docs.cow.fi&utm_medium=web&utm_content=header-nav-link)  for any other token and approve the token(s) you intend to trade with this contract.

In this example we are going to trade Wrapped XDAI:

![2-approve-tokens-in-cow-swap-app.webp](https://celebrated-gift-f83e5c9419.media.strapiapp.com/2_approve_tokens_in_cow_swap_app_5364f18433.webp)

### 3. Create a new smart order instance

For this example we will deploy a TradeAboveThreshold order, which will automatically sell whenever the holds more than X of some token.

The factory for this contract on Gnosis Chain is located at [0xd20a99e3c6c103108d74e241908e00ef4db447fb](https://gnosisscan.io/address/0xd20a99e3c6c103108d74e241908e00ef4db447fb)  (if you can’t find the factory, you can deploy a new factory using foundry). To create a new instance, head to your Safe and create a  _New Transaction_  →  _Contract Interaction_  and load the contract ABI from the factory address.

We want to call create. Fill out the required parameters (with the target being your current Safe). In this example we are selling wxDAI for USDC whenever the contract holds $1 or more:

![3-create-a-new-smart-order-instance.webp](https://celebrated-gift-f83e5c9419.media.strapiapp.com/3_create_a_new_smart_order_instance_a65941db91.webp)

Add transaction, create batch, and execute. After the transaction has been executed, open the transaction hash in a block explorer to find the address of the smart order instance that the factory has created (e.g. from looking at the internal txs).

![3-1-create-a-new-smart-order-instance.webp](https://celebrated-gift-f83e5c9419.media.strapiapp.com/3_1_create_a_new_smart_order_instance_214ed8ac83.webp)

Here we created [https://gnosisscan.io/address/0xdf724fdbaef2419f1af895f494bd8969ec433d01](https://gnosisscan.io/address/0xdf724fdbaef2419f1af895f494bd8969ec433d01).

### 4. Set Custom Fallback handler

Head back to the Safe to create a  _New Transaction_  →  _Contract Interaction_, this time on the Safe itself (enter the address of the Safe).

When prompted choose  _Use Implementation ABI_.

![4-set-custom-fallback-handler.webp](https://celebrated-gift-f83e5c9419.media.strapiapp.com/4_set_custom_fallback_handler_ae00dddb6b.webp)

The contract method selector we want to invoke is setFallbackHandler and the address should be the contract that has been created in the previous step:

![4-1-set-custom-fallback-handler.webp](https://celebrated-gift-f83e5c9419.media.strapiapp.com/4_1_set_custom_fallback_handler_12a2a422f0.webp)

After adding and executing this transaction, you will have set the smart order as your Safe’s ERC1271 implementation.

### 5. Fund the Safe

Now, when the Safe receives 1 wxDAI, it should automatically place an order to sell it for USDC. Let’s try:

![5-fund-the-safe.webp](https://celebrated-gift-f83e5c9419.media.strapiapp.com/5_fund_the_safe_998c182c18.webp)

Shortly after the transfer is mined, if we check [https://explorer.cow.fi/](https://explorer.cow.fi/)  for our Safe address, we should see a pending order trying to sell the wxDAI for USDC

![5-1-fund-the-safe.webp](https://celebrated-gift-f83e5c9419.media.strapiapp.com/5_1_fund_the_safe_141edf754d.webp)

And, after a short amount of time the order should be filled.

You can repeat this process as often as you want by just sending some more funds to this Safe. In order to withdraw the proceeds you can use the standard Safe functionality.

## Conclusion

In this tutorial we described and hinted at the power that smart orders can have in the context of smart contracts becoming autonomous trading agents, talked about how a simple “conditional order” type can be created with a few lines of solidity and walked through a step-by-step example of how we can deploy a smart order using Safe as a custody solution.

We hope this article inspired you to try out smart orders, or even build your own on top of CoW Protocol. Please get in touch with suggestions and ideas. We are looking forward to seeing what type of orders can be built with this paradigm.

Give  [ERC1271 orders a try](https://swap.cow.fi/#/1/swap/WETH?utm_source=docs.cow.fi&utm_medium=web&utm_content=header-nav-link)  today and let us know what you think by reaching out on  [Twitter](https://twitter.com/CoWSwap)  or  [Discord](https://discord.com/invite/cowprotocol)!



large_smart-order-tutorial-cover.webp

medium_smart-order-tutorial-cover.webp

small_smart-order-tutorial-cover.webp

thumbnail_smart-order-tutorial-cover.webp

smart-order-tutorial-cover.webp

This tutorial provides an introduction and a step-by-step description of how to create “smart orders” on CoW Protocol. The order that we create will facilitate custom trading logic and use Safe (formerly known as Gnosis Safe) as a backbone.

Tutorial: Creating Smart Orders with CoW Protocol

On July 21st, 2023, After a successful  [governance vote](https://app.nexusmutual.io/governance/view?proposalId=197)  from Nexus Mutual, CoW Swap processed a  [large trade for the insurance protocol](https://twitter.com/CoWSwap/status/1682450015237857280?s=20)  using the exchange’s signature intent-based trading design and MEV protection.

## Trade Details

Nexus Mutual swapped 14,390 ETH from its capital pool for an equivalent amount in rETH. They did so in two separate orders, the first order swapped  [250 ETH for 231.8 rETH](https://explorer.cow.fi/orders/0x29a83c4990db493b7fbf47ed821288340b4e9394524b1da151251d274d64e150cafea5c050e74a21c11af78c927e17853153097d64baae44?tab=overview)  and the second order swapped  [14,140 ETH for 13,117.148 rETH](https://explorer.cow.fi/orders/0x5e84d3e19341b77c362f37e706b153e460deb929d850bec7d9697a631fe4596fcafea5c050e74a21c11af78c927e17853153097d64bab666?tab=overview).

The overall order stats:

-   **USD value of the trade**: $27.3 million
-   **Minimum asset amount**: 13,362 rETH
-   **Maximum asset amount**: 13,400 rETH
-   **Amount the DAO received**: 13,409.04 rETH

## Why CoW Swap?

CoW Swap’s solver competition ensured that Nexus Mutual received the best possible execution price, even after announcing the trade details publicly in a governance proposal ahead of time.

CoW Swap provided several benefits for this trade:

1.  Protection from attack vectors caused by the delayed execution
2.  A limit order that guarantees some minimum amount for the assets
3.  Minting rETH through CoW Swap directly, instead of swapping for the liquidity on the market

For this swap, Nexus Mutual chose the Chainlink oracle as their price checker, guaranteeing that they would receive no less than the minimum specified in the governance proposal.

## CoW Swap: The leader in DAO trading

The largest DAO trades take place on CoW Swap, and the exchange is single-handedly responsible for more than 30% of all DAO trades. Check out  [CoW Swap for DAOs](/learn/cow-swap-for-daos)  to learn why DAOs such as  [Aave](/learn/aave-trade-breakdown),  [ENS](/learn/ens-trade-breakdown), and more trust CoW Swap with their large trades.

If you’re a DAO looking to make a large trade on CoW Swap, get in touch with us on  [Twitter](https://twitter.com/CoWSwap)  or through our  [Discord](https://discord.com/invite/cowprotocol). You can check out CoW Swap for yourself  [here](https://swap.cow.fi/#/swap?utm_source=medium&utm_campaign=NexusM-article).





large_1_Eo3es0t4ei_ARO6gNm7Z_A.webp

medium_1_Eo3es0t4ei_ARO6gNm7Z_A.webp

small_1_Eo3es0t4ei_ARO6gNm7Z_A.webp

thumbnail_1_Eo3es0t4ei_ARO6gNm7Z_A.webp

1_Eo3es0t4ei_ARO6gNm7Z_A.webp

The smartest DAOs trust CoW Swap with their most-important trades


Nexus Mutual Trade Breakdown

On July 10th, 2023, After a successful  [governance vote](https://app.aave.com/governance/proposal/?proposalId=267)  from Aave DAO, CoW Swap processed a large LP position trade for Aave using the exchange’s signature intent-based trading design and Milkman contract.

Since then, Aave completed another trade totaling $1,948,000 with the goal of  [treasury diversification](https://app.aave.com/governance/proposal/282/).

## 1st Trade Details

Aave DAO acquired a direct position in the B-80BAL-20WETH Balancer pool by swapping their entire aBAL & aWETH balances. The trade occurred over two transactions ([Transaction 1](https://explorer.cow.fi/orders/0xb8534a7890442f38394224acea0b894e734175f9dbb17130d444ffcf3c096f438a2e3cef438049b4176186468d3a095d9e24973b64ac2280?tab=overview)) ([Transaction 2](https://explorer.cow.fi/orders/0x825de9ff6963afd5a6e1ab63712f60a749b8750a023e2e49089003d9fee9128b176f00c370f77bdc6c3079296ff89391ccb26bca64ac625e?tab=overview)).

-   **USD value of the trade**: $2,026,573.69
-   **Amount the DAO received**:  [157,169.86 B-80BAL-20WETH](https://governance.aave.com/t/analysis-of-b-80bal-20weth-acquisition/14005), with an average BPT price of $12.89
-   **Slippage tolerance:** 1.5%
-   **Actual slippage**: 1%
-   **Positive difference compared to direct deposit**: 1,918.72 units of B-80BAL-20WETH
-   **Positive difference due to slippage**: 556 units of B-80BAL-20WETH

## 2nd Trade Details

Aave DAO swapped DAI to USDC for treasury diversification purposes. This trade also occurred over two transactions ([Transaction 1](https://explorer.cow.fi/orders/0x03a16efc858c41dd476b8270ed7cdeac00718dd72902493e13c4ec4931a8543d944ea54ae648ceebbdc3e643e8a993a0c4e8dae564ca6b2a?tab=overview)) ([Transaction 2](https://explorer.cow.fi/orders/0xffa61ae864eeaa228ca19195887303d278bbd40f75a9c70493737eb3dbcd0280264fe3292fc2a05500d638093d88adbca487e36864ca6b31?tab=overview)).

-   **USD value of the trade**: $1,937,476
-   **Amount the DAO received**: 1,937,476 USDC
-   **Price Surplus**: $9,699.15

## Why CoW Swap?

CoW Swap’s solver competition ensured that Aave received the best possible execution price, even after announcing trade details publicly in a governance proposal ahead of time.

Compared to a direct deposit, CoW Swap provided several benefits for this trade:

1.  Protection from attack vectors caused by the delayed execution
2.  The minimum amount in a direct deposit proposal would have been uncertain, requiring a high slippage tolerance to successfully execute the trade, which in turn would expose the trade to MEV bots
3.  Use of the Milkman bot for protection against MEV, slippage, and re-entrancy risk

## Milkman

The CoW Grants Program-funded, and Yearn.fi-developed  [Milkman bot](https://github.com/cowprotocol/milkman-bot)  was critical to the Aave trade.

The Milkman bot ensures that trades execute for the real-time price or better by utilizing a price checker, such as a Uniswap v3 pool, Chainlink oracles, or a custom price checker. Instead of setting a slippage tolerance, DAOs can utilize Milkman to determine a maximum percentage deviation from the price checker, guaranteeing that their trade will finalize at a fair market price. Milkman also simplifies governance for trades as DAOs don’t have to define a fixed price re-vote if the market moves significantly.

For this swap, Aave DAO chose the Chainlink oracle as their price checker, guaranteeing that they would receive no less than the minimum specified in the governance proposal.

## CoW Swap: The leader in DAO trading

The largest DAO trades take place on CoW Swap, and the exchange is single-handedly responsible for more than 30% of all DAO trades. Check out  [CoW Swap for DAOs](/learn/cow-swap-for-daos)  to learn why DAOs such as  [ENS](/learn/ens-trade-breakdown),  [Nexus Mutual](learn/nexus-mutual-trade-breakdown), and more trust CoW Swap with their large trades.

If you’re a DAO looking to make a large trade on CoW Swap, get in touch with us on  [Twitter](https://twitter.com/CoWSwap)  or through our  [Discord](https://discord.com/invite/cowprotocol). You can check out CoW Swap for yourself  [here](https://swap.cow.fi/#/swap?utm_source=medium&utm_campaign=aave-trade).

large_Aave-trade-cover.webp

medium_Aave-trade-cover.webp

small_Aave-trade-cover.webp

thumbnail_Aave-trade-cover.webp

Aave-trade-cover.webp

Aave Trade Breakdown

CoW DAO develops the most user-protective products in Ethereum - so you can do more with less worry.

Live Token Price Chart & Metrics

CoW DAO

All articles