Badger-Finance
migrate BADGER liquidity for Across bridge from v1 to v2 liquidity pool
on May 17, Across will be migrating their platform from v1 to v2 with new liquidity pools and model. for Badger DAO to continue providing users liquidity to instantly bridge BADGER from arbitrum to mainnet after that date it will be required current BADGER liquidity is migrated from the v1 lp contract to v2 pool contract.
layman summary - https://medium.com/across-protocol/lps-migrate-liquidity-from-v1-to-v2-screenshots-and-faqs-8616150b3396
steps to migrating liquidity
-
remove BADGER liquidity from Across v1 Badger LP https://etherscan.io/address/0x43298F9f91a4545dF64748e78a2c777c580573d6#writeContract
-
add BADGER liquidity to Across v2 HubPool LP https://etherscan.io/address/0xc186fa914353c44b2e33ebe05f21846f1048beda#writeContract (Updated HubPool LP contract to prod)
block by not WL badger in hub pool just yet, will be sorted next week
script merged, already across started moving the migration to v2 officially, we will be able to migrate partially due to utilization
Some DD notes on the HubPool.sol contract:
Diff
Started off by comparing the latest logic from the repo and the deployed, you can see the comparison here: https://www.diffchecker.com/aca35q9u
Deployed logic doesn't include the following functionalities:
- Pausability on
addLiquidity() - haircutReserves() function, unaudited security feature that:
Enables the owner of the protocol to haircut reserves in the event of an irrecoverable loss of funds on one of the L2s.
Difference doesn't raise any red flags.
Audit
Contracts were audited by OpenZeppelin Security and some issues and vulnerabilities were found and later on addressed by the UMA team.
The audit discloses that some unknown integration vulnerabilities may arise and that the audit is only limited to the codebase in matter.
Ownership
The HubPool contract's owner currently points to 0x9a8f92a830a5cb89a3816e3d267cb7791c16b04d
WARNING: THIS IS AN EOA!!! Owner controls all functions related to the pool's management as well as the security features (pausing/emergencyDeleteProposal). Some of these functions include altering the cross-chain contract related to the pool. Deeper digging is required to understand the systematic repercussions that some of these functions could have if the owner was compromised - specially rugging vectors.
Testing
The HubPool contract is thoroughly tested with multiple unit/integration tests:
NOTES
removeLiquidity()is not pausable and, hence, a malicious owner couldn't block withdrawals through that mean.- Add/Remove liquidity has reentrancy checks as required.
- Biggest notable concern is around the HubPool EOA Ownership - I would recommend to inquire about whether ownership will be transferred to a Multisig. Otherwise, further DD is required to ensure that ownership capabilities can't put funds at risk.
hubpool production contract: https://etherscan.io/address/0xc186fa914353c44b2e33ebe05f21846f1048beda
as discussed with @sajanrajdev in dms. the owner in this case it is a msig, 2/6. at the moment seems that it is keep with low threshold for agility of patching, but plans in the following month is to move owner to optimistic governance contract which is fully audited.
likely safe threshold later on will be increase prior to transfer ownership to governor contract
EDIT: The contract analyzed above was a test contract. The live instance can be found here 0xc186fA914353c44b2E33eBE05f21846F1048bEda
The logic matches the latest release from the repo: https://www.diffchecker.com/LqMXlnvu. This includes the audit fixes and new security features discussed above.
This contract is owned by a 2/6 Multisig
The team mentioned that they decided to keep a 2/6 to keep agility during launch phase. But they have plans to increase to 3/6 shortly and to move towards an OptimisticGovernor setup in the next month.
Given OZ's reputation as auditors and the thoroughness of their audit, the audit's fixes implemented, the repo's testing coverage, proof of on-chain testing, and ownership by a multisig (although 2/6 is not ideal, this will change shortly), I think we should be good to migrate.
We should still get a senior Solidity sign-off imo.
Is pretty much a screaming security warning. From what I can tell the owner can deny any tx effectively allowing them to freeze tokens in the contract.
I can't seem to find a way for funds to be swept out, there still may be other attack vectors such as minting more LP token to claim them on the other side, but I haven't found proof for nor against it being doable
I'd ask the Across team to change to a multi-sig instead of EOA
@hasherror @petrovska-petro
Saj says the address has been updated, can you please update the Issue and confirm the proper HubPool Address?
This is the prod version of HubPool contract afaik https://etherscan.io/address/0xc186fa914353c44b2e33ebe05f21846f1048beda#readContract
Updated issue (I think)
Liquidity migration will be on hold till OptimisticGovernor becomes the owner of the HubPool, which will have at least 2H timelock. Contract still needs deeper DD from our side. but it has being fully audited
Bringing this back to pending to start discussions of pulling v1 liquidity from Across to prevent any issues / loss of funds while we wait for v2 to be secured by the 3/6 msig
is the v1 still active, as in can users currently use that to bridge? otherwise it makes no sense to keep liquidity there.
if indeed it is still active, why would we want to migrate to v2? what happens if we just stick to the v1 contract for now? will it get deprecated?
v1 is no longer active. If badger is not comfortable moving to the v2 liquidity pool (which is still presently managed with a 2/6 multisig) I think it's better to bring the badger tokens back to Treasury until/if badger is interested in the v2 option.
On Tue, Aug 2, 2022, 1:55 AM Gosuto Inzasheru @.***> wrote:
is the v1 still active, as in can users currently use that to bridge? otherwise it makes no sense to keep liquidity there.
if indeed it is still active, why would we want to migrate to v2? what happens if we just stick to the v1 contract for now? will it get deprecated?
— Reply to this email directly, view it on GitHub https://github.com/Badger-Finance/badger-multisig/issues/439#issuecomment-1202049366, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASDOCELTP6P6QH4WY77UT6LVXCZ3NANCNFSM5VWWSYGA . You are receiving this because you were mentioned.Message ID: @.***>
snapshot result for 0xD0A7A8B98957b9CD3cFB9c0425AbE44551158e9e:
balance_before balance_after balance_delta
symbol
A-BADGER-LP 19,999.976192836985924272 0.000000000000000000 -19,999.976192836985924272
BADGER 5,126,560.240273895041890584 5,146,712.844935597673603643 20,152.604661702631713059
Events In This Transaction
--------------------------
├── Across Badger LP (0x43298F9f91a4545dF64748e78a2c777c580573d6)
│ ├── Transfer
│ │ ├── from: 0xD0A7A8B98957b9CD3cFB9c0425AbE44551158e9e
│ │ ├── to: 0x0000000000000000000000000000000000000000
│ │ └── value: 19999976192836985924272
│ └── LiquidityRemoved
│ ├── amount: 20152604661702631713059
│ ├── lpTokensBurnt: 19999976192836985924272
│ └── liquidityProvider: 0xD0A7A8B98957b9CD3cFB9c0425AbE44551158e9e
│
└── Gnosis Safe (0xD0A7A8B98957b9CD3cFB9c0425AbE44551158e9e)
└── ExecutionSuccess
├── txHash: 0xc4296303d81aa7f33b73b0bd41661ee68e7b5334f54225d74a3bae71d9f6462e
└── payment: 0
{
│ 'ethereum_client': <gnosis.eth.ethereum_client.EthereumClient object at 0x7f81348f6fd0>,
│ 'safe_address': '0xD0A7A8B98957b9CD3cFB9c0425AbE44551158e9e',
│ 'to': '0x40A2aCCbd92BCA938b02010E17A5b8929b49130D',
│ 'value': 0,
│ 'data': HexBytes('0x8d80ff0a000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000f20043298f9f91a4545df64748e78a2c777c580573d600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004bd6d894d0043298f9f91a4545df64748e78a2c777c580573d6000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000444f52fd1700000000000000000000000000000000000000000000043c336cfef84defaab000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'),
│ 'operation': 1,
│ 'safe_tx_gas': 0,
│ 'base_gas': 0,
│ 'gas_price': 0,
│ 'gas_token': '0x0000000000000000000000000000000000000000',
│ 'refund_receiver': '0x0000000000000000000000000000000000000000',
│ 'signatures': b'',
│ '_safe_nonce': 50,
│ '_safe_version': '1.3.0',
│ '_chain_id': None
}
withdrawal from v1: https://etherscan.io/tx/0x20329a7e6b0ea974d8f5faf0fdf8637ffd6d104a6b34e3d1e2ccc2f82262e62c
suggesting to move this ticket to backlog until we hear back from the across team in regards to better governance structure.
Across is still at least a month from migrating away from 2/6 multisig for their v2. The badger in the v1 liquidity pool is inert.
I'd recommend pulling the tokens back to Treasury if Badger does not want to move the liquidity to the v2 pool while it remains under 2/6 multisig control.
On Wed, Aug 3, 2022, 9:33 AM Gosuto Inzasheru @.***> wrote:
suggesting to move this ticket to backlog until we hear back from the across team in regards to better governance structure.
— Reply to this email directly, view it on GitHub https://github.com/Badger-Finance/badger-multisig/issues/439#issuecomment-1203957629, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASDOCEKPGKBACMS3FOG36CTVXJYLHANCNFSM5VWWSYGA . You are receiving this because you were mentioned.Message ID: @.***>
Across is still at least a month from migrating away from 2/6 multisig for their v2. The badger in the v1 liquidity pool is inert. I'd recommend pulling the tokens back to Treasury if Badger does not want to move the liquidity to the v2 pool while it remains under 2/6 multisig control.
yes this is exactly what we did, see my comment above for tx hash.
Got it. I'm not great at following the GitHub process flows. Cheers
On Wed, Aug 3, 2022, 10:04 AM Gosuto Inzasheru @.***> wrote:
Across is still at least a month from migrating away from 2/6 multisig for their v2. The badger in the v1 liquidity pool is inert. I'd recommend pulling the tokens back to Treasury if Badger does not want to move the liquidity to the v2 pool while it remains under 2/6 multisig control.
yes this is exactly what we did, see my comment above for tx hash.
— Reply to this email directly, view it on GitHub https://github.com/Badger-Finance/badger-multisig/issues/439#issuecomment-1203996318, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASDOCEIUATZQCGO7GVGZTHLVXJ377ANCNFSM5VWWSYGA . You are receiving this because you were mentioned.Message ID: @.***>