Wizard Bridge V2 High-level design:
Initiation Transaction on BSC: The user initiates a transaction on BSC. This could involve Ether (or, more likely, BNB or a BEP-20 token), or it could be a more complex smart contract interaction.
Lock Funds on BSC: The bridge's smart contract on BSC locks the user's funds, which means they're inaccessible until the process is completed.
Generate a Cryptographic Proof of Transaction: Once the transaction is confirmed on the BSC, the bridge generates a cryptographic proof of this transaction. This proof includes the amount of BNB/tokens transferred, the address sending them, and the address that should receive them on Arbitrum.
Submit Proof to Arbitrum: The bridge submits this proof to its corresponding smart contract on the Arbitrum network. This could be done by a centralized entity (called a relayer), by the users themselves, or by a decentralized network of relayers.
Verify Proof on Arbitrum: The Arbitrum contract verifies the proof. This involves checking the cryptographic proof and the BSC state root. This step is more complicated than it sounds because Arbitrum and BSC are separate networks. You'll likely need a system in place to relay BSC block headers to Arbitrum, or utilize a decentralized oracle service.
Mint Tokens on Arbitrum: If the proof is valid, the Arbitrum contract mints an equivalent amount of wrapped tokens (like a wrapped version of BNB or the BEP-20 token) on the Arbitrum network and assigns them to the appropriate user's address.
Last updated