MIMD 0013 Native SPL support

[GabrielePicco]

Description

Since ATAs cannot be delegated, using SPL tokens in the ER currently requires a wrapper program that creates pseudo-ATAs, e.g.: ephemeral-rollups-spl.

While this works, it has several disadvantages:

1. More complex developer experience (DevEx) and user experience (UX)
2. Wallets and SDKs assume standard usage of ATAs and the token program
3. The standard token program cannot be used directly by the fee payer

Proposal

Create a default implementation that natively maps to ATAs during cloning in the validator. This would allow:

1. Normal use of token programs in the ER
2. Fewer changes required for smart contracts using SPL tokens to integrate with the ER

Proposed Implementation

At a high level, the wrapped program is simple. It contains instructions to:

1. Initialize a pseudo-ATA
2. Delegate a pseudo-ATA
3. Undelegate a pseudo-ATA
4. Top up a pseudo-ATA
5. Withdraw from a pseudo-ATA

A pseudo-PDA is derived from [owner, mint, ephemeral_spl_program] and contains a balance field, which represents the token balance.

Top-up and withdraw operations add or subtract funds from a global protocol vault (one vault per mint), while respecting and updating the owner’s balance.

Validator Cloning and Mapping

Key points:

• ATAs can be deterministically identified if the owner, mint, and token program are provided.
• Transactions that operate on SPL tokens use one of the standard token programs (whose pubkeys are known).

Implementation steps:

• For transactions that include the token program, look up the fee payer (used as the owner) and the mint (by inspecting common instructions and mint positions, e.g., identifying a transfer).
• If the actual ATA exists on the base layer, it can be identified after it is cloned the first time (the owner is the token program).

Once the ATA is recognized, the pseudo-ATA is derived [owner, mint, ephemeral_spl_program] and cloned instead. If delegated, it becomes a writable ATA in the ER.