Deposit Channels & Brokers

In Ingress: Witnessing Deposits, we briefly covered how unique deposit addresses can be reserved for depositors of various kinds to the protocol. Although not necessary to interact with the protocol, this particular ingress method provides incredible flexibility for the user and is a unique feature of the Chainflip protocol. In this component analysis, we’ll explore at a lower level how Deposit Channels work and discuss Brokers in more detail.

Deposit Channels

Almost all contemporary blockchains have some sort of multi-sig compatible addressing system where anyone can derive a very large number of valid wallet addresses that are controlled by a single public key. Given N number of addresses can be derived as f(pubkey, index), creating Deposit Channels isn’t really about the addresses at all, but rather reserving an index for the user.

We tie the index (and address derived from it) directly with a Deposit Channel. A Deposit Channel Request is submitted by the user which registers the Destination Address and other trade details but also reserves an index from which a unique Deposit Channel Address can be derived. Similarly, when Liquidity Providers wish to add funds to their position, they also request an index on the State Chain to lock in their unique Deposit Channel Address.

The method of deriving a unique Deposit Channel Address based on an index varies based on the blockchain that the deposit is intended to be made. Ethereum and its derivative chains, for example, rely on the CREATE2 function (as the vaults on EVM chains are contracts, not wallets), Bitcoin uses its own Hierarchical Deterministic (HD) wallet system, and for Polkadot, another Substrate specific system. Each new blockchain type added will require developing abstractions to handle these varying multi-signature systems.

This is really no different to the way that centralised exchanges handle user deposits, deriving unique deposit addresses and then sweeping the funds from those public addresses into the main wallet as required.

Opening Deposit Channels

1. The user, through a Broker (discussed below), has an extrinsic submitted to the State Chain which includes all required swap data, such as their Destination Chain and Destination Address.
2. The Broker returns the transaction hash to the user to verify the opening of the Deposit Channel.
3. The user can verify the validity of the Deposit Channel using a secondary chain data source if desired
4. The user can also locally derive the Deposit Channel Address based on the index/nonce/salt that was included in the successfully submitted Deposit Request, and when ready, makes a deposit to that derived address to initiate the swap.

It should be noted that designers of front-end interfaces for the Chainflip protocol should be careful to offer users access to the transaction hash of Deposit Channel Request transactions, and should avoid deriving the addresses server-side. By doing it this way, the integrity of the interface and the Broker can be verified by the user through any secondary source of chain data, such as third-party block explorers. This is an essential design standard, necessary to uphold the credibility of the protocol and to promote trustless interactions in general.

Closure of Deposit Channels

All Deposit Channels close after 24 hours. This guarantees continuity of service as the Vaults and Authority Sets rotate. Users should always open a new Deposit Channel and send their deposit immediately every time they swap or make a liquidity deposit.

After a Deposit Channel has been closed, many Vault types will actually reuse the Deposit Channel Address when assigned to a new Deposit Channel. This is normally to avoid redeploying deposit contracts and save on gas on the EVM chains.

See the Vault design documentation for more information on how Deposit Channels are handled during Vault rotations on each chain type.

Brokers

Any State Chain account can play the role of a Broker. Their role is to construct and submit Deposit Channel Requests extrinsics to the blockchain for themselves, but mostly on behalf of end users. This role is essential in enabling the Chainflip protocol’s default user experience: without an access point to submit a transaction to the state chain, users would have to be forced to include complex transaction metadata in their swap deposits to vaults. This would increase gas fees for users and would also necessitate the use of specialised wallets and a myriad of SDK integrations to overcome this issue.

A Broker should offer an endpoint that takes an input of swap intent information and returns the extrinsic hash once the Broker has opened a Deposit Channel on the State Chain for the user. From there, the Deposit Channel can be verified through any secondary source before a deposit to the resulting Deposit Channel Address is made.

Although the role of a Broker is relatively straightforward, one of the major challenges with running a public endpoint to the State Chain is the threat of blockchain spam. To overcome this for the sake of network integrity, Brokers pay a small State Chain transaction fee in $FLIP every time they submit an extrinsic to the State Chain. These $FLIP transaction fees are burned.

This places the burden of spam prevention on the Broker. If their endpoint is abused, they end up paying for the associated transaction fees. As a result, Brokers will need to design systems that protect against spam attacks. Private Brokers sidestep this issue, but public ones will need to ensure their web interface or API is appropriately protected, and that requests are appropriately filtered.

Broker Fees

This design then raises the question: why would anyone run a Broker if they have to pay for third parties to use it, especially when those third parties may be malicious?

The answer lies in Broker Fees. Broker operators can choose to charge a fee for the use of their endpoint, and can be set at any value from 0 basis point to 1000 basis points. When set to more than zero, the network will charge an additional fee which is deducted from the deposit amount, in the deposit asset. This fee is taken immediately after the deposit is witnessed and credited to the broker's account.

This way, anyone wishing to integrate Chainflip into their wallet, web interface, or other Web3 products can benefit from getting their users trading on the protocol. The better the balance Broker operators can strike between attracting users and managing Deposit Channel Request transaction fees, the more profits they can expect to make.

Broker fees are expected to be an important driver of protocol growth, filling the role of an equivalent affiliate scheme common in many centralised exchanges, and even some decentralised ones.

It also removes some incentives to fragment the cross-chain swapping app by offering an easy way to collect fees based on the same protocol in the backend but with different trading interfaces, target users, and product experiences.

With that said, many Brokers will probably not take a fee, particularly private Brokers set up by professional traders to rapidly interact with the network for software trading strategies. However, Brokers that decide to take fees can withdraw these balances at any time through the CLI.

Direct Vault Trades

Deposit Channels can be bypassed through direct Vault trades. This process requires the user to send funds directly to the Vault’s primary wallet or call a Vault contract's swap function, but must include all of the required swap information, such as Destination Address and Destination Chain, in the deposit transaction on the external chain. Upon witnessing this direct transfer, Validators will parse the metadata and immediately include the trade in the swap queue.

It is expected that this direct addressing method will be used by professional traders to speed up their swap executions, bypassing Brokers and swap Deposit Channels in general. It could also be used by application developers who need to be able to send non-interactive transactions to Vaults. By not requiring a call-and-response from the State Chain, and instead only needing to know the current address of the contract or vault, this enables some use cases that would otherwise not be possible.

With that said, we do not anticipate this method being popular amongst typical users, mainly due to the fact that it increases gas costs as a result of the extra metadata that has to be included on the external chain, and would require many different specific wallet integrations to be convenient.