From an integration perspective, using Ephemeral Rollups is similar to writing a multi-threaded program. Programs can offload work to an Ephemeral Rollup session to process transactions in a low-latency, high-throughput SVM runtime. The SVM runtime is provisioned just-in-time, and transactions are processed by nodes from the decentralized networks of ephemeral validators.

Ephemeral Rollups can be used with any program that targets the Solana blockchain. We maintain a library of common integrations for:

Lifecycle of the Integration

The lifecycle of integrating Ephemeral Rollups in your program is as follows:

1

Write your program

Write your Solana program as you normally would, using Anchor, Bolt, or native Rust, C, or even assembly.

2

Add delegation and undelegation hooks

Accounts that are delegated can be used as writable in an Ephemeral Rollup session.

3

Deploy your program on Solana

Deploy your program directly on Solana.

4

Connect the frontend

Connect a frontend using any SDKs that respect the SVM RPC specification (web3.js, Solana Rust SDK, Unity SDK, or others). Use an RPC router or route on the client side.

Delegation

Delegation is the process of transferring ownership of one or more of your program’s PDAs to the delegation program. Ephemeral Validators will then be able to use the PDAs to perform transactions in the SVM runtime and commit the state.

In Rust programs, you can use the ephemeral_rollups_sdk crate to delegate accounts.

Install it with:

cargo add ephemeral_rollups_sdk

Then use the delegate_account function to delegate an account to the delegation program.

Delegation
use ephemeral_rollups_sdk::cpi::delegate_account;

delegate_account(
    &ctx.accounts.payer, // The account that will pay for opening the
    &ctx.accounts.pda, // The PDA to delegate
    &ctx.accounts.owner_program, // Owner program of the PDA
    ...
    pda_seeds, // Seeds to make the PDA signer
    0, // 0 means no time limit for the delegation
    3_000, // Update frequency on the base layer in milliseconds
)?;
Both delegation and undelegation are CPIs that can be integrated in existing instructions of your program

Undelegation

Undelegation is the process of transferring ownership of the PDAs back to your program. On undelegation, the state is committed and it trigger the finalization process. Once state it validated, the PDAs are unlocked and can be used as normal on mainnet

Delegation
use ephemeral_rollups_sdk::ephem::commit_and_undelegate_accounts;

pub fn undelegate(ctx: Context<IncrementAndCommit>) -> Result<()> {
    commit_and_undelegate_accounts(
        &ctx.accounts.payer,
        vec![&ctx.accounts.pda.to_account_info()],
        &ctx.accounts.magic_context,
        &ctx.accounts.magic_program,
    )?;
    Ok(())
}

Additionally, custom CPI can instruct the ephemeral validators to commit and finalize a state or close a session.

Note that commit and undelegation accept a list of accounts. These accounts are committed atomically to the base layer which allows to maintain state consistency of dependent accounts

Execute transactions

Any other instruction which is part of your program can be executed without changes. The transaction will be processed by Solana or Ephemeral Validators depending on the account’s delegation status.

For a complete example, see the Anchor Counter example.