By improving our gauge add reporting in multi-sig ops, we guarantee that always the correct gauge is set as "preferential" in the subgraph and ultimately in the front-end
Problem statement
Let's say an entity creates a gauge on Arbitrum, then wants to apply for a BAL gauge and re-creates a new one. In the subgraph and the front-end, the first gauge is automatically set as preferential. One needs to emit an event to set it correctly. Ideally, if this is the case, one should do it before the gauge goes live / is added to the gauge controller so we guarantee frictionless operations
Implementation details
After checking that root and child-chain gauges are correctly set, do the following:
check the root gauge
check the getrecipient field
on target chain, check subgraph and check preferential gauge field by calling following query:
{
pool(id: "POOL_ADDRESS_LOWERCASE") {
preferentialGauge {
id
}
gauges {
id
}
}
}
if getrecipient in root gauge != preferential on target chain, throw error / warning
Tritium-VLK
commented
3 weeks ago
Motivation
By improving our gauge add reporting in multi-sig ops, we guarantee that always the correct gauge is set as "preferential" in the subgraph and ultimately in the front-end
Problem statement
Let's say an entity creates a gauge on Arbitrum, then wants to apply for a BAL gauge and re-creates a new one. In the subgraph and the front-end, the first gauge is automatically set as preferential. One needs to emit an event to set it correctly. Ideally, if this is the case, one should do it before the gauge goes live / is added to the gauge controller so we guarantee frictionless operations
Implementation details
After checking that root and child-chain gauges are correctly set, do the following:
Details: https://github.com/balancer/gauges-subgraph/issues/91