Sign in Subscribe

GARP: Standardizing AMB Relayer Incentives

Cata Labs

• 7 min read
GARP: Standardizing AMB Relayer Incentives

Arbitrary Messaging Bridges (AMBs) play an integral role in the cross-chain world, operating as communication pathways connecting different blockchains. These bridges need help from relayers to actually deliver messages from one blockchain to another.

However, there's a problem. The way relayers are rewarded for their work isn't robust or standardized. Right now, relayers often end up spending more money than they make. Sometimes, they don’t make any money at all–with the burden of operating them falling onto the core team, the protocol’s Foundation, or external entities awarded grants to manage them.

Without a healthy relayer network, AMBs cannot deliver cross-chain messages in a timely manner–which in turn affects user experience and also opens up transactions to pernicious MEV extraction. This situation highlights the need for a better system to motivate relayers and make sure AMBs work smoothly for connecting different blockchains.

The Challenge of AMB Relayer Incentives

“Show me the incentives and I will show you the outcome.” – Charlie Munger

The efficacy of any system lies in its incentives. The current landscape of AMB relayer incentives is marked by inconsistency, inefficiency, and challenges that hinder the optimal functioning of cross-chain interactions. 

In the current state, many AMBs suffer from non-standardized relayer incentives, leading to a range of issues:

Trust assumptions on relay: Some relaying mechanisms rely on a few centralized entities in order to facilitate the payment process. This introduces an element of trust, which harms the resilient and censorship resistance of AMBs. In cases where these relayers fail to do their job, a new payment has to be initiated.

Unspent gas not refunded: Estimating gas costs for transaction calls is a complex task due to the variability of gas prices. As a result, users often overestimate gas, leading to unnecessary fees and inefficiencies in true price execution (i.e., price quote including gas fees).

No acknowledgements: Acknowledgments (acks) are crucial for application logic and user experience. Acks allow for the origin chain to have knowledge that the outbound message was received on the destination chain, which in turn allows for the clean up of state on the origin chain. Unfortunately, many AMBs do not support acks. In cases where acks are supported, users often face the hassle of figuring out how to get gas on the destination chain, or the application protocol is left to manage gas on all the chains where it's deployed. This adds complexity and inconvenience to the user experience.

Non-standardized anything: Diverse interfaces, payment processes, payment formats, and address formats make it difficult to relay for multiple AMBs.

These challenges not only hinder the seamless flow of cross-chain transactions but also increase the centralization of AMBs to a handful of relayer operators.

Introducing GARP: Incentivization Contracts

The journey toward a more efficient and reliable AMB ecosystem begins with a standardized implementation for relayer incentives. Today, we introduce General Automatic Relayer Payment (GARP), an incentive layer for all AMB relayers.

GARP places a smart contract as an intermediary between applications and AMBs, serving as the source-of-truth to define how relayers are paid based on the observed (and verified) messages delivered. Since the contract sits on-chain, its logic is governed by the underlying blockchain rather than by off-chain logic. This also allows the contract to augment the AMB with additional logic:

  • Measuring the gas used by the application
  • Reliably sending a message back to the source chain
  • Paying the relayer in a standardized token

GARP is also trust-minimized because any relayer can claim the incentive after confirming the delivery of a message on the origin chain. Because it’s a smart contract, GARP is generalized and can be implemented for any VM–with its reference implementation written in Solidity for EVM chains. For applications that heavily rely on acknowledgments, GARP has an opt-in feature to specifically incentivize the timely delivery of acknowledgements.

We see GARP as a lightweight, trust-minimized solution to the problems we’ve observed in the current AMB relayer landscape, eliminating off-chain complexities and introducing a standardized incentive mechanism.

GARP: A Primer

struct IncentiveDescription {
    uint48 maxGasDelivery;
    uint48 maxGasAck;
    address refundGasTo;
    uint96 priceOfDeliveryGas;
    uint96 priceOfAckGas;
    uint64 targetDelta;
}

At the core of this solution lies the IncentiveDescription struct, comprising six essential variables that define the relayer incentives:

  • maxGasDelivery: The maximum gas consumed by the contract on the destination chain.
  • maxGasAck: The maximum gas consumed by the contract on the source chain (ack).
  • refundGasTo: An address to which any unspent incentive is refunded.
  • priceOfDeliveryGas: The gas price on the destination chain, denominated in the source chain's currency.
  • priceOfAckGas: The gas price on the source chain, denominated in the source chain's currency.
  • targetDelta: The ideal time between execution on the destination chain and ack, offering the option for strong ack incentives.

Relaying incentives are stored strictly on the source chain with no communication to the destination chain except maxGasDelivery.

The incentive variables can vary in size, for EVM they are set so all fit into 2 storage slots. For other implementations, the address size, slot size, or gas price could be defined differently and should result in a different storage layout to optimize for gas.

Measuring Gas

The issue of gas in this context involves several intricate factors: How gas usage is measured, how it's valued, and how its usage limits are enforced.

