feat: add MegaETH charge payment method

[0xBreadguy]

Adds the MegaETH payment method (megaeth) with a charge intent for one-time ERC-20 token transfers on MegaETH.

What is MegaETH?

MegaETH is an EVM-compatible blockchain with 10ms block times and sub-second finality, making it well-suited for real-time machine-to-machine payments where settlement latency is critical.

Spec overview

The MegaETH charge method uses Permit2 as its sole asset transfer mechanism. The client signs an off-chain EIP-712 PermitWitnessTransferFrom message; the server submits the transfer on-chain. This works with any ERC-20 token via Uniswap's universal approval contract — no per-token implementation required.

Key features

• Permit2-only transfers — universal ERC-20 compatibility through a single, audited contract. No third-party token-level dependencies.
• Sub-50ms settlement — MegaETH's 10ms blocks and realtime_sendRawTransaction RPC enable inline receipt confirmation.
• Payment splits — up to 8 additional recipients per payment for platform fees, revenue sharing, and referral commissions.
• Hash payload — alternative credential type for clients that broadcast transactions directly.
• Fee sponsorship — servers can sponsor gas (negligible on MegaETH, <$0.001/tx) for a seamless client experience.
• Structured errors — RFC 9457 Problem Details with standard problem types from the core spec.

Design decisions

• Permit2 over EIP-3009: We evaluated EIP-3009 (transferWithAuthorization) but chose Permit2 exclusively to avoid third-party risk from per-token implementation requirements and the fragility of forwarder contracts. Permit2 also offers better extensibility via witness data and batch patterns.
• No assetTransferMethod field: Since Permit2 is the only method, there's no need for a discriminator. This keeps the spec surface minimal and eliminates a dual code path for implementers.

Networks

Network	Chain ID	RPC
Mainnet	4326	https://mainnet.megaeth.com/rpc
Testnet	6343	https://carrot.megaeth.com/rpc

Checklist

[x] Follows method template structure
[x] IETF-conformant structure (Abstract → Intro → Requirements → Terminology → Body → Security → IANA)
[x] RFC 2119 keywords used correctly
[x] Security Considerations covers replay protection, cross-chain replay, hash credential binding, fee payer risks, approval scope, and hot wallet security
[x] IANA registrations for method (megaeth) and intent (charge)
[x] Internal cross-references resolve
[x] Examples with realistic base64url-encoded values that decode correctly
[x] ABNF appendix included
[x] Rebased on main

───

This specification was prepared with AI assistance. All content has been reviewed and verified for correctness by the author.

[brendanjryan]

Thanks for submitting!

Are there any megaeth specific implementation details in this proposal? Is permit2 native on megaeth?

[0xBreadguy]

Thanks! Yeah, there are a few MegaETH-specific things baked in:

• realtime_sendRawTransaction — MegaETH RPC method that returns the receipt inline (so no polling).
• 10ms blocks — the whole spec assumes onchain confirmation is fast enough to happen within the HTTP request/response cycle, which is a unique value prop MegaETH

And yep, Permit2 is deployed on MegaETH at the canonical Uniswap address (0x000000000022D473030F116dDEE9F6B43aC78BA3) — same deterministic deployment as Ethereum, Base, etc.

[brendanjryan]

• 10ms blocks — the whole spec assumes onchain confirmation is fast enough to happen within the HTTP request/response cycle, which is a unique value prop MegaETH

Does this change the overall control flow in any way, which is defined by the spec, or the upstream implementation?

I think given the high amount of overlap with the core EVM spec (just RPC + block time which is different on all chains) I would prefer to merge this into a core EVM spec, as this will allow us to adopt this more quickly across multiple applications.

Position here would change if there were more divergences from other chains which would change interfaces / control flow

[0xBreadguy]

No, I think that's appropriate if we want to begin a consolidated implementation.

Most of what MegaETH offers is just heavily optimized EVM and not necessarily materially different EVM (gift and curse). The stuff like RPC is an implementation detail.

With chain-specific specs you could maybe see some divergence on things like split parameters, but can also try to account for that when consolidating.

I'd love to collaborate on an evm spec.

[gakonst]

I think you can get away with just a simple general EVM charge intent assuming no-ERC4337 and we can iterate from there, feel free to reword/open new PR, and we can consolidate it w/ the Sei folks' work as well! (Closing for cleanliness)