Users would cover network fees with SPL tokens, expanding Solana’s accessibility.
Relays would automate fee calculation and transaction preparation.
On January 7, 2025, developer Ilan Gitter submitted the proposal called “sRFC-34: Standardized Relayer API” for the Solana network. Its objective is to allow users to interact in this chain without the need to own SOL, its token native, to pay network fees (gas fees).
The acronym «sRFC-34 (Solana Request for Comments)” They refer to a specific proposal within the Solana ecosystem. The “34” indicates the number within this series of documents.
For its part, the nomenclature “Standardized Relayer API translates as “Standardized Relay API”.
The sRFC-34 proposal defines a framework through a API specific (Application Programming Interface) to standardize the operation of the relayers (relays) that manage user transactions.
What are relayers in Solana and what are they for?
Initially, these relayers They are a relevant component for the decentralized finance ecosystem (DeFi).
In the context of Solana, the relayers are computer programs operated by companies or institutions that act as intermediaries for facilitate interaction between users and the network.
These relayers pay network fees in SOL on behalf of users and, in return, give them charge them the equivalent rates in some token SPL (Solana Program Library, a standard for tokens on Solana, similar to Ethereum’s ERC-20).
This method is known as “gas abstraction” and aims to make the user experience simpler by eliminating the requirement to hold SOL to pay transaction fees.
Removing this requirement would expand the accessibility of Solana to users who do not own SOL. Additionally, it would allow Solana-based projects to use their own tokens to cover operating costs.
How would the sRFC-34 proposal work?
Currently, each Solana user must have a sufficient amount of SOL in your wallet to cover network fees, even when you transact with others tokens SPL.
The Gitter’s proposal establishes a common format for transaction data that must be relayed. Thus, the relayers could interpret and process information uniformly, which would facilitate communication between different applications and services that use relayers.
Among some of the functionalities that the Gitter API would introduce in the relayers They highlight estimating fees, preparing transactions with specific instructions, and signing and sending transactions directly to blocks.
A user or application can send a transaction to a relayer using the standardized Gitter API and the relayerthen, is responsible for relaying the transaction to the Solana network. Then the relays They must confirm whether transactions have been processed and confirmed on the network.
If something goes wrong, the relayer can communicate what it was and how it can be fixed.
The standardization of the relayers I would ensure that they can be integrated using the same pattern in different applications to handle transactions without end users having to worry about gas fees.
This standard implementation would enable any application within Solana to interact with the relayers predictably, eliminating the need for each developer to implement custom solutions.
At the same time, the proposed API and the standardization of the behavior of the relayerswould provide performance and seamless interoperability between different applications within Solana.
The relayers uniforms would allow for efficient transaction management, such as fee calculation and transaction preparation, which would optimize the time and resources needed to process them.
However, the proposal must still be discussed and accepted by the network’s developers and validators before its implementation.
Possible use cases, according to the developer behind sRFC-34
Besides that a relayer can pay a network fee on behalf of the user, Gitter raised two additional use cases for his proposal.
First of all, for the Program Derived Addresses (PDAs) in Solana. These are special addresses that cannot pay transaction fees themselves, and allow you to create addresses that only a program can use to sign transactions. Relays do not have the authority to move funds themselves. They can only execute transactions that have already been validated and authorized by the program that controls the PDA.
The PDA acts as a gatekeeper that allows or blocks transactions based on programmed instructions.
What relays do is facilitate the execution of transactions that meet the pre-established conditions by the programs created by the PDAs. Here, the relay would be essential because it can pay the fees necessary for a PDAs take actions in Solana.
As provided by Gitter, having standardized relays means that more developers can integrate and use PDAs in your applications without worrying about how to handle fees, which could increase the adoption of this type of smart wallets.
Secondly, the developer argued that this standardized functionality can be leveraged by in-app wallets.
Are there risks in implementing a relay standard?
Although the proposal presents potential benefits, its implementation could face technical and operational challenges.
The network could depend on the availability and correct functioning of the relayers. Given an interruption in its service, users’ ability to carry out transactions would be affected.
One might also wonder if the fact that the relayers handle fee payments on behalf of users would open doors to possible vulnerabilities if they are not implemented correctly.
Ultimately, although the change seeks to facilitate transactions, it could decrease demand for SOL as token native, indirectly affecting its use in other aspects of the ecosystem and, ultimately, its market price.