Measuring the exact gas cost of a transaction call on the EVM is a challenge. Similarly, enforcing a precise cap on the gas spent within a call while allowing additional logic to execute is not feasible. This situation remains consistent for non-EVM chains as well.

Gas enforcement is done by limiting the external call to exactly maxGas<Delivery/Ack>. In the EVM, this is enforced by setting a gas limit for the external call.

Calculating gas spent starts from the earliest feasible point and continues until the latest possible moment, always including the external call. However, this measurement isn't perfect due to logic occurring both before and after the phase where gas cost can be accurately measured. Furthermore, since only maxGas<Delivery/Ack> has been accounted for in terms of payment, any excess gas usage (e.g., the application using exactly maxGas) isn't directly covered by the incentives. The gas expended on the destination chain is sent back to the source chain alongside the acknowledgement. In cases where a chain is unable to measure gas, it should return maxGas as gasSpent.

Gas pricing is consistently based on the currency of the source chain. This approach simplifies the user experience while retaining a high degree of flexibility. For messages of lower priority, priceOfDeliveryGas can be set accordingly or even to zero. Similarly, if an ack holds no critical importance to the application, priceOfAckGas can be set at a similarly low level. Ultimately, the relay incentive is calculated as the minimum of spentGas<Delivery/Ack> and maxGas<Delivery/Ack>, multiplied by the priceOf<Delivery/Ack>Gas. The difference between the combined sum of both and the maximum value is then refunded to the designated refundGasTo address.

Gas pricing is consistently based on the currency of the source chain. This approach simplifies the user experience while retaining a high degree of flexibility. For messages of lower priority, priceOfDeliveryGas can be set accordingly or even to zero. Similarly, if an ack holds no critical importance to the application, priceOfAckGas can be set at a similarly low level. The final relay incentive is then computed as min(spentGas<Delivery/Ack>, maxGas<Delivery/Ack>) · priceOf<Delivery/Ack>Gas for both Delivery and Ack. The difference between the sum of both and the maximum is refunded to refundGasTo.

Strong Ack Incentives

The idea is that an ideal execution time between execution on destination and the delivery of the ack exists: targetDelta. If more time than targetDelta has passed, then the ack should be more incentivised. At the same time, if less time has passed then the delivery incentive should be higher. The following pseudo code is how the code should treat the 2 cases (less and more time):

ackFee = spentGasAck * priceOfAckGas
deliveryFee = spentGasDelivery * priceOfDeliveryGas
// If the time it took to get the ack back is exactly targetDelta, then exactly the 2 fees are delivered.
if (ackExecutionTime == targetDelta) {
    return (deliveryFee, ackFee)
}

compared to the time passed.
if (ackExecutionTime < targetDelta) {
    return (
        deliveryFee + ackFee * (targetDelta - ackExecutionTime)/targetDelta,
        ackFee - ackFee * (targetDelta - ackExecutionTime)/targetDelta,
    )
}

// If less time than expected, then the deliveryFee should be linearly higher 
// If more time than expected, then the ackFee should be linearly higher compared to the time passed.
if (ackExecutionTime > targetDelta) {
    // If it took more time than 200% of targetDelta then the deliveryfee should be 0.
    if (ackExecutionTime >= targetDelta * 2) {
        return (0, ackFee + deliveryFee)
    }
    return (
        deliveryFee - deliveryFee * (ackExecutionTime - targetDelta)/targetDelta,
        ackFee + deliveryFee * (ackExecutionTime - targetDelta)/targetDelta,
    )
}

The exact implementation is allowed to vary slightly to optimize for gas.

When using this scheme, it is very important that targetDelta is set to more than the time it takes for messages to get confirmed on the destination chain as otherwise some of the delivery gas is always given to the ack relayer.

This definition works well in combination with the single relayer addition: If a single relayer is prompt, then not only do they get the full delivery and ack fee but they also save gas because of the lower complexity associated with a single transaction.

It is very important to remember that the ack "clock" starts ticking from when the destination call has been executed not when the first message was emitted. As a result, if it takes 30 days to send the message from the source to the destination but the ack from the destination to the source only takes 10 seconds, then it is those 10 seconds that are counted against targetDelta. As a result, the base maxGasDelivery will incentivize the delivery of the message to the destination until it has been delivered.

Use GARP Today

We see general, standardized relayer incentives as a public good that will benefit the entire crypto community. GARP is an open-source solution that's ready and available for use, as well as has been thoroughly audited by Veridise. You can access the repository through this link: https://github.com/catalystdao/GeneralisedIncentives 

The power of GARP is being demonstrated in real-world scenarios, as seen with its integration with Wormhole. However, the potential of GARP extends beyond this, and we are actively seeking further integration of GARP into other AMBs, along with a broader adoption by relayers.

If you're interested in using GARP into your cross-chain relayer stack, we encourage you to get in touch with us on Telegram. Your involvement is a crucial step in realizing a more robust, decentralized cross-chain future.

Sign up to keep up to date.

Enter your email
Subscribe