Summary
Aura is always seeking to drive value to the protocol and its token holders through new partnerships, by offering access to liquidity provision on new tokens, and through additional yield farming opportunities; and the primary method of achieving these goals is through deploying new pools.
Aura has recognised that there is a significant overhead, and a high barrier to entry for new DAOs and protocols wishing to join the ecosystem. While some of this overhead is necessary in order to ensure that the quality of offerings on the platform remain high, there are also some additional hoops to jump through that could be removed in order to ease the process.
This proposal seeks to introduce a new UI that enables any DAO or protocol to launch their Balancer pools on Aura, provided that they have a pool on Balancer that has a gauge (signifying that it can receive BAL emissions), and that the gauge has votes (signifying that it will receive BAL emissions in the upcoming epoch).
Motivation
Aura believes that the proposal will have the following benefits:
-
Simpler onboarding to the protocol
Aura intends to add a new UI that demystifies the process on how new pools and tokens can be onboarded. This UI will explain step by step the requirements from the very beginning of the process, including the requirements on Balancer. It will then allow the users to see a list of undeployed Balancer pools that meet the deployment criteria and simply push a button to, once the transaction has resolved (and once automated approvals have occurred on side chains - explained further in specifications), have their pool live on Aura. Finally, the UI will explain the process on how to incentivise liquidity on their newly deployed pool (through voting, Hidden Hand etc.). -
Driving more value to users
Aura foresees that this lower barrier to entry and improved documentation of the process will help onboard new protocols and therefore bring new value to the ecosystem. -
Reduced administration costs and improved flexibility
As much of this process is currently a manual task performed weekly (usually on a Monday) by Aura, it has a time and administration cost associated with it. By allowing protocols to deploy their own tokens, there is improved flexibility when times are constrained - they no longer need to wait until Monday to see their new pool. Furthermore, it is always possible that user error occurs and pools do not meet requirements, or are missed from the manual deployment list. By allowing protocols complete autonomy of how and when they deploy, Aura hopes to reduce the occurrence of any of the aforementioned issues in the future.
Specification
Should this AIP be approved, the following changes will be implemented:
-
UI to onboard new pools
The app interface will be updated with a new page that guides the user through the onboarding process and allows them to deploy their own pools at will. -
Removing Aura DAO multisig permissions from the PoolManager deploy function
The PoolManager contract will be updated to remove the protocol multisig as the operator, this allows only the multisig to add new pools being. Instead, the new operator will be a PoolFeeManagerProxy contract, that allows anyone to be able to add new pools , but still based on the same requirements as before: the underlying Balancer pool has a gauge, and the gauge has votes.
On Mainnet, the pool deployments are expected to be near instantaneous.
On sidechains, any user will be able to request to add a pool by calling the L1PoolManagerProxy contract, with the root gauge and the target chain id. Due to the underlying infrastructure (Balancer GaugeController) being deployed on Mainnet (regardless of whether the pool exists on a sidechain), there will still be an off-chain verification required in order to protect Aura from bridge attacks. Once automation is in place, the lead-time to a new pool deployment would be a few hours.
Technicals
Mainnet
- PoolFeeManagerProxy - 0xD0521C061958324D06b8915FFDAc3DB22C8Bd687
L1PoolManagerProxy - 0x54F2DEc216DFFB9174eDb0d53910bADA5227A14d
All Sidechains
- L2PoolManagerProxy - 0x2B6C227b26Bc0AcE74BB12DA86571179c2c8Bc54
Steps to update on Mainnet contracts
- PoolManager.setOperator(0xD0521C061958324D06b8915FFDAc3DB22C8Bd687)
- BoosterOwnerSecondary.setFeeManager(0xD0521C061958324D06b8915FFDAc3DB22C8Bd687)
- PoolFeeManagerProxy.setProtectedPool(false)
{
"version":"1.0",
"chainId":"1",
"createdAt":1723121316604,
"meta":{
"name":"Transactions Batch",
"description":"",
"txBuilderVersion":"1.16.5",
"createdFromSafeAddress":"0x5feA4413E3Cc5Cf3A29a49dB41ac0c24850417a0",
"createdFromOwnerAddress":"",
"checksum":"0x61e3e818092e0878e264b802b552111b2823be754565d4cdb6141b54545252e9"
},
"transactions":[
{
"to":"0x8Dd8cDb1f3d419CCDCbf4388bC05F4a7C8aEBD64",
"value":"0",
"data":null,
"contractMethod":{
"inputs":[
{
"name":"_operator",
"type":"address",
"internalType":"address"
}
],
"name":"setOperator",
"payable":false
},
"contractInputsValues":{
"_operator":"0xD0521C061958324D06b8915FFDAc3DB22C8Bd687"
}
},
{
"to":"0xCe96e48A2893C599fe2601Cc1918882e1D001EaD",
"value":"0",
"data":null,
"contractMethod":{
"inputs":[
{
"name":"_feeM",
"type":"address",
"internalType":"address"
}
],
"name":"setFeeManager",
"payable":false
},
"contractInputsValues":{
"_feeM":"0xD0521C061958324D06b8915FFDAc3DB22C8Bd687"
}
},
{
"to":"0xD0521C061958324D06b8915FFDAc3DB22C8Bd687",
"value":"0",
"data":null,
"contractMethod":{
"inputs":[
{
"internalType":"bool",
"name":"_protectAddPool",
"type":"bool"
}
],
"name":"setProtectPool",
"payable":false
},
"contractInputsValues":{
"_protectAddPool":"false"
}
}
]
}
Steps to update sidechains contracts
- PoolManager.setOperator(0x2B6C227b26Bc0AcE74BB12DA86571179c2c8Bc54)
{
"version": "1.0",
"chainId": "42161",
"createdAt": 1723121903778,
"meta": {
"name": "Transactions Batch",
"description": "",
"txBuilderVersion": "1.16.5",
"createdFromSafeAddress": "0xD86CEB76e9430D3bDE90ded79c82Ae62bc66d68b",
"createdFromOwnerAddress": "",
"checksum": "0xc4a2970ae2d0940c8b387ffa8cadd353993d58d07052bacab0d869bbaae0c1aa"
},
"transactions": [
{
"to": "0xf24074a1A6ad620aDC14745F9cc1fB1e7BA6CA71",
"value": "0",
"data": null,
"contractMethod": {
"inputs": [
{
"internalType": "address",
"name": "_operator",
"type": "address"
}
],
"name": "setOperator",
"payable": false
},
"contractInputsValues": {
"_operator": "0x2B6C227b26Bc0AcE74BB12DA86571179c2c8Bc54"
}
}
]
}
Voting
This proposal will be subject to a single-choice vote. You may vote “For” or “Against” this proposal, or choose to abstain from voting. A “Yes” vote indicates approval to implement locking and staking on the Base network as described above. A “No” vote indicates that the terms need to be reconsidered.