Solidity Bridge Deployment Scripts

[0xmovses]

Summary

Holesky Deployments for Movement Devnet

Contract	Address
AtomicBridgeInitiatorMove	0xa8ce38EF26fB6e912954cf1309f98d5a753d367F
AtomicBridgeCounterpartyMove	0x09Da59E3fe9Db7BEb26e55467583b1C50357DC85

Holesky Deployments for Movement Testnet Bardock

Contract	Address
AtomicBridgeInitiatorMove	0xB7cBE82b07fdA3517AE882e12C7Faa764C16Afb9
AtomicBridgeCounterpartyMove	0xB5bBBd4913da0a8eb723E8cD1e02d69565f4da66

Sepolia Deployments for Movement Testnet Bardock

Contract	Address
AtomicBridgeInitiatorMove	0x09Da59E3fe9Db7BEb26e55467583b1C50357DC85
AtomicBridgeCounterpartyMove	0xa8ce38EF26fB6e912954cf1309f98d5a753d367F

NOTE that current owner of the contract is 0x5b97cdf756f6363A88706c376464180E008Bd88b

MOVE Holesky Deployment: 0xC36ba8B8fD9EcbF36288b9B9B0ae9FC3E0645227

---

Adds the necessary scripts for deploying the .sol atomic bridge contracts. Follows the same governance procedures laid out in MOVETokenDeployer.

NOTE that the addresses set for movementLabsSafe and movementFoundationSafe are unused addresses for now and are to be verified for real deployment to testnet and mainnet.

Changelog

• Adds AtomicBridgeInitiatorMOVEDeployer.sol
• Adds AtomicBridgeCounterpartyMOVEDeployer.sol

Testing

You can test this by deploying against a local anvil network :

PRIVATE_KEY=<YOUR_PRIVATE_KEY> forge script AtomicBridgeInitiatorMOVEDeployer --for
k-url http://127.0.0.1:8545 --broadcast --legacy

Grab the contract address generated and use that as the Initiator arg for the Counterpary script

PRIVATE_KEY=<YOUR_PRIVATE_KEY> forge script AtomicBridgeCounterpartyMOVEDeployer --for
k-url http://127.0.0.1:8545 --broadcast --legacy

[Primata]

You might want to merge primata/contract-pipeline and inherit Helper so that you can have all methods in place.

[Primata]

these addresses are wrong, here is the ethInitiator 0xa8ce38EF26fB6e912954cf1309f98d5a753d367F
and this is the ethCounterparty 0x09Da59E3fe9Db7BEb26e55467583b1C50357DC85

[l-monninger]

@0xmovses What are the next steps you'd like to take here?

[0xmovses]

@l-monninger Let me rebase main and redeploy these contracts, I'll update the PR description with new addresses.

[0xmovses]

setCounterpartyAddress on 0xB7cBE82b07fdA3517AE882e12C7Faa764C16Afb9 was called

blockHash               0x26af7301a3aab4b516631adbf0a3e8732f0400d229ec71cac6ab438f90e55d92
blockNumber             2593025
contractAddress
cumulativeGasUsed       2314160
effectiveGasPrice       1032034
from                    0x5b97cdf756f6363A88706c376464180E008Bd88b
gasUsed                 51084
logs                    []
logsBloom               0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
root
status                  1 (success)
transactionHash         0x27a02b403063dacbeaa01945302ee1eef99340af64c66bcb97cf696469d0cf15
transactionIndex        13
type                    0
blobGasPrice
blobGasUsed
to                      0xB7cBE82b07fdA3517AE882e12C7Faa764C16Afb9

[andygolay]

I'd say this looks good pending resolution of @0xPrimata's comments

[Primata]

Because initiator and counterparty are paired, I would suggest merging them and calling

AtomicBridgeInitiatorMOVE(atomicBridgeInitiatoryProxy).setAtomicBridgeCounterparty(address(atomicBridgeCounterpartyProxy));
AtomicBridgeCounterpartyMOVE(atomicBridgeCounterpartyProxy).setAtomicBridgeInitiator(address(atomicBridgeInitiatorProxy));

[andygolay]

@0xPrimata does there need to be some kind of assertion in lockBridgeTransfer, about available MOVE?

Or, if not, how can we be sure that the amount will be available to withdraw in completeBridgeTransfer?

[Primata]

because it has been bridged before. The poolBalance doesn't help at all with knowing that the amount will be available to withdraw in the case of an exploit.

I would suggest taking a look at ERC20 _transfer method and seeing that it's doing exactly what we do with poolBalance but with extra security steps.