Architecture
Architecture of Relay Depository
The architecture of the Relay Depository contracts depends on the VM type of the chain (see VM-specific details below), but high-level, every depository has two core components:
- deposit methods: these are contract methods that can be called by users to deposit funds (optionally, an id can be attached to every individual deposit)
- allocator: entity which can sign messages authorizing the withdrawal of funds from the depository
From the protocol perspective, deposits of funds to the depository represent deposits to the Relay Hub. Once arrived on the Relay Hub, ownership of funds is being tracked there, according to the rules of the Hub. The tracking depends on the implementation of the Hub, and can happen offchain (if the Hub is implemented in a centralized way), or onchain (if the Hub is implemented as a chain). See Relay Hub section for more details on its inner workings.
Below you can find an overview of the depository implementation details across all of the supported VM types.
Ethereum VM
On Ethereum VM chains, there’s two ways to deposit funds to the depository:
- native tokens deposit: using the
depositNative(address depositor, bytes32 id)
method - erc20 tokens deposit: using one of the
depositErc20(address depositor, address token, uint256 amount, bytes32 id)
ordepositErc20(address depositor, address token, bytes32 id)
methods (the second method is going to consume any allowance given bymsg.sender
to the depository contract)
Solana VM
On Solana VM chains, there’s two ways to deposit funds to the depository:
- native tokens deposit: using the
deposit_native(amount: u64, id: [u8; 32])
method - spl tokens deposit: using the
deposit_token(amount: u64, id: [u8; 32])
method