MIMD-0016: Ephemeral (ER-Local) Accounts

[bmuddha]

Status: In Progress
Created: 2026-01-14
Updated: 2026-02-05

---

Abstract

Ephemeral accounts are zero-balance accounts with an EPHEMERAL flag that can be persisted in AccountsDB. Rent is paid by any account (PDA or oncurve) at 32 lamports/byte (109x cheaper than Solana). This enables creating state directly in the ephemeral rollup without base chain prerequisites.

---

Motivation

Creating state on Solana requires locking rent-exempt balance (3,480 lamports/byte). For a 10KB account, this costs ~35M lamports. This is prohibitively expensive for temporary use cases like gaming sessions, caching, or computation intermediate results.

Ephemeral accounts provide a cheap alternative: zero-balance accounts that live only in the ER, with rent paid by a sponsor account. Costs are deterministic based on size. Rent is fully refundable when accounts are closed.

---

Rent Analysis

The 32 lamports/byte rate balances storage overhead (~2.1x for shadow buffer), competitive positioning (109x cheaper than Solana), and future monetization potential.

Model	Storage Cost	TX Fees	Total (10KB, 1K txs)
Solana	3,480 lamports/B	5,000 lamports/tx	38,480,000 lamports
Light Protocol	0.24 lamports/B	5,000 lamports/tx	5,002,400 lamports
MagicBlock	32 lamports/B	0-50 lamports/tx	0-50,000 lamports

Example costs (at $200/SOL):

• 1 KB: 32,000 lamports ($0.0064)
• 10 KB: 320,000 lamports ($0.064)
• 100 KB: 3.2M lamports ($0.64)

---

Specification

Ephemeral Flag

Bit 6 on AccountSharedData. Account must have 0 lamports, cannot be committed to base chain, and rent is paid by a sponsor.

Sponsor and Vault Model

CPI-Only Architecture: All instructions must be invoked via CPI. Direct calls from wallets are rejected.

Sponsors: Any account can sponsor (PDA or oncurve). Sponsor must be a signer.

Vault: All rent flows through EPHEMERAL_VAULT_PUBKEY (owned by magic-program).

Rent Calculation:

ephemeral_rent = (data_len + ACCOUNT_STATIC_SIZE) * 32

Rent Flow:

• Create: Debit sponsor → Credit vault
• Grow: Debit sponsor → Credit vault (difference)
• Shrink: Debit vault → Credit sponsor (difference)
• Close: Debit vault → Credit sponsor (full refund)

Instructions

CreateEphemeralAccount { data_len: u32 }
// Accounts: [sponsor (signer, writable), ephemeral_account (signer, writable), vault (writable)]
// Note: Owner automatically inferred from CPI caller
// Note: Ephemeral account must be a signer to prevent pubkey squatting
// Note: Maximum data_len is 10 MB

ResizeEphemeralAccount { new_data_len: u32 }
// Accounts: [sponsor (signer, writable), ephemeral_account (writable), vault (writable)]
// Note: Maximum new_data_len is 10 MB

CloseEphemeralAccount
// Accounts: [sponsor (signer, writable), ephemeral_account (writable), vault (writable)]
// Note: Resets account to empty state (0 lamports, system_program owner, 0 data)

---

Architecture

Data Flow

User Program (CPI required)
    ↓
Magic Program (validates sponsor, debits rent, sets EPHEMERAL flag)
    ↓
AccountsDB (persists zero-balance account)

Account Lifecycle

Create → Active (rent in vault) → [Resize] → Close (refund to sponsor)

---

Safeguards

1. CPI-Only Requirement: Prevents direct wallet access, ensures program mediation
2. ScheduleCommit Validation: Ephemeral accounts rejected with InvalidAccountData error
3. Vault Protection: Marked as ephemeral, owned by magic-program
4. Sponsor Validation: Magic-program validates sponsor is a signer
5. Pubkey Squatting Prevention: Ephemeral account must be a signer on create

Risks and Mitigations

• State Loss: ER-only accounts can be lost on corruption (snapshot/backup strategies recommended)
• Attack Surface: CPI-only requirement ensures programs implement access control
• Parameter Rigidity: Fixed rate requires coordinated upgrade to adjust

---

Implementation Phases

Phase 1: Flag and Constant ✅

• EPHEMERAL_FLAG_INDEX (bit 6), EPHEMERAL_RENT_PER_BYTE (32), MAX_DATA_LEN (10 MB), AccountsDB filter

Phase 2: Instructions ✅

• Create/Resize/Close processors, CPI validation, sponsor validation, rent calculation

