Gas paid by the protocol, in consensus not a relayer, not a paymaster

Limonata — Wed, 01 Jul 2026 23:29:47 +0000

Most “gasless” blockchain experiences are not actually gasless.

The user may not pay the fee directly, but somewhere behind the scenes there is usually a relayer, an ERC-4337 paymaster, a bundler, or an off-chain service covering the transaction.

Those systems can work well, but they also introduce more infrastructure, more private keys, more failure points, and more contracts that need to be maintained and audited.

With Limonata, I wanted to try something different:

What if gas sponsorship was handled directly by the blockchain itself?

Limonata is an independent EVM Layer 1 built with the Cosmos SDK and cosmos/evm.

It has its own validators, its own CometBFT consensus, full EVM compatibility, and Chain ID 10777.

The unusual part is that gas sponsorship is handled directly in consensus.

No relayer.

No bundler.

No paymaster contract.

No special transaction format.

The chain itself decides whether a transaction qualifies for sponsored gas.

Before going further, I want to be clear about one thing:

Limonata is currently a testnet. Testnet LIMO has no monetary value. This is a technical invitation to build, test, and find problems before mainnet.

How protocol-level gas sponsorship works

On a normal EVM network, the sender must hold the native coin and pay the gas fee.

On Limonata, every transaction first passes through the chain’s ante handler.

The ante handler is the consensus-level validation step that runs before transaction execution.

It checks the transaction, verifies the sender, calculates the fee, and determines whether the protocol should sponsor the gas.

When a transaction qualifies, the gas is paid from an on-chain sponsorship pool.

The transaction is included in the block normally, but the sender’s balance is not reduced.

Because this logic exists directly inside the chain, developers do not need to operate a separate gas infrastructure system.

There is no relayer server to maintain.

There is no relayer private key to protect.

There is no UserOperation wrapper.

There is no bundler.

There is no paymaster contract to deploy and secure.

The base layer handles the sponsorship.

The honest limitation

There is one important detail that users need to understand.

The account must be able to afford the gas before the chain decides to sponsor it.

That means an account with a completely zero balance may still receive an insufficient funds error, even if the transaction would otherwise qualify for sponsorship.

The solution is simple:

Claim a small amount of test LIMO from the faucet once.

After that, sponsored transactions do not reduce the balance.

That small initial amount acts as a proof of funds and creates a basic anti-Sybil cost.

The account must have something, but the sponsored gas itself is not deducted.

This is not perfect account abstraction, and I do not want to pretend that it is.

The goal is to make onboarding significantly easier while still keeping a basic economic barrier against mass-created empty accounts.

Daily sponsored gas allowance

Every account receives a daily protocol-paid gas allowance.

The allowance currently includes:

A cold-start allowance of 0.1 LIMO per day
An additional allowance based on the amount of LIMO held by the account
A maximum daily allowance of 10 LIMO

At the low fees currently used on the testnet, even the cold-start allowance can cover a large number of ordinary transactions.

The balance-based bonus also creates an anti-Sybil limit.

Creating thousands of empty wallets does not provide unlimited free gas. Each wallet only receives the small base allowance unless it holds more LIMO.

When an account reaches its daily sponsorship limit, transactions do not stop working.

The sender simply begins paying gas normally.

Gas sponsorship is therefore conditional, not unlimited.

The system is implemented in a native module called x/gassponsor.

That module manages the protocol sponsorship pool, daily account allowances, eligibility rules, and allowance resets.

Developers can sponsor transactions to their contracts

The protocol allowance is useful for ordinary activity, but some applications need more predictable coverage.

Imagine a game, marketplace, social application, or trading platform that processes thousands of user interactions.

The developer may want every interaction to feel gasless without forcing users to acquire the native coin and without operating ERC-4337 infrastructure.

For that use case, Limonata includes another native module called x/sponsorpool.

It is exposed to the EVM through a precompile at address:

0x901

A simplified interface looks like this:

interface ISponsorPool {
function deposit(address contractAddr, uint256 amount) external;

function withdraw(address contractAddr, uint256 amount) external;

}

A developer can deposit LIMO and assign it to a specific contract.

Transactions sent to that contract can then be sponsored from the developer’s deposit until the balance runs out.

The sponsorship pool is:

Permissionless
Withdrawable
Non-inflationary
Native to the chain

There is no application allowlist.

Any developer can fund sponsorship for a contract.

The deposited LIMO remains controlled by the developer and can be withdrawn.

The module does not mint new coins to cover the gas.

The developer funds the experience directly.

The idea is similar to ERC-4337 paymaster semantics: the application pays the gas for its users.

The difference is that the sponsorship mechanism already exists as a native chain primitive.

The developer does not need to deploy and secure an entire paymaster system.

Gasless does not mean costless

I dislike gasless marketing that acts as though transaction costs disappear.

They do not.

When a transaction is free for the user, someone else is paying.

On Limonata, collected fees are processed by the x/squeeze module.

The current fee split is approximately:

40% burned
10% returned to the protocol gas sponsorship pool
50% distributed to validators

The protocol-sponsored account allowance is funded through the chain’s fee system.

Contract-specific sponsorship is funded directly by developers.

This creates two separate paths:

Protocol sponsorship for regular accounts
Developer-funded sponsorship for specific contracts

The long-term economics still need to be tested carefully before mainnet.

The important point is that the system does not pretend gas has no cost.

It changes who pays and moves the decision into consensus.

Passkey transactions with Face ID and Touch ID

Gas is only one part of the onboarding problem.

The other major problem is the wallet experience.

Most normal users do not want to install a browser extension, protect a seed phrase, purchase a native coin, and then learn how gas works before using an application.

Limonata includes native support for secp256r1 signatures through RIP-7212.

This allows wallets to use WebAuthn passkeys to authorize transactions.

A user can sign using:

Face ID
Touch ID
Windows Hello
Another passkey-compatible authenticator

The goal is to allow blockchain applications to feel more like traditional applications.

The user creates a wallet using a device passkey, signs with biometrics, and interacts without manually managing gas for every transaction.

The passkey implementation is still experimental and will require security auditing before mainnet.

It is enabled on the testnet specifically so developers can test it publicly and help identify problems.

You can try the live demo here:

https://limonata.xyz/demo

Anti-MEV development

Limonata is also experimenting with encrypted transaction ordering.

The current x/encmempool implementation uses a commit-reveal mechanism.

I want to be careful about how this is described.

The current version is not full threshold encryption.

It introduces delayed visibility and ordering rules, but it does not provide complete MEV protection, especially when a single validator controls transaction ordering.

The planned threshold-encrypted mempool is designed to go further.

The intended flow is:

Transactions are submitted in encrypted form.
The transaction order is fixed before validators can read the contents.
Transactions are decrypted only after the order is committed.
Decryption requires cooperation from at least two of three keypers.

The threshold-encrypted version is intended to activate through a governance upgrade.

The foundation is being built and tested now, but I would rather describe the current state honestly than market unfinished work as complete.

Try Limonata

You can add the network using:

Chain ID: 10777

RPC: https://rpc.limonata.xyz

Claim test LIMO once from the faucet:

https://faucet.limonata.xyz

Deploy a contract and test a sponsored transaction using the quickstart:

https://github.com/Limonata-Blockchain/limonata-quickstart

Try the gasless and passkey demo:

https://limonata.xyz/demo