Tezos Gas Station

We at Madfish want to allow users to send their FA1.2 - FA2 tokens without holding XTZ on the user’s account. As a solution, we are developing a prototype of a Tezos Gas Station Relayer.

Architectural overview of a Gas Station

Gas Station is a backend application with a few endpoints for accepting permits and parameters. We imagine wallet-relayer interoperation as follows:

Wallet asks the server if it supports a specific TZIP-17 compatible token and its current price. It forms the desired transaction and creates a permit for the gas station to be able to send it on the user’s behalf. Then the user crafts a transfer to reward GSN for gas in tokens and again permits for a third party to submit it to the Tezos network. All this info then sent to the server using the usual HTTP POST request. The server validates all the data and sends it to the network paying for the gas if fees are satisfactory. Transactions being batched provides guarantees of atomicity: either transaction is done as a whole or fails completely.

At the current stage, we have created an early stage prototype of the gas station that accepts next requests:

POST requests:

  • /submit - accepts JSON with permit params and call params.

GET requests:

  • /supported_tokens - get which tokens are supported by the specific relayer

  • /price <token_address> - get current gas price for a specific token

  • /address - fees destination address


Arbitrary call submission consists of two parts and both are mandatory and thoroughly validated by the server. The first part is a call and parameters intended to be called by the user and the second part is a Transfer to the gas station address. Both of these parts have corresponding permits. After making sure received parameter hashes are matching and signed appropriately, server performs transactions in the following order:

  • Submit user’s action permit and fee payment permit
  • Call to user’s action
  • Transfer fee to our backend’s address on behalf of the user

All these transactions are batched to ensure atomicity and decrease gas price.

Optimized transfer payload

In case a user makes a simple transfer, we may take advantage of FA2’s ability to perform a few transfers in a single call and optimize it so only one permit and one contract call is performed, making it considerably cheaper.


As for now, no discovery mechanisms are planned: wallets will just have a whitelist of known gas stations and will poll them to discover if they are available. But it is possible to implement some kind of DNS system or just a simple endpoint /neighbours advertising recommended backends available to interact with.

Our next steps

We will continue to explore the possibilities of creating a gas station on the Tezos network. The first implementation is planned for our wallet. We’ll be sharing our progress with the community and discussing possible ways for improvement.


We would appreciate any feedback and suggestions on relayer implementation, so don’t hesitate to leave your comment or write us in our telegram or discord communities.


I see the benefits in regards to gaming. The game sets up the wallet for the user and user jumps right in without first needing to go to an exchange to buy XTZ. Of course, the user can use XTZ to buy in-game items but doesn’t need to to get started.

I’m I understanding this correctly?

Yeah, you are right. It may prove benefitial not only to games, but to apps and DeFis in general. Basically it provides frictionless on-boarding for new users who might not know how or not care enough to buy XTZ in advance.

1 Like

Great idea for gaming and defi alike.
Can you not take a fraction of the fa Tokens to pay the fees?
I’ve seen other apps do this.
For example on mirror protocol it may cost me part of my mir

As far as we know this approach is used by token developers themselves. To incentivise using and on-boarding they even might go as far as paying for user transaction altogether. We think it will be possible to have relayers which are willing to send transactions without taking a fraction later on, when some kind of fee price auction is implemented.

1 Like

I love this idea - get it implemented! I can easily see how useful this would be for DeFi dapps - e.g. a dapp which pays interest in the form of FA2 tokens which trade on DEXes/CEXes - no need for me to pay gas fees or have XTZ in my wallet to transact the FA2 token. Contrary to people thinking that this disincentivizes people from using XTZ, I think it will only expand the ecosystem further.

Just found my way to this post. Super interesting! This looks like it could turn out to be extremely useful. How is development going? Any updates since the initial post?

I can imagine this being a great way to onboard users from other crypto ecosystems onto Tezos without them having to pre-purchase XTZ from a centralized exchange in order to interact with the network.

Would the following be possible? Imagine a user who only owns Ether, but they would like to bring their Ether onto Tezos to provide liquidity, or to yield farm, but they can’t pay any XTZ fees as they don’t own any yet. Could the user initiate a swap from ETH to ETHtz for instance, or swap some ETH to XTZ via the relayer in order to get a few XTZ for gas fee purposes?

Another use case I can envision revolves around utilizing a Sapling shielded-pool on Tezos. My understanding is that all fees need to be paid using un-shielded Tez as the shielded-tez themselves are just tokens. Could someone interact with the shielded-pool via the relayer, and also withdraw from the shielded-pool via the relayer?

Hi, we have researched and developed Gas Station Relayer server which can perform simple token transfer on behalf of the user. It can be configured to work with permit-enabled token and is able to fetch its price from Harbinger price feed.

  • For interacting with this relayer we have developed decentralized web application prototype. We are still testing and improving it as it is still a bit early in development
  • For the whole system we are currently working on overcoming some UX hurdles as per current system concept user has to sign permit payload twice: once for gas cost estimation