MIMD-0026 - Ephemeral ATAs

[GabrielePicco]

MIMD: Rent-Pending Ephemeral ATAs

Status

Proposal

Scope

Support rent-pending ephemeral ATAs for:

• canonical SPL Token
• Token-2022

Problem

We need to allow creating an ATA-like account on the ephemeral rollup for a
destination that may not yet have a base ATA or base eATA delegation. This
allows tokens to be sent gaslessly to that destination on the ephemeral rollup,
while the destination can later claim the tokens on base.

The local account should behave like a normal ATA, but settlement must know that
the corresponding base ATA/eATA/delegation may not exist yet and has not been
rent-funded.

Proposal

Introduce a local-only account state:

delegated + rent_pending_ephemeral_ata

The account remains a normal canonical SPL ATA in shape:

pubkey = ATA(owner, token_program, mint)
owner = token_program
data = token account data for token_program

token_program must be either TOKEN_PROGRAM_ID or TOKEN_2022_PROGRAM_ID.

The extra state means the ATA is locally usable, but base eATA/delegation
materialization must be handled during commit or undelegation.

This must not reuse the existing ephemeral account flag, because scheduled
commit currently rejects ephemeral accounts.

Settlement Metadata

The flag alone is insufficient. The scheduled intent must carry explicit
settlement metadata:

RentPendingEphemeralAta {
    ata: Pubkey,
    eata: Pubkey,
    owner: Pubkey,
    mint: Pubkey,
    token_program: Pubkey,
    delegated_payer: Pubkey,
    delegated_vault: Pubkey,
}

token_program is required because the eATA itself is derived only from
[owner, mint], while the ATA address and account layout depend on the token
program.

Creating the eATA remains free because any useful flow already requires moving
real tokens. However, commit or undelegation requires a delegated payer that
covers the base-side settlement cost. That cost is routed to the delegated vault.

The delegated payer must be included in the settlement metadata so the committor
does not need to infer who pays when the base ATA/eATA/delegation did not
previously exist.

Creation Semantics

Local creation is allowed only when:

• the token program is canonical SPL Token or Token-2022
• the pubkey is the canonical ATA for [owner, token_program, mint]
• the mint is owned by token_program
• the account data is a valid initialized token account for token_program
• the account has no delegate, close authority, or native token state

For canonical SPL Token, the local account can be synthesized from the fixed SPL
Token account layout.

For Token-2022, the local account must preserve the Token-2022 account layout
and extensions. It must be created from:

• deterministic Token-2022 account layout derived from the mint extensions

Token-2022 accounts must not be synthesized through the legacy SPL Token packing
path.

If the base ATA or eATA already exists, do not override the local ephemeral ATA
state. This also applies when the local ATA was produced by eATA projection.
Base creation is idempotent, and the eventual balance is reconciled by summing
balances during commit or undelegation.

Commit And Undelegation

For rent_pending_ephemeral_ata:

1. Skip normal DLP metadata lookup, because it may not exist yet.
2. Charge the recorded delegated payer for settlement cost and credit the
   delegated vault.
3. Materialize base eATA/delegation idempotently if missing.
4. Materialize the base ATA idempotently when undelegation needs a real token
   account.
5. Commit the local ATA balance into the eATA.
6. Sum with any existing base eATA or ATA balance instead of replacing it.
7. On undelegation, pay required rent and restore the final canonical ATA on
   base using the recorded token_program.

After successful settlement, clear the rent-pending state.

Safety Rules

• Never infer rent-pending state from lamports or token data alone.
• Do not expose local rent lamports that SPL CloseAccount could withdraw.
• Preserve Token-2022 account owner, data length, and extension state.
• Reject incompatible existing base state instead of overwriting it.
• Keep eATA creation free; costs enter only at base commit/undelegation through
  the delegated payer and are credited to the delegated vault.
• Require the delegated payer itself to be delegated and writable for the
  settlement flow.

Rationale

This keeps the ER account user-facing as a normal ATA while making the missing
base-rent/delegation state explicit for settlement. It avoids forcing the path
through ordinary DLP commit metadata before that metadata exists. Token-2022
support is viable as long as the token program is carried explicitly and the
implementation preserves Token-2022 layouts instead of rebuilding them as legacy
SPL Token accounts.