[BIP-255] Approve Cron Fi TWAMM Relayer

Governance General Proposal
1

Payload with PR

Background

We have been researching & developing TWAMMs built on top of Balancer as a custom pool. Balancer grants DAO has been extremely supportive of our endeavor and we’re excited to launch next month. You can learn more about the project here:

Motivation

TWAMMs and Balancer pools in general are complicated to interact with in absence of a UX. We are building a dedicated relayer that abstracts the complexity from the end-user and provides safety in terms of slippage protection and error handling.

We want to do this all from a smart contract thus maintaining the advantages of a fully on-chain protocol: permissionless, composability, & decentralization. Additionally, we don’t want our protocol to be restricted by hostile regulatory regimes that target Web UX.

Interactions

Below are the two ways to interact with the core TWAMM contracts today via Gnosis Safe or Etherscan. Without a dedicated UX, the user would have to know how to set slippage, handle errors, etc themselves.

Unsafe + complex: interact through Vault

A user would have to create tuples and be knowledgeable of Balancer’s Vault infrastructure. Furthermore, they would have to abi.encode data specific to TWAMM like intervals, swap type, etc.

image
image1094×2612 315 KB

Safe + intuitive: relayer/periphery contract

Here the user would specify very simple inputs (similar to in a UX) in order to execute a long-term swap.

image
image1084×2754 273 KB

Development

We will create our Relayer, similar to Balancer Relayer (https://github.com/balancer/balancer-v2-monorepo/blob/master/pkg/standalone-utils/contracts/relayer/BalancerRelayer.sol), but with added abstractions for the following functions:

  • function longTermSwap
  • function shortTermSwap
  • function partnerSwap
  • function join
  • function exit
  • function withdraw
  • function cancel

image
image1908×1195 107 KB

Security

image
image1750×524 76.9 KB

Tradeoffs

Balancer

⛔️ Attack vectors: addressed in the security section
✅ Ease of use for a new pool type
✅ Expand Balancer pool interaction to fully on-chain
✅ Exploring & developing the Relayer ecosystem for other teams, integrators

Cron

⛔️ Increase of attack surface
✅ Vastly improved on-chain UX
✅ Moat against copycats, vampire forks
✅ Simplified onboarding of different user personas: whales, protocols, 3rd party front-ends

Users, integrators

⛔️ Additional gas costs of the periphery
✅ Interact directly without UX/3rd party
✅ Ease of use and integration    
✅ Safety and slippage checks are done by the periphery    
✅ Abstract TWAMM complexity

Governance

We would like governance to approve this relayer so we can onboard users faster, improve user experience, and reduce the complexity to interact with TWAMMs.

Relayer Information:

Balancer’s architecture requires governance approval for CronFi: Relayer for these actions:

Vault Actions:

  • "joinPool(bytes32,address,address,(address[],uint256[],bytes,bool))": "0x78ad1b68d148c070372f8643c4648efbb63c6a8a338f3c24714868e791367653”

  • "exitPool(bytes32,address,address,(address[],uint256[],bytes,bool))": "0xc149e88b59429ded7f601ab52ecd62331cac006ae07c16543439ed138dcb8d34"

  • "swap((bytes32,uint8,address,address,uint256,bytes),(address,bool,address,bool),uint256,uint256)": "0x7b8a1d293670124924a0f532213753b89db10bde737249d4540e9a03657d1aff”

Documentation:

2 Likes
2

I am in support of this proposal. As a reminder, approving a relayer through governance does nothing until individual users explicitly approve. The proposal will be updated with the proper role targets once the contract is deployed.

Cron is doing some next level things in the AMM space. I’m very excited to see this innovation happening on top of Balancer.

2 Likes
3

Echoing Mike here. Through the Balancer Grants team we have had the pleasure of witnessing Cron’s work progress for quite some time and they are top tier overall. They are pursuing audits of their core and periphery contracts to not cut any corners on top of being extremely thorough internally. I am in support and hope others will take the same stance :slight_smile:

1 Like
4

Relayers have a lot of power, and while they require user approval, we should still be careful. This BIP would be stronger if it included a review and/or sign-off from blabs before moving ahead with this proposal.

My understanding is that a user who grants access to this relayer will grant access to all their assets in the vault. Not just those which have been deposited with/controlled by Cron’s TWAMM.

3 Likes
5

Thanks for the feedback @Tritium! The periphery contract will be fully audited by SpearbitDAO and we have had members of Balancer team as reviewers of our code from the get-go. Will check with the team if there’s anybody specific from the BLabs team we should also loop in.

This is true, but all actions still need to be triggered by the user. We plan on restricting the pools that this relayer can interact with to the pools identified by our Factory so we can’t move users’ positions from other pools (exit) and join TWAMM pools for example.

Also, the codebase will be open-sourced and contracts verified on Etherscan at launch so users can review what the relayer is doing.

1 Like
6

Updated the proposal with the mainnet relayer information: CronV1Relayer | Address 0xE0Ca4DAc40d44D737f0d02B1F2B2D969731eCda9 | Etherscan

Code has been audited by SpearbitDAO - Appendix Section, and reviewed by @gerg.

1 Like
7

I also reviewed the mainnet contract at 0xE0Ca4DAc40d44D737f0d02B1F2B2D969731eCda9. I did not check if it works correctly, or even what it tries to do, but I did check that in all Vault calls the sender argument is the caller of the relayer (i.e. its msg.sender).

This means that in order for the relayer to use someone’s funds, then that user has to first approve the relayer, and then call it. This is not unlike granting infinite token allowance to a contract, so I consider it safe to grant this contract relayer permissions (though I did not check the correctness of the contract as a whole - it may do dumb things with your tokens, but you have to tell it to do these dumb things).

4 Likes
8

From reviewing the code in a broader scope, this relayer appears to do what it claims.

  • It is designed only to interact with pools deployed by the Cron Factory
  • The Vault actions it can call are:
    • joinPool
    • swap
      • For a “normal” swap
      • For initiating a Long Term swap
    • exitPool
      • For withdrawing proceeds from a Long Term swap
      • For cancelling (and reclaiming proceeds + unswapped tokens) from a Long Term Swap
  • It handles encoding userData for various functions to simplify user-provided arguments

Disclaimer: I am not an auditor; all smart contracts carry some inherent risk.

5 Likes
9

https://snapshot.org/#/balancer.eth/proposal/0x2fb7eb12cf750993cee5f731646ecbb245de46f34e0de9ddf556dfb518d3ab89