I’ve been thinking a lot about how we can safely bridge POOL to Polygon. My two major concerns have been:
- POOL being effectively burned because L2->L1 return costs are very high.
- Inability of Polygon POOL holders to participate in governance.
I believe I have a solution, so I’ve written it in the form of a PTIP. Have a read below and let’s discuss the approach.
Summary
This proposal allows us to bridge the POOL token to Polygon while retaining voting power.
Abstract
We will deploy a new token on Ethereum called Bridge Pool. This token can be minted and burned for POOL at a 1:1 exchange rate. The Bridge Pool token can be bridged to Polygon using their standard mechanism, saving us significant effort. The POOL held by the Bridge Pool can be delegated by governance.
Motivation
Polygon allows users to very easily set up a token bridge for ERC20 tokens. This means that tokens are locked into the bridge on Ethereum, then minted in the corresponding bridge on Polygon. The problem with this solution is that POOL tokens locked in the bridge are unable to be used for voting. Some people may bridge POOL tokens back to Ethereum, but the bridge is quite costly. Current costs are around $100 USD. Small amounts of POOL will become dust and be permanently locked in Polygon.
This proposal aims to mitigate the loss of votes by bridging what is effectively a POOL “IOU” token.
Specification
Overview
This proposal will:
- Deploy a Bridge Pool token contract
- Bridge Pool tokens can be minted by depositing POOL
- POOL can be redeemed by burning Bridge Pool tokens
- Governance can delegate the voting power of the POOL held by the Bridge Pool contract.
- The Bridge Pool token will be bridged to Polygon as the official POOL token.
- Polygon POOL holders (and possibly bPOOL) can vote using Snapshot. The delegate will vote in on-chain proposals according to the results of the Snapshot votes.
Rationale
We want to bridge the POOL token to Polygon so that users can take advantage of cheap transactions, but still contribute to the protocol. By utilizing Polygon’s standard token bridge, we can save a significant amount of development effort. Deploying a token is very simple to do, and it only needs mint, burn and delegate functionality.
4 Likes
Glad you are posting this as I think it’s very important. I like the plan. I have a couple of questions.
how exactly does this process work?
who is the voting power delegated to? (would it be controlled by a multisig)
at what intervals would these tokens be delegated? (people could mint and burn bPOOL at any time)
can you delegate to yourself so you retain voting power?
2 Likes
how exactly does this process work?
It would work exactly like the current POOL Pool:
- Users deposit their Pool into the contract
- Governance has the ability to delegate the voting power of POOL held by the contract
If users withdraw, the voting power decreases. If users deposit, the voting power increases.
at what intervals would these tokens be delegated? (people could mint and burn bPOOL at any time)
My intuition is that the bridge will be mostly used by governance to safely bridge POOL to Polygon for liquidity mining. My second intuition is that users will mostly use bPOOL to redeem actual POOL tokens. I’m not sure if many people would want to bridge to Polygon.
can you delegate to yourself so you retain voting power?
You can only delegate votes, to yourself or otherwise, if you hold POOL tokens.
So does it mean that bPOOL holders will be able to vote through Snapshot and then the result of the vote will be cast on chain by governance? Or bPOOL holders will lose the ability to vote?
That’s how voting works for DPI, if you have Index tokens, you can vote through Snapshot and then they use the tokens held in the DPI contract, let’s say Aave, to cast a vote on chain.
https://snapshot.org/#/index/proposal/QmeqmnsThQNCjdhVno9Fhjtk3zkkUUKT6SkrQNBpRpENbi
1 Like
So does it mean that bPOOL holders will be able to vote through Snapshot and then the result of the vote will be cast on chain by governance?
Exactly! I realize now that I didn’t make that very clear in the post, I’ll make an edit.
1 Like
I think we should discuss quorum requirements on a polygon snapshot voting scenario. Would it mimic requirement that exists on layer one?
1 Like
I think what’s important is being consistent for our multisig rules.
The POOL Pool Snapshot multisig is a Safe with 2-of-4 confirmations required. It would be simplest to continue that same pattern, and then everyone will know the rules.
Perhaps all multisig owners should be incentivized? If at least to cover the gas.
1 Like
So: I’m going to shoot down my own proposal for two reasons:
- Creating an intermediary token is not worth the engineering effort. Bridging POOL to Polygon hasn’t resulted in lost votes, so why spend a lot of time addressing a non-existent problem.
- Keeping incentives on Ethereum will drive the POOL token back. Ethereum is our settlement layer, and while users may earn POOL tokens on L2s they should stake their POOL tokens on Ethereum.
We’re going to proceed by using the standard Polygon bridge for the POOL token.
2 Likes
POOL has been bridged to Polygon.
You can now go to the Matic Bridge and transfer your POOL to Polygon.
Token |
Polygon Address |
POOL |
0x25788a1a171ec66da6502f9975a15b609ff54cf6 |
1 Like