Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.magicblock.gg/llms.txt

Use this file to discover all available pages before exploring further.

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:

Anchor

Integrate with an Anchor program

Native Rust

Integrate with an Native Rust program

​
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, 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

Execute transactions

Execute transactions on-chain or off-chain using any SDKs that complies with the SVM RPC specification (web3.js, Solana Rust SDK, Unity SDK, or others).

​
Add delegation and undelegation hooks

Empower your program with ultra-latency transactions by adding delegation and undelegation hooks. Simply add two functions from the native Rust SDK to your program.

​
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 session
    &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 triggers the finalization process. Once state is validated, the PDAs are unlocked and can be used as normal on mainnet. The SDK exposes a MagicIntentBundleBuilder that lets you build commit and commit-and-undelegate intents in one call:
Undelegation
use ephemeral_rollups_sdk::ephem::MagicIntentBundleBuilder;

pub fn undelegate(ctx: Context<IncrementAndCommit>) -> Result<()> {
    MagicIntentBundleBuilder::new(
        ctx.accounts.payer.to_account_info(),
        ctx.accounts.magic_context.to_account_info(),
        ctx.accounts.magic_program.to_account_info(),
    )
    .commit_and_undelegate(&[ctx.accounts.pda.to_account_info()])
    .build_and_invoke()?;
    Ok(())
}
The same builder can be used with .commit(...) instead of .commit_and_undelegate(...) to push state to the base layer without releasing the PDA. 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

​
Frontend

To make it easier to integrate via the frontend, we created the Magic Router. You send transactions directly to the magic router, and we can determine for you whether it should be routed to the Ephemeral Rollup or base layer.
Frontend
import { sendMagicTransaction } from "magic-router-sdk";

const routerConnection = new Connection("https://devnet-router.magicblock.app", "confirmed");

// Construct a standard Solana transaction
const tx = await exampleClient.current?.methods
  .exampleMethod(0)
  .accounts({
      user: userPda,
      user: userKeypair.current.publicKey,
  }).transaction() as Transaction;

const noopInstruction = new TransactionInstruction({
      programId: new PublicKey('11111111111111111111111'),
      keys: [],
      data: Buffer.from(crypto.getRandomValues(new Uint8Array(5))),
  });
transaction.add(noopInstruction);

// Send the transaction
const signature = await sendMagicTransaction(
  routerConnection,
  tx,
  [userKeypair]
)
These public RPC endpoints are currently free and supported for development:
Magic Router Devnet: https://devnet-router.magicblock.app
Solana Devnet: https://api.devnet.solana.com
ER Devnet: https://devnet.magicblock.app
TEE Devnet: https://devnet-tee.magicblock.app/
Find out more details here .