sRFC 34 - Standardized Relayer API
Summary
This RFC proposes a standard API that teams can adopt/implement to enable on-chain activity without end users holding SOL (gas abstraction/gasless transactions). Creating a network of relayers would enable end users, or companies, to choose their preferred relayer, or provide sponsored transactions with certain partnerships. Creating an up to date relayer also allows teams to build faster as they would not have to build their own. The ultimate aim is to create a marketplace of permissionless relayers with differentiated features that improve user experience.
Motivation
Many companies currently create their own version of a relayer (or Paymaster in EVM speak) to support their own business and use case. Historically, teams tend to fork Octane and re-work it to their needs. This, however, is less than ideal as it has not been updated in three years, was not audited, and is not production ready. Additionally, relayers have proven themselves to be a required primitive in many scenarios which would benefit from composability and a permissionless standard. Solana thrives on well established primitives rather than copy pasting code for each use case.
Use Cases
This relayer is designed to be flexible to support the major flows teams encounter. This means that it can provide customers a way to transfer SPL tokens, or execute an arbitrary transaction without needing to own any SOL. The relayer may choose to sponsor transaction fees for a transfer completely or request a fee to be received in the SPL token that is transferred. Here are the main use cases I am targeting:
- Payments: Transferring tokens without needing SOL.
- Smart wallet activity: As a PDA cannot be a fee payer, it requires a relayer or another party to pay transaction fees. Having a standardized set of relayers which can support these transactions increases their proliferation and usage.
- Embedded wallets: Embedded wallets are often used as a way to abstract the complexities of wallets away from end users. As an example, in game actions that utilize an embedded wallet can use a relayer to execute and sponsor game activity.
Proposal
Important: This spec is purposefully not prescriptive on the implementation details of the relayer and instead is purely focused on utilizing a common API interface. Each relayer provider can differentiate on features and capabilities. As an example, it may be worthwhile for one relayer to add lighthouse guards to transactions but not useful for another. Additionally I expect a number of “add-on” standardized features to be developed and provided by different providers such as Jito bundling.
An Rust based implementation named “Kora” is in progress by Solomon here.
Below is an overview of the proposal. To see the full implementation proposal, please refer to this doc and provide direct comments where desired.
Relayer RPC HTTP Methods Overview
| Method Name | Description | Required Parameters | Result |
|---|---|---|---|
| feeEstimate | Estimate the fee for an arbitrary transaction using a specified token. | transaction, fee_token | estimated_fee, conversion_rate |
| transactionTransfer | Create a transfer transaction for a specified token, sender, and recipient. The token supplied will be assumed to be the token to also be used for fees. Returns a partially signed transaction. | amount, token, source, destination | transaction, fee_in_spl, token, fee_in_lamports, valid_until_blockheight |
| transactionPrepare | Prepare a transaction by adding relayer-specific instructions. Returns a partially signed transaction. | transaction, fee_token | transaction, fee_in_spl, fee_token, fee_in_lamports, valid_until_blockheight |
| transactionSign | Sign a prepared transaction without submitting it to the blockchain. | transaction | transaction, signature |
| transactionSignAndSend | Sign and submit a transaction to the blockchain. | transaction | transaction, signature |
| transactionSend | Submit a fully signed transaction to the blockchain. | transaction | signature |
| getSupportedTokens | Retrieve a list of tokens supported by the relayer for fee payments. | (none) | tokens (list of token metadata) |
Key Terminology
- transaction: Base64-encoded serialized Solana transaction. This could be a signed or unsigned transaction.
- signature: Unique “transaction hash” that can be used to look up transaction status on-chain.
- source: Source wallet address. The relayer is responsible for deriving and the TA.
- destination: Destination wallet address. The relayer is responsible for deriving and creating the TA if necessary.
- fee_token: Token mint address for the fee payment.
- fee_in_spl: Fee amount the end user will pay to the relayer to process the transaction in spl tokens in the smallest unit of the spl token (no decimals)
- fee_in_lamports: Fee amount in Lamports the Paymaster estimates it will pay for the transaction.
- valid_until_block_height: Expiration block height for time-sensitive operations.
- tokens: Array of supported token metadata (e.g., symbol, mint, decimals).
- features: Array of features enabled by the relayer (e.g., bundle support, sponsorship).
Note: I am in no way married to the name “relayer”. I just don’t really want to use paymaster.