Relayers & Addressing
In Ingress: How Chainflip Gets Assets, we briefly covered how unique deposit addresses can be reserved for depositors of various kinds to the protocol. In this component analysis, we’ll explore at a lower level how Ingress Addressing works and discuss Relayers in more detail.
Almost all contemporary blockchains have some sort of multi-sig compatible addressing system where anyone can derive a very large number valid wallet addresses that are controlled by a single public key. Given N number of addresses can be derived as f(pubkey, index), Ingress Addressing 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 Swap Intent. A Swap Intent is essentially a request, not only to register the Payout Address and other trade details, but to reserve an index from which a unique Ingress 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 Address.
The method of deriving a unique deposit address based on an index varies based on the blockchain that the Swap Deposit is intended to be made on. Ethereum and its derivative chains, for example, rely on the CREATE2 function, 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 multisignature 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.
The process for reserving and receiving an Ingress Address through a Swap Intent follows this process:
- 1.The user, through a Relayer (discussed below), has an extrinsic submitted to the State Chain which includes all provided Swap Intent data.
- 2.The Relayer returns the transaction hash to the user to verify the state of the Swap Intent
- 3.The user can verify the inclusion of the Swap Intent in a block through a secondary chain data source if needed
- 4.The user can also locally derive the Ingress Address based on the index/nonce that was included in the successfully submitted Swap Intent, and when ready, makes a deposit to that 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 Swap Intent transactions, and should avoid deriving the addresses server-side. By doing it this way, the integrity of the interface and the Relayer 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.
Any state chain node with a balance can become a Relayer. Their role is to construct and submit Swap Intent 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 Relayer should offer an endpoint that takes an input of swap intent information, and returns the extrinsic hash once the Relayer has submitted it to the state chain. From there, the Swap Intent can be verified through any secondary source before a deposit to the resulting Swap Address is made.
Although the role of a Relayer 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, Relayers pay a small state chain transaction fee in $FLIP every time they submit a Swap Intent extrinsic to the state chain. These $FLIP transaction fees are burned.
This places the burden of spam prevention on the Relayer. If their endpoint is abused, they end up paying for the associated transaction fees. As a result, Relayers will need to design systems which protect against spam attacks. Private Relayers sidestep this issue, but public ones will need to ensure their web interface or API is appropriately protected, and that requests are appropriately filtered.
It is important that Relayer operators are provided with the tools to reduce the risk of spam attacks, and to mitigate the costs should they occur. It is assessed that the kinds of spam attacks possible through Relayers and the strategies to mitigate them are not unique to Chainflip, but exist across all public endpoints, websites, and internet services of all kinds. Thus, the mitigation techniques will broadly reflect the best practices in use across the internet today. What differentiates Chainflip Relayers is that there is a more significant direct financial cost associated with the requests made by potential spammers, but the tradeoff to achieve the desired user experience should be worth it.
This design then raises the question: why would anyone run a Relayer if they have to pay for third parties to use it, especially when those third parties may be malicious?
The answer lies in Relayer Fees. Relayer operators can choose to charge a fee for the use of their endpoint, and can be set at any value from 1 basis point to 1000 basis points. As a part of the Swap Intent extrinsic, Relayers include an otherwise empty relayer fee value which will instruct the network to charge an additional fee (similar to the Network Fee) which is deducted from any completed swap that they relayed the Swap Intent for. This fee is taken in USDC immediately after the Network Fee has been deducted.
This way, anyone wishing to integrate Chainflip into their wallet, web interface, or other Web3 product can benefit from getting their users trading on the protocol. The better the balance Relayer operators can strike between attracting users and managing Swap Intent transaction fees, the more profits they can expect to make.
Relayer 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 of the 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 Relayers will probably not take a fee, particularly private Relayers set up by professional traders to rapidly interact with the network for software trading strategies.
Ingress Addressing can be bypassed through direct vault trades. This process requires the user to send funds directly to the Vault’s primary wallet or contract address, but must include all of the required information to derive a Swap Intent in the transaction metadata in the external blockchain ingress transaction. 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 Relayers and Swap Intent transactions 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.
As raised in other sections, one of the more complex aspects of processing Swaps is handling cases of Vault Rotation. Vault Contracts will be easier to manage since the contract address itself shouldn’t change, but Native Wallet Vaults create a brand new wallet every time even one member of the Authority Set changes.
To illustrate the problem, consider a user that, through a Relayer, successfully submits a Swap Intent Extrinsic at 13:00 local time, attempting to sell DOT tokens. Shortly afterwards, at 13:14 local time, the latest auction is completed. By 13:27, all of the necessary key generation ceremonies and tests have been completed, and the Vaults have been rotated to the new Authority Set. By the time the user has located their wallet and initiated a transfer, it’s 13:35 local time.
The user has just sent funds to a Vault controlled by an old Authority Set. If no process to handle this scenario is built, the user simply loses their deposit forever.
To overcome this problem, the Chainflip protocol forces members of an Outgoing Authority Set to remain online and maintain all Native Wallet Vaults for 2 weeks after a Vault Rotation process has been started. This way, if any deposits are made in this window of time, they can be witnessed and swept into the new Native Wallet Vault.
During this window of time, we say that the Vault is Expiring, and once that window of time has passed and all remaining funds in the Vault at that time are swept into the latest Vault, it has then Expired.
It should be noted that in most cases, the Authority Set will likely contain largely the same members in each successive epoch with only minor membership changes each auction. Therefore, most members of the Outgoing Authority Set will also be members of the current Authority Set, and won’t be impacted by the added responsibility of maintaining an old Vault.
For those Validators which are Unstaking or have been outbid in the latest auction, they remain as an Active Validator not in the Authority Set, and are instead called an Outgoing Member. While the Vaults which they control have not yet expired, they remain bonded and liable for slashing, and must witness ingress transactions related to the expiring Vaults, and sign transactions to sweep funds out of them.
Last modified 2mo ago