Gasless
An ERC-2771 relayer, why ERC-4337 is a dead end on Mezo, and the deposit exception.
On this page
Maren's gasless design exists because the obvious answer is wrong, and being able to say why is worth more than the answer itself. A user signs; Maren's relayer submits and pays the BTC gas.
The relayer is hosted on matsnet at maren-relayer.rolandojude18.workers.dev. It sponsors
eligible calls when healthy, funded and within its quota. Availability is checked by the
client; read who pays on the confirmation screen before signing.
BTC deposits require your own BTC for gas. Link creation and approvals can also require gas. If sponsorship is unavailable, the client may offer a direct transaction with its fee shown first. Keep a small testnet BTC balance. This beta uses testnet funds only.
The mechanism: EIP-2612 permit plus ERC-2771 relaying
This is Maren's primary path, and it is exactly what Mezo itself runs in production for its "Get Gas" feature. No bundler, no vendor, no EntryPoint.
The user produces an EIP-712 ForwardRequest and, where MUSD moves, an EIP-2612 permit. No
transaction is created. MUSD supports permit, so approval and action are one signed message.
The relayer checks the signature against its allowlist and per-address budget, then simulates
the call with eth_call before spending any gas.
MarenRelayHub recovers the true sender from the signature, pays the BTC gas, and calls the
target Maren contract. The user ends holding MUSD and a receipt without ever holding BTC.
Why the fee and the work settle together
MarenRelayHub extends MarenForwarder and adds an atomic, signed-fee relay path. One EIP-712
RelayedCall signature covers the target, the exact calldata, the gas, the nonce, the deadline,
and feeToken / feeAmount / feeRecipient. The hub takes the fee and performs the call in
the same frame, bubbling any inner revert, so fee and work settle together or neither does.
This design exists because a natural alternative is broken. OpenZeppelin's
ERC2771Forwarder.executeBatch takes an atomic flag, but the flag governs validation only: a
failed inner call does not revert the batch. A batched fee leg would settle even when the work leg
reverts, charging a user for an action that did not happen. MarenRelayHub therefore reverts
executeBatch with BatchExecutionDisabled(). This was verified with a test that drives a batch
whose work leg reverts and asserts the fee leg settled anyway.
The deposit exception
Value is never relayed. RelayedCall has no value field, and execute rejects a non-zero one.
That is why MarenVault.deposit() is deliberately absent from the relay allowlist: a deposit
carries BTC as msg.value, which this relay path cannot carry. Every BTC deposit needs user-paid
gas. Other actions are sponsored only if their selector is allowed and the relayer is available;
link creation and approvals can require user-paid gas too.
Earn is not sponsored either. MarenEarn is not an allowlisted relay target: the relayer's
/health reports exactly three — marenPay, marenRegistry and marenVault. Both
MarenEarn.deposit() and MarenEarn.withdraw() are therefore user-paid, in BTC, every time.
The relayer's guarantees are narrow and worth stating precisely. It relays only to Maren
contracts, only for known selectors. It rate-limits per address (50 actions a day) and per IP
(200), and the whole service runs under one global BTC gas budget — 0.01 BTC a day on matsnet,
visible at /healthz — that halts relaying for everyone when spent. Each address gets 25 lifetime
sponsored actions. After that, MarenRelayHub.executeWithFee is deployed and ready to take a
signed MUSD fee inside the same transaction, but no allowlisted call carries a fee argument yet,
so no fee can be charged and the relayer answers 402 SPONSORSHIP_UNAVAILABLE rather than
subsidising silently. Wiring the fee path is the next piece of work; refusing is the safe failure
direction meanwhile. It never
holds user funds: compromise of the relayer key costs Maren its gas float, not a user's money.
Why ERC-4337 is a dead end on Mezo
ERC-4337 EntryPoint v0.7 is deployed on Mezo, at
0x0000000071727De22E5E9d8BAf0edAc6f37da032, byte-identical to the Ethereum L1 deployment. It
is also completely inert.
| Check | Result |
|---|---|
| UserOperations ever processed | Zero, per the explorer index |
| Contract verified on the explorer | No |
| Blockscout account-abstraction indexer | 501 Service is disabled |
debug_traceCall on Mezo RPCs | Not implemented, absent from the mezod source |
| Pimlico, Biconomy, ZeroDev, Alchemy, Gelato | Not listed for Mezo |
The root cause is one row. Every ERC-7562-compliant bundler validates a UserOperation by tracing
it, which requires debug_traceCall. Mezo's RPCs do not implement it, so no compliant bundler can
run against Mezo. An EntryPoint with correct bytecode that has processed nothing is the result.
The "zero UserOperations" figure is from the explorer index, not an exhaustive log sweep. As a control against it being an indexing artefact, the same endpoints return over 100,000 transactions for MUSD. The indexer works; the zero is real as far as the index goes. A team that picked ERC-4337 from a diagram would spend weeks discovering this.
Interoperate with x402
Mezo operates its own gasless payment rail: the x402 settlement proxy at
0x402085c248EeA27D92E8b30b2C58ed07f9E20001, live on both networks with a facilitator at
https://facilitator.vativ.io. Because MUSD supports both permit2 and EIP-2612, a buyer
authorises a payment with a single EIP-712 signature: no approval transaction, no gas. Maren
interoperates with this rather than competing with it. A payment rail the chain already operates
is an asset, not a rival.
EIP-7702, accepted, as the upgrade path
Mezo mainnet accepts EIP-7702 type-4 transactions: this was verified by signing one from a
funded-to-zero key and submitting it, and the node decoded the authorization list and rejected on
insufficient balance, not on "transaction type not supported". Combined with the active
P256VERIFY precompile, that is the path to transaction batching, session keys, and
passkey-authorised accounts.
Treat acceptance as the verified claim and live usage as unverified: no delegated account has been observed on-chain yet. Maren does not depend on EIP-7702 for launch. It is the direction of travel once the simpler ERC-2771 mechanism is live and audited.