Phase 3: Integration ✅

• Magic-program processor integration, testing, correctness verification

Phase 4: SDK and DX 🚧

• Instruction builders, documentation, integration guides

---

Monetization (Future)

Optional fee percentage on rent operations:

ephemeral_rent = data_len * 32
ephemeral_fee = ephemeral_rent * FEE_PERCENTAGE  // e.g., 10%
total_cost = ephemeral_rent + ephemeral_fee

Example (10KB, 10% fee): Debit 352,000, refund 320,000 on close, keep 32,000 fee.

---

Example Usage

Basic Usage (from your program)

// Create ephemeral account (owner = your program ID)
let ix = MagicBlockInstruction::CreateEphemeralAccount {
    data_len: 10_000u32,
};

// Accounts: [sponsor (signer), ephemeral_account (signer), vault]
// Note: ephemeral_account must be a signer to prevent pubkey squatting
// Use invoke() for oncurve sponsor, invoke_signed() for PDA sponsor

// Resize
let ix = MagicBlockInstruction::ResizeEphemeralAccount {
    new_data_len: 20_000u32,
};

// Close (rent refunded to sponsor)
let ix = MagicBlockInstruction::CloseEphemeralAccount;

Program-Managed Sponsor

// Your program controls who can create accounts
if sponsor.authority != ctx.payer.pubkey() {
    return Err(Unauthorized);
}

if sponsor.account_count >= MAX_ACCOUNTS {
    return Err(QuotaExceeded);
}

// CPI to create ephemeral account
invoke_signed(&ix, accounts, seeds)?;
sponsor.account_count += 1;

---

Conclusion

Ephemeral accounts provide:

• 109x cheaper storage than Solana
• No base chain prerequisites
• Full rent refund on closure
• Flexible sponsor model (wallets or PDAs)

---

References

• Solana Rent Reduction (SIMD-0389)
• Light Protocol ZK Compression

[Dodecahedr0x]

Rent is paid by sponsor PDAs (owned by the invoking program)

Why not use the ephemeral balance of the creator? Apps can still sponsor by cosigning but it wouldn't impose the burden of maintaining the sponsor account on devs.

Is there a reason why this would need to be called through CPI? Creating oncurve accounts could be useful as well (I can see how resolving conflicts is impossible for accounts owned by incompatible programs)

Also, who would be the recipient?

---

ephemeral_rent = data_len * (3480 / cost_multiplier)

Rent has a constant cost to prevent spamming empty accounts

---

How does assigning the account work here? Through the regular system program? Prohibited for ephemeral accounts?

---

The fact the ephemeral accounts lock real value, they open up an attack surface which the smart contract devs need to consider and defend against, which adds DevX complexity.

Not sure what attacks this is referring to.

---

Since the debit/credit balance is maintained purely based on account existence, an accountsdb corruption might lead value burn or validator balance drain. But this would also introduce myriad other problems, and it is a highly unlikely scenario.

The difference here is that resetting accountsDB may not revert to the latest committed state: if rent is paid to a real account that e.g. the validator might commit at some point, then users will not be refunded and the validators gets to keep the fee. If rent is stored in an ephemeral accounts, then everything is lost but nobody loses money (outside of the implications of ephemeral accounts disappearing on programs using them)

[bmuddha]

Why not use the ephemeral balance of the creator? Apps can still sponsor by cosigning but it wouldn't impose the burden of maintaining the sponsor account on devs.

I guess we can allow a direct payment through feepayer, yes, but that would probably put a burden on the app developer to discriminate between invoke and invoke_signed, when calling the account creation, depending on who is paying. It's a flexibility tradeoff I suppose. And most of the feepayers rn are not delegated.

Is there a reason why this would need to be called through CPI?

Mostly to enforce that the invocation goes through the owner program's security logic, i.e. I cannot just use a program sponsor and call the instruction directly, creating an account even if I'm not eligible according to program rules.

Creating oncurve accounts could be useful as well

Probably, from a technical standpoint nothing prevents us from allowing them as well. The custom instruction can be agnostic of how it is invoked (invoke vs invoke_signed).

Also, who would be the recipient?

That's the thing, to keep things simple, we just burn and mint tokens out of vacuum, the created account holds the virtual balance difference just by existing. Although that relies on the fact that the rent rate won't ever change.

Not sure what attacks this is referring to.

Mostly related to the fact that the authority enforcement on sponsor is fallen onto the app dev, and they need to write custom logic on who (which of their users) can create accounts using those program global sponsor accounts. And also who can close them to ensure that the refund goes to the right wallet.