Gasless
An ERC-2771 relayer, why ERC-4337 is a dead end on Mezo, and the deposit exception.
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 live on matsnet at maren-relayer.rolandojude18.workers.dev, accepting: true,
with a durable nonce and quota store and a 0.01 BTC/day global gas budget. A sponsored
MarenVault.borrow of 200 MUSD settled in block 15368268, gas paid by the relayer for a signer
holding no BTC. Until it is, you submit your own
transactions and pay BTC gas, and the app says so on every screen. Hosting it is one command
plus funding a hot wallet, and it is the single biggest gap between the demo and the product.
Even once hosted, the first deposit always costs gas. Never read "gasless" as "zero gas".
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 a meta-transaction cannot carry. A user pays for
their first deposit; everything after it can be sponsored.
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.