Thanks for all these questions @eek637!
- I’ll answer from an Angle perspective on this one, but I think Gamma might have more elements to add. One heuristic to favor I think when choosing a pool is to go whenever possible to pools with projects which are ready to co-incentivize. Not only does this increase the efficiency of UNI incentives (more TVL and potentially volume with the same amount of ARB tokens from Uniswap), but it also ensures in some way that liquidity will not dry up once incentives from Uniswap stop. Why would a project switch to another AMM if it has already solid liquidity built on Uniswap?
Another thing is of course to go for pools that will bring a lot of volume. The easiest way to keep the liquidity once incentives stop is if volume and fees are high enough to maintain incentives for LPs to stay in the pool. Overall looking into pairs that yield the highest volume on other chains but are under-efficient on Arbitrum is probably the most efficient way to deal with this. - Liquidity managers are automatically all supported in Merkl. Some are natively integrated which means that if an address provides liquidity through like Gamma: the script will see that Gamma has a vault, it will recognize the Gamma vault and instead of making the Gamma vault address eligible to the incentives, the addresses providing liquidity to it will directly be eligible. Adding managers to be natively integrated is a rather straightforward process that can be done on the Angle end by deploying a subgraph for each manager (provided that it’s structured with a factory or a registry). In the worst case, if the Merkl script does not automatically recognize a liquidity manager (or a smart contract able to distribute rewards), the liquidity manager will still be able to claim its rewards and distribute it in some way to its users.
- Distributions can be created on-chain with Merkl by calling what is called a DistributionCreator contract. The function call to be voting on will include two subcalls: one to approve the
DistributionCreatorcontract for the amount of ARB tokens to distribute, and one to create distributions on all the pools that will have been considered eligible. In a distribution, you can specify through a struct the length of the distribution, the amount of tokens to distribute, the parameters for the distribution (like which % for fees, for token0, for token1). Should we move forward, we will of course assist in the preparation of these payloads.
On the questions for Angle:
-
Audits: Angle Protocol was audited several times. When it comes to Merkl in itself, it’s only a set of two gated contracts, one to create distributions and another one being a fork of Uniswap Merkle Distributor contract, with a Merkl root that can be updated depending on the output of the off-chain script (which also comes with a variety of circuit breakers). There are no risk of funds for Merkl users because users do not need to stake their liquidity to be eligible for rewards. The only risk with the system is that the rewards (e.g the ARB tokens) are stolen, but apart from a failure in the script or of a compromised trusted address posting an invalid Merkle root, there are no other way this can happen. Even with the gist of the logic being off-chain for Merkl, we’ve had several peer reviews of the contracts of the system and we’ve planned to include Merkl contracts in our upcoming audit batch (starting on the 26th of June).
-
The privileged roles in the contract are:
- the addresses that are trusted to update the Merkle root that distributes rewards
- a management multisig (with address specified here) which notably has the power to whitelist some tokens to be used as rewards, to waive the signature requirement for some addresses, to change the dispute period. This multisig is a 2/3 multisig with as signers the 3 co-founders of Angle (myself: Pablo Veyrat, Guillaume Nervo, and Picodes).
Access control across Merkl is managed through what we call a Core contract which handles roles.
-
On the parameters, the best results to give to this one would be empirical results. At Angle for the agEUR pools we have incentivized on Uniswap, we had a strong bias towards incentivizing agEUR TVL, so the distribution was skewed towards more people putting agEUR. On the efficiency of the system with such bias, I had shared the result for Angle here. To give you an idea, if you put a 60% weight on fees in the parameters, 60% would mean that with 2 positions with the same TVL, a concentrated position and a full range LP, the concentrated position will get 80% of emissions. The higher the fee parameter, the more concentrated liquidity position will be, but at the same time, I expect this liquidity to be kind of mercenary and a few addresses might over-optimize to earn more at the expense of less advanced users providing liquidity on larger ranges. So the 50,25,25 sounds for us like the best way to:
- Incentivize narrow liquidity enabling Uniswap pools to be more utilized (cf the use case for agEUR on Ethereum in the agEUR-USDC pool)
- But at the same time enable less sophisticated actors to come in and still earn some rewards from their distribution
-
We haven’t had any case so far of someone disputing the results sent through Merkl. It’s most likely because Merkl has ran without any issue since the month of August 2022 and has already helped distributing $m in incentives.