PoC: CoW or 0x for rebalancing after rebase

[mz7mz7mz7]

Ie user had only token X before rebase. After rebase they would have some token X and some token Y. But let's assume they want to hold only token X. How we can automatically do it for them after the rebase?

Some ideas:

1. Automatically sell Y. (this would take some time to execute, the transactions will not be atomic, the prices will fluctuate)
2. Internally offset those who want only X and those who want only Y (no price impact)
3. ???

@jiokeokwuosa , @Tunji17 -- any other ideas?

[Tunji17]

@mz7mz7mz7 what reasons will make a user want to hold only one token over the other? It is my understanding that both tokens will have the same pegged price at this point. correct me if i'm wrong

[Tunji17]

So @mz7mz7mz7 my reasoning behind this is to create some kind of queue where we can partially match risk on tokens with risk off tokens, so a user will opt in to hold only a particular type of token and after every rebase we want to internally offset this for users that have this flag using the queue. but this will depend on demand and supply, so this has to be communicated to the user in one form or the other. like we can encourage them to always trade either of their tokens manually using the exchange but can market this as an experimental feature.

[Tunji17]

we can also automatically settle open orders with token of users that have this flag. eg User A wants to hold only risk off tokens, and we were able to only partially fill 50% of their risk on tokens, if user B opens an order to sell their risk off token we can automatically match this with user A risk on tokens

[Tunji17]

POC for matching orders internally on our smart contract and look into 0x creating orders and matching in bulk

[mz7mz7mz7]

Let's build a prototype/proof of concept with our current smart contracts as a base that would utilize CoW smart orders to execute rebalancing after rebase. Article: https://cow-protocol.medium.com/tutorial-creating-smart-orders-on-cow-protocol-683a5f9f4763 The article is using the old framework, the new one is here: https://github.com/rndlabs/composable-cow Long live coding session on it which was recorded here: https://youtu.be/5lbnMPqfXho Here are the different smart order types that already exist: https://github.com/rndlabs/composable-cow/tree/main/src/types Standard: https://eips.ethereum.org/EIPS/eip-1271 Docs: https://docs.cow.fi/tutorials/how-to-place-erc-1271-smart-contract-orders

We have also shared a Slack channel with the CoW team if we need to raise any questions, it's called 'cow-riskprotocol'.

[haidarally]

0X: @mz7mz7mz7 Can unlimited orders be created by user?

• Yes, User will need to generate and sign the order. They dont check for user balance anywhere. As per my understaning, partially fillable orders should work. https://docs.0xprotocol.org/en/latest/basics/orders.html#limit-orders https://github.com/0xProject/0x-protocol-specification/blob/master/v3/v3-specification.md#fillorder

Can fill multiple orders in a single transaction?

• I dont see that they provide any method for this. However, we can wrap the method in another function that help us fill multiple orders at once. https://docs.0xprotocol.org/en/latest/basics/functions.html?highlight=fillLimitOrder#filllimitorder Sample fill: https://github.com/0xProject/0x-starter-project/blob/master/src/scenarios/fill_erc20_limit_order.ts#L122

[mz7mz7mz7]

In regards to 2nd point: filling multiple orders in one tx, I was referring to these functions @haidarally : https://etherscan.io/address/0x61935cbdd02287b511119ddb11aeb42f1593b7ef#writeProxyContract

[mz7mz7mz7]

And as for both of these points -- can we actually developed simple PoC, in the form of unit test or command line app, whatever is simpler, and just try to do what we discussed:

1. Assuming our middleman (M) wallet address has sufficient balances of X and Y.
2. And assuming it has orders from A and B for selling LARGE X->Y and LARGE Y->X respectively.
3. And the balances of X and Y on A and B are smaller than LARGE.
4. Execute, in one blockchain transaction, two swaps: X->Y from A to M, and after that Y->X from B to M.
5. Which would not change the balances on M at all.
6. And would give A and B only the token they wanted to have.

[haidarally]

@mz7mz7mz7 As discussed, the batchFillLimitOrders method doesnot seem to be present in the v4. Waiting for some clarifications from 0x.

[haidarally]

@mz7mz7mz7 The composable cow frameworks actually works in the following manner

• Deploy an order template such as TradeAboveCertainThreshold
• User need to have a safe wallet
• They need to set their safe with extensiveFallBackHandler https://hackmd.io/-nLuF3JIRyuS5w864_mbrg
• They need to configure composable-cow to respond whenever there is the need for a erc1271 signature
• They need to create an order on the composable-cow Composable cow will emit an event ConditionalOrderCreated, which will be picked up by WatchTowers and processed when matured. https://goerli.etherscan.io/tx/0xbfd3646030f2525714584df5b64d6e1198cf716d5b1bdc243860bf8b0ef3e6d9#eventlog

I think for the part where users need to modify their safe, we should be able to permit them to do so on our dApp using thehttps://www.npmjs.com/package/@safe-global/safe-core-sdk or other sdks

Notes: 2nd Audit still in progress For added info: https://forum.cow.fi/t/automated-treasury-management-methodology/1799 https://www.youtube.com/watch?v=5lbnMPqfXho&ab_channel=CoWSwap

[haidarally]

@mz7mz7mz7 As discussed, the batchFillLimitOrders method doesnot seem to be present in the v4. Waiting for some clarifications from 0x. @mz7mz7mz7

0x Poc works PR: https://github.com/RiskProtocol/rebalance-poc-0x/pull/1 Cons: We have to pay the gas fees

Flow: User has to create a very big order( maximum of uint128) , sign the order and submit both objects to us User has to approve the exchange contract. Then we fill the orders as many time as required Same order filled twice below https://polygonscan.com/tx/0xd3b548a4d174f12ef3813740d50c8a0e8c6ca590233a674c59eb0f1f9b2a34ca https://polygonscan.com/tx/0x8936b495fbcddb6cd93250884cfa29be2bd5e737ef580dfe3460740d5ea5a60b

[haidarally]

Cow AMM: https://discord.com/channels/869166959739170836/1207617790966628414/1219189278769156106

[haidarally]

Updates:

• Composable cow has some issues
• Patched Composable cow : https://github.com/cowprotocol/composable-cow/pull/87
• Audits? etc
• Cow needs to have a pool valued at 0.1 eth to work with the APIs: https://docs.cow.fi/cow-protocol/reference/core/tokens#requirements
• Ref: https://discord.com/channels/869166959739170836/935460632818516048/1251031062860005487 -API and SOlver repo: https://github.com/cowprotocol/services/tree/main

POC

-- Let USDC be RiskOFF -- Let COW be RiskON -- Assume that after every rebase

1. WrapperX will get rid of RiskOFF (USDC) by sending the totality of it to SafeX
2. WrapperY will get rid of RiskON (COW) by sending the totality of it to SafeY

Demonstration

1. As soon as SafeX gets RiskOFF (USDC), it creates an order to sell them
2. As soon as SafeY gets RiskON(COW), it creates an order to sell them
3. The recieved tokens are sent directly to their respective wrappers X and Y

[mfw78]

Hi all, looks like something interesting in the works here. If you need some help from a CoW Protocol side, reach out to us in #tech-talk on discord :smiley: