Executors Part 3: Incentives
Welcome back to the third and final part of our blog series on Executors, a crucial actor in the t3rn ecosystem. In the first blog Part 1: What are t3rn Executors?, we introduced the role of the Executors, and explained how to become one and start generating yield by executing multichain transactions. In the second blog Part 2: Execution Lifecycle, we covered the three stages of an XTX object's life cycle, vital to successfully execute multichain transactions and generate yield on t3rn.
Now, we will dive deeper into the world of Executor incentives, which are a critical component of t3rn tokenomics. As we explore this topic, we will learn about liquidity (having more funds available for transactions), execution value, and execution speed, and we will go through an example of a transaction presenting three different scenarios.
So, get ready to discover how Executors' incentives contribute to the growth and success of the t3rn ecosystem and get a taste of the coming releases.
Liquidity on Target
As with most protocols, liquidity is paramount. In t3rn, the protocol benefits from Executors having liquidity available on the target chain they operate on. More funds at their disposal results in more and larger transactions being processable. At the same time, attracting liquidity is crucial to bootstrapping a newly connected chain.
Unlike traditional bridges or AMMs, t3rn does not rely on smart contracts to lock the liquidity of the protocol. Executors can freely move, manage and also secure the liquidity that they provide. This flexibility makes incentivizing liquidity more complicated when compared to traditional liquidity mining.
Target blockchains will have liquidity incentive periods, enabling Executors to prove the number of funds they have available on the target. This balance is relayed to the t3rn Circuit, where a proportional amount of incentive rewards can be collected.
Execution Value
Additional rewards are also distributed for the value each executor has transferred cross-chain. Metrics like transaction amount, value, and type will derive this.
Execution Speed
Quick confirmation times benefit every network participant in t3rn. Executors are more capital efficient, having their funds tied up in XTXs for less time. Users benefit from low overall transaction times. As a result, the confirmation speed as a side effect is also incentivized via Executor rewards.
Transaction examples
For this example, we will introduce the following parties:
Alice - A user creating XTX transactions
Edward - An Executor fulfilling transactions on Ethereum and Kusama
Emma - An Executor fulfilling transactions on Ethereum and Kusama
Exchange rates:
1 TRN = 1 USD
1 ETH = 1000 USD
Single-step Optimistic XTX
Alice wants to convert 1000 TRN tokens on t3rn to 1 ETH on Ethereum. She uses a bridging dApp, built on the t3rn protocol for this.
- Since dApp only does single-step asset bridging, it uses the optimistic transaction type, making transactions fast and cheap.
- dApp now recommends the max_reward amount based on the asset value, historic rewards, and current transaction costs. In this case, it recommends 10 TRN, adding it to the 1000 TRN Alice wants to transfer.
- dApp sets the insurance deposit to 101 TRN, requiring the Executor to deposit 10% of the transaction value during the execution stage.
- Alice submits the transaction, having 1010 TRN of her account reserved.
- Edward and Emma see the XTX (containing the transfer Side Effect) and run their custom Risk/Reward analysis. They now have to decide:
- If they want to facilitate the SFX at all
- If so, which max_reward would be acceptable to them
- Edward wants to execute the transaction and decides a reward payment of 1009 TRN would be sufficient to turn a profit. He submits this as a bid for the SFX. This automatically reserves the insurance deposit of 101 TRN on his account.
- Emma is sure she can profitably execute the Side Effect for 1008 TRN and submits this as a bid. As Emma's bid is lower, Edward’s bid is undercut, resulting in his reserved balance being claimable. In turn, Emma has 101 TRN of her balance reserved as the insurance deposit.
- The bidding period has now expired, making Emma the Executor for this SFX, the only one in the XTX.
Scenario A - Emma Executes correctly
- Emma now sends 1 ETH, from an Ethereum account she controls to Alice's receiver address.
- Once the transaction is finalized, she generates an inclusion proof for her transaction and submits it to the t3rn blockchain.
- The inclusion proof is checked, ensuring that Emma sent the correct amount of ETH to the correct address. If this is the case, the XTX is finalized, allowing Emma to claim her reward.
- Alice is refunded 2 TRN, the result of the bidding.
Scenario B - Emma executes incorrectly, and Edward claims re-execution
- For some reason, Emma does not execute the SFX she had bid on
- The XTXTimeout is reached, triggering the re-execution of the side effect, slashing Emma’s insurance deposit
- Alice’s insurance deposit is added to the max_reward of the SFX, bringing it to 1109 TRN
- Edward is quick to claim the re-execution, as the side effect has become very profitable to execute
- Edward executes and confirms the Side Effect, finalizing the XTX
- Edward receives 1109 TRN
- Alice receives 1 ETH and is refunded 2 TRN, the result of the bidding
Scenario C - Emma executes incorrectly, and Edward does not claim the re-execution
- Emma does not execute the Side Effect she had bid on for some reason
- The xTxTimeout is reached, triggering the re-execution of the side effect, slashing Emma’s insurance deposit
- Edward sees this but has his capital tied up in other executions currently
- The XTX is reverted
Alice is refunded the 1010 TRN she deposited on creation.
Release Roadmap
The features outlined in this document are not all implemented yet and will be released in phases.
Release 1
In the first release, t3rn will be able to connect to Kusama via our on-chain light client. This is a one-way state relay, allowing message sending from Kusama to t3rn. As an effect, t3rn will only allow optimistic SFX, enabling one-way cross-chain transactions, like transfers or swaps, from t3rn to Kusama. At this stage, message sending from Kusama to t3rn will not be possible, as this requires Attesters.
Release 2
The second release will include Attesters, enabling two-way message sending and escrow transactions. By then, the Eth2 light client will also be ready, enabling transactions to and from Ethereum.
Stay tuned to our blog and social channels as we divulge our full tech roadmap and updates on the latest engineering news.
Risks
Executing side effects on t3rn also comes with some risks, which Executors must be aware of.
Reverted XTX
An XTX can be reverted if not all of its SFXs are confirmed before reaching the timeout limit. The timeout limit then triggers the reimbursement of the Executors that have confirmed their SFXs in time. The way this works is different between optimistic and escrow side effects.
Optimistic
The Executors will receive the expected reward. These are paid by the offending Executor/s using their reserve bond.
Escrow
The Executor will get their deposits refunded from the escrow contract with the next unlock batch. The transaction cost for this operation is covered by the finality fee, which the user pays on XTX creation. The Executor, however, will receive no reward, losing the amount spent on gas depositing to the contract. Their funds are also locked up during the execution, resulting in opportunity costs.
To minimize the number of reverts, the t3rn Circuit plans to implement a re-execution mechanism. If an Executor does not confirm in time, their insurance deposit will be added to the reward, making it more attractive for other Executors to pick up. This should reduce the number of reverts significantly in the future.
Asset Price Changes
Executors receive their reward once an XTX has reached the “All Steps Confirmed” status. Until that happens, the Executor is exposed to the value of the reward asset changing. The overall effect strongly depends on the asset type of the reward payment. In general, it is beneficial for all network participants to confirm their transactions quickly.
Attester Collusion (escrow only)
Unlocking escrowed SFXs requires a 2/3 Attester majority. As the escrow contract tracks the current Attester set, it can check the submitted signatures, unlocking the deposited funds. Attesters could attempt to collude, finalizing a transaction different from the outcome than that on the t3rn Circuit.
As mentioned, two forms of collusion can occur. These forms result in a loss of funds for either the user or the Executor. These situations only arise if the finality state diverges, which is only possible for escrow transactions.
To prevent this, t3rn has the following layer of security functions in place:
Attester Staking
Attesters are highly-staked network participants that receive inflation for signing escrow unlock transactions. Nominated staking is supported. In the current Attester set, Attesters are periodically tasked with signing the unlock transactions the t3rn Circuit generates. They submit their signatures back to the Circuit, which bundles them into an efficient proof object that can be submitted by Executors to the escrow contract, unlocking the funds.
This enables two obvious Executor slashing points:
On Signature Submission
When the Executor submits its signature for a batch of unlocking transactions, the t3rn Circuit can ensure the signature is valid and that the correct data was signed. A mild slashing event occurs if a faulty signature is detected, costing the Attester some stake. A single Attester may submit a wrong signature by accident (e.g., network lag, bit-flips, etc.), and since this was not a coordinated attack, the network can not be considered to have been in real danger.
On Escrow Unlock
Collusion could happen if the Attesters coordinate and build a fraudulent proof object.
If the attesters achieve a fraudulent ⅔ majority, the escrow contract would have no way of detecting or preventing this. For fishermen, however, detecting this kind of collusion is very easy. They monitor the outcome of executions on the escrow contracts, ensuring the outcomes match. If divergent finalization is detected, they generate an inclusion proof for the fraudulent transaction and submit it to the t3rn blockchain. The offending Attesters are then severely slashed. The slashed funds are expected to cover any potential losses caused by such an event.
A single fisherman is enough to keep all attesters in check so no specialized incentivization models are in place in the first releases of the t3rn protocol. However, as the protocol matures this will be revisited to incentivize and encourage fishermen distribution throughout the t3rn community.
Impossible Side Effects (escrow only)
An attacker could force an execution revert by creating a side effect that is impossible to finalize. For example, an XTX could contain a transfer SFX for an asset that does not exist. By definition, this SFX can never be confirmed, eventually forcing a revert. A fraudulent revert could result in Executors losing the balance tied up in the escrow contract.
As only escrow transactions are prone to revert-collusion attacks, it is rather simple to check if a side effect is impossible to execute. The escrow side effects always involve an asset, so checking the following should suffice as a check:
- The asset exists on the target
- The reward for the side effect covers the cost of acquiring the asset
- The asset can be acquired openly (has liquidity, etc)
Executors should check this for all escrowed side effects for an execution they want to bid on. Alternatively, token lists (like on Uniswap) can also be used.
Overall, understanding the role of Executor incentives is crucial for anyone interested in participating in the t3rn ecosystem and contributing to its growth and success. We invite you to follow us to stay up to date with the latest developments.
Thank you for reading our blog series on Executors.
Part 1: What are t3rn Executors?
t3rn’s vision
The future of Web3 is multichain. t3rn has been built to enable this new paradigm in multichain programming, which is trustless, fail-safe and interoperable. We believe in trust-free collaboration, therefore the network will offer open access for anyone to join and play a critical role as Collator, Executor, Attester or Contracts Registry Builder.
Team t3rn will take a phased approach to rolling out the protocol, gradually releasing different features, showcasing and battle testing the network within a Substrate-based environment first before integrating with some of the foremost ecosystems in the industry.
About t3rn
t3rn is a multichain protocol that brings fail-safe, interoperable execution and smart contract composability to the Polkadot ecosystem and beyond.
t3rn’s ultimate goal is to enable trust-free collaboration between blockchains and to create an ecosystem in which anyone can utilize and deploy an interoperable smart contract, in an ecosystem where developers are fairly rewarded for their contributions.
Turn multichain with t3rn.
Glossary
t3rn Circuit - the name of the t3rn blockchain.
XTX - a cross-chain execution containing N side effects on an arbitrary number of different target chains. Every side effect belongs to a specific execution.
Side Effect (SFX) - a single transaction on a target blockchain.
Insurance Deposit - a small deposit paid by the Executor winning the side effect bidding. This deposit incentivizes Executors to execute the side effects they have won the bid for. Failing to submit the execution proof until the execution expiry will result in the deposit being slashed. The user sets the insurance amount on a per-side effect basis.
Side Effect Reward - The reward the user pays to execute a single side effect. This is the total amount paid to Executors. During the bidding stage, Executors can submit execution bids, lowering the reward amount paid out.
Attesters - Stakers on t3rn used to authorize unlock transactions in the target escrow contract. Users can nominate their TRN tokens to receive a proportional share of the inflation paid to them.
Escrow Contract - A smart contract deployed on the blockchains t3rn connects to. The outputs of escrow side effects are temporarily deposited there until the execution has finalized. An Attester majority is needed to unlock transactions from the contract.
👉 Subscribe to our newsletter: Join 15,000 subscribers for exclusive monthly updates and insights, directly from Maciej Baj, founder & CTO of t3rn. - no spam, unsubscribe anytime.
