Skip to main content

magicblock:Solana 瞬时 Rollup 应用

设计、实现并调试 MagicBlock 的 Solana 应用,覆盖 Ephemeral Rollups、委托、隐私支付、预言机、会话密钥与本地校验。

来源信息

仓库
magicblock-labs/magicblock-dev-skill
最近来源活动
2026年10月23日 08:17
检测到的 SKILL.md 语言
英语
星标
9
Forks
6

用途

用于 MagicBlock 产品选型、接入、跨产品设计或生产排障。一般 Anchor/PDA/钱包脚手架请搭配 solana-dev。

必要前提

具备编程 Agent,并清楚程序目标、账户与网络等 Solana/MagicBlock 上下文。通用 Solana 脚手架仍由配套的 solana-dev 负责。

操作说明

先判断是否需要 MagicBlock 及最小产品组合 → 分类操作(初始化、委托、ER 操作、提交、解除委托、异步服务)→ 选择 base/router/ER 连接 → 按委托状态检查与正确 preflight 实现 → 排查线上路由故障并交付带风险说明的改动。

限制

聚焦 MagicBlock 的 ER/委托/预言机/会话密钥;不能替代通用 Solana 或 Anchor 脚手架。基座层委托成功不代表 post-delegation ER 动作已执行。

安装方式

默认使用会先检查来源的 Prompt;你也可以切换为直接命令,或下载本地副本。

检查来源文件

决定是否安装前,请先阅读 SKILL.md,以及 SkillsMP 当前展示的配套文件。

文件资源管理器
22 个文件

正在显示 SKILL.md

SKILL.md
来源说明 · 只读预览
name
magicblock
description
Design, implement, and debug MagicBlock applications on Solana. Covers Ephemeral Rollups with delegated state; ER/PER architecture and settlement; private payments and token flows; oracles and randomness; scheduling and temporary authority; security and local validation. Use for MagicBlock product selection, integration, cross-product design, or production troubleshooting.
# MagicBlock Development Skill ## Pair with the `solana-dev` skill Use this skill for MagicBlock-specific concerns: ER/PER, delegation, oracles, Session Keys, cranks, VRF, Magic Actions, eSPL, and private payments. For general Solana or Anchor work such as scaffolding, PDAs, account layouts, SPL tokens, clients, wallets, or LiteSVM/Mollusk testing, also load `solana-dev`. ## Key Concepts **Ephemeral Rollups** enable high-performance, low-latency transactions by locking a delegated account on the base layer while an ER clone continues to execute under the account's original program owner. They are useful for gaming, real-time apps, and fast transaction throughput. **Ephemeral Accounts** are born, used, and closed only inside an ER. They are useful for temporary high-frequency state, but they never commit to Solana and therefore cannot be the only copy of durable ownership, balances, rewards, or settlement results. **Delegation** temporarily assigns the base-layer account to the Delegation Program and clones it into the ER with its original program owner. Normal program ownership, signer, authority, and account constraints still apply on the ER; delegation status is a routing and lifecycle concern, not a new application authorization rule. **Post-delegation actions** attach instructions to a base-layer delegation with `delegate_account_with_actions`. The Delegation Program stores them in the delegation record; the validator runs them on the ER after cloning. Base-layer delegation success does not prove that the action ran. For public or encrypted payloads, signer handling, and recovery, read [delegation-actions.md](references/delegation-actions.md). These are distinct from post-commit Magic Actions, which run on the base layer. **Delegation debugging invariant**: a properly delegated account looks owned by the delegation program on base, owned by the original program on the ER endpoint returned by router `getDelegationStatus`, and reported `isDelegated: true` by `getDelegationStatus` sent to that ER endpoint itself. For the verified SDK v0.16.2 snapshot, use **MagicIntentBundleBuilder** to schedule commit and commit-and-undelegate intents. Do not use the deprecated free functions `commit_accounts` and `commit_and_undelegate_accounts`. **Private Ephemeral Rollups (PER)** gate a delegated account inside a TEE-backed validator with an ER-local `EphemeralPermission`. Delegate only the data account on the base layer, then create, update, and close its permission on the ER with `CreateEphemeralPermissionCpi`, `UpdateEphemeralPermissionCpi`, and `CloseEphemeralPermissionCpi`. Do not create or delegate a separate base-layer permission account. **Magic Actions** are base-layer instructions scheduled inside an ER transaction via `MagicIntentBundleBuilder.add_post_commit_actions(...)`. Each attempted base-layer transaction applies its commit and actions atomically. If any BaseAction fails, the committor removes every BaseAction in that affected `TransactionStrategy` before retrying its remaining commit strategy; actions in other transaction/finalize strategies are outside that removal scope. Observe and reconcile every originally scheduled action: scheduling or eventual commit success alone does not prove that any of them ran. **Commit fees and limits** span the Delegation Program and validator. Without the fee-vault path, a plain commit fails once the account's current nonce reaches 10; accepted commits can still consume the delegation PDA fee budget at undelegation. With a delegated payer and validator-scoped `magic_fee_vault`, commit 26 starts debiting `100_000` lamports per committed account. Read [fees-and-commit-economics.md](references/fees-and-commit-economics.md) first for fee, refund, sponsorship, cost-estimation, or fee-payer funding questions. **Lamports top-up**: when a delegated account (e.g. a delegated fee payer) needs more lamports on the ER side, use `lamportsDelegatedTransferIx` from the SDK. The transaction is submitted on **base layer** — the Ephemeral SPL Token program creates a single-use lamports PDA, funds it, and delegates it so the ER credits the destination. **Ephemeral SPL Token** has two surfaces. In the SDK lifecycle model, clients use `delegateSpl`/`transferSpl`/`undelegateIx`/`withdrawSpl`, and the ER balance appears as a normal SPL token account at the owner's canonical ATA address, so Anchor programs can use plain SPL Token CPI. In the direct-program model, contracts use `ephemeral-spl-api` and explicitly work with the eATA/global-vault PDAs; do not apply the canonical-ATA model to that raw surface. Private base→ephemeral transfers now credit an ER-only **Magic ATA** (TS SDK ≥ 0.17.1). Before you promise that an eSPL feature works on a cluster, check the devnet/mainnet deployment table in [ephemeral-spl-token.md](references/ephemeral-spl-token.md#deployment-status). **Pricing Oracle** republishes supported market feeds for Solana/ER consumers. A safe integration verifies the expected feed identity, upstream publish-time freshness, value domain, exponent, checked arithmetic, and user price bounds; successful deserialization alone is not price validation. **Session Keys** authorize a temporary signer for constrained application actions. Session validity is separate from SPL token authority: token spending also requires an explicit, bounded token delegate allowance. **Architecture**: ``` ┌─────────────────┐ delegate ┌─────────────────────┐ │ Base Layer │ ───────────────► │ Ephemeral Rollup │ │ (Solana) │ │ (MagicBlock) │ │ │ ◄─────────────── │ │ └─────────────────┘ undelegate └─────────────────────┘ ~400ms ~10-50ms ``` ## Default stack ### Programs Use Anchor with `ephemeral-rollups-sdk`; native and Pinocchio are also supported. - Use the target repo's existing `ephemeral-rollups-sdk` / Anchor versions unless the task is an explicit upgrade - The SDK feature flag selects the Anchor range: `anchor` for Anchor 1.x programs, or `anchor-compat` for Anchor >=0.28,<1.0 programs **Required macros:** - `#[ephemeral]` on the program module, **before** `#[program]` — injects the `process_undelegation` callback (the delegation program CPIs into it to return the account) and the commit/undelegate intent builders. Commit and undelegation require it; delegation itself does not. Include it on any program that delegates so its accounts can later be undelegated. - `#[delegate]` and `#[commit]` on the respective delegation/commit account contexts. - `#[vrf]` on a VRF *request* context **and** `#[vrf_callback]` on the VRF *callback* context — the callback macro authenticates fulfillment. Enable the `vrf` feature on `ephemeral-rollups-sdk`. SDK v0.16.2 re-exports VRF, so new Anchor code does not need a direct `ephemeral-vrf-sdk` dependency. See [vrf.md](references/vrf.md). **Non-Anchor programs:** use the `ephemeral-rollups-pinocchio` crate (delegation, commit, and VRF have Pinocchio equivalents). The engine examples repo ships Anchor and Pinocchio variants of `roll-dice`; use Pinocchio when the target program is native rather than Anchor. Versions in this skill are known-good snapshots or compatibility markers. Before changing dependencies, inspect the target repository's manifests, toolchain files, lockfiles, and relevant upstream sources. See [resources.md](references/resources.md) for the dated snapshot and source links. ### Connections - Base layer connection for initialization and delegation: `https://rpc.magicblock.app/devnet` or `https://rpc.magicblock.app/mainnet` - Router connection for delegation status: `https://devnet-router.magicblock.app/` or `https://router.magicblock.app/` - Ephemeral rollup connection for operations on delegated accounts: use the `fqdn` returned by router `getDelegationStatus` ### Transaction routing - Delegate transactions → Base Layer - Operations on delegated accounts → Ephemeral Rollup - Undelegate/commit transactions → Ephemeral Rollup ## Operating procedure ### 0. Plan architecture when the design is not fixed For a new application, integration design, migration, or implementation plan, read [architecture-planning.md](references/architecture-planning.md) before writing code. Decide whether MagicBlock is needed, select the smallest product set, map accounts and transaction routing, define settlement and recovery, and choose validation environments. Ask at most three material questions per round; otherwise proceed with explicit assumptions. ### 1. Classify the operation type - Account initialization (base layer) - Delegation (base layer) - Post-delegation action (scheduled on base layer; executed on the ER after cloning) - Operations on delegated accounts (ephemeral rollup) - Commit state (ephemeral rollup) - Undelegation (ephemeral rollup) - ER-only Ephemeral Account lifecycle (ephemeral rollup; never commits) - Asynchronous service work (VRF callback, crank, queued transfer, or Magic Action) - Hosted API transaction construction followed by client signing/submission ### 2. Pick the right connection - Base layer: `https://rpc.magicblock.app/devnet` or `https://rpc.magicblock.app/mainnet` - Router: `https://devnet-router.magicblock.app/` or `https://router.magicblock.app/` - Ephemeral rollup: the `fqdn` returned by router `getDelegationStatus` for the account ### 3. Implement with MagicBlock-specific correctness For each implementation, record: - Which connection to use for each transaction - Router `getDelegationStatus` checks before operations - PDA seeds matching between delegate call and account definition - Preserving preflight for supported base transactions, and using `skipPreflight: true` only for an ER path with a known simulation incompatibility (document the reason and inspect execution logs) - Waiting for state propagation after delegate/undelegate - For Ephemeral SPL Token flows, selecting the deposit and withdrawal builders independently: use the default shuttle withdrawal, or explicitly run `undelegateIx`, wait for its base commit, and call the legacy `withdrawSpl(..., { idempotent: false })`; use `ephemeral-spl-api` exports (not copied bytes or guessed seeds) for direct CPI - For oracle flows, feed identity, maximum age, numeric conversion, user limits, and stale-feed behavior - For Session Keys, scope, expiry, optional one-time signer lamports top-up, revocation, application- enforced spending limits, and any separate SPL delegate allowance - For asynchronous flows, the difference between acceptance/scheduling and completion, plus observation, idempotency, timeout, retry, refund, and reconciliation For security-sensitive designs, reviews, and implementations, read [security.md](references/security.md). Separate protocol guarantees from required integration validation, application policy, and ordinary Solana security. Do not present an application recommendation as a MagicBlock protocol guarantee. In a review, report each finding with its runtime, product state, label, source, consequence, and test, using the template in [security.md#review-output](references/security.md#review-output). ### 4. Debug live delegation/routing failures For `InvalidWritableAccount`, missing private balances, validator mismatch, or "account is delegated but ER rejects it" reports: - Start from the exact signature or account pubkey. - Query router `getDelegationStatus` and use its `fqdn` for ER reads/transactions. - Compare base ownership, router status, ER ownership, and recent ER transaction logs. - Treat base ownership by the delegation program as expected for a delegated account. - See [debugging.md](references/debugging.md) for the full runbook. ### 5. Diagnose possible service-side failures For unexpected RPC, routing, oracle, or transaction errors that could be service-side: - Always fetch current data; do not answer from remembered status. Use the direct JSON API `https://status.magicblock.app/api/services` as the source of truth. - Select the same network the code uses: JSON keys are `mainnet` and `devnet`. - Match the affected endpoint to the right region/server and service: - Regions are `asia`, `europe`, `usa`, and `tee`. - Service IDs are listed in `.meta.services`; currently `er` (Ephemeral Rollup), `rpc_router`, `pricing_oracle`, and `vrf_oracle`. - Use the server entries under `.environments[network].regions[region].servers`; for mainnet Asia this includes `as.magicblock.app`. - Interpret `.live_status[service]`: `true` = Operational, `false` = Down, missing/undefined = N/A. - Interpret `.metrics[service]` as downtime minutes per day aligned with `.meta.days` in UTC. - When reporting findings, include the network, region, endpoint, service status, and relevant date range. Distinguish live status from historical downtime. - For direct ER RPC endpoints, optionally correlate with JSON-RPC `getHealth` or `getVersion`, but do not let a single RPC probe replace the status API. ### 6. Add appropriate features - Cranks for recurring automated transactions - VRF for verifiable randomness in games/lotteries - Private payments API for private transfers and swaps - Pricing Oracle for verified external market data - Session Keys for repeated low-friction user actions - Ephemeral Accounts for temporary state that is explicitly allowed to disappear When combining products, read [composition-patterns.md](references/composition-patterns.md) and keep authority, token control, oracle validity, ER execution, base settlement, and asynchronous completion as separate guarantees. ### 7. Deliverables expectations When you implement changes, provide: - Exact files changed + diffs - Commands to install/build/test - Risk notes for anything touching delegation/signing/state commits ## Progressive disclosure (read when needed) - Architecture planning, output templates, and validation-environment selection: [architecture-planning.md](references/architecture-planning.md) - Cross-product selection and boundary design: [composition-patterns.md](references/composition-patterns.md) - MagicBlock-specific security boundaries and source standards: [security.md](references/security.md) - Debugging ER/delegation failures: [debugging.md](references/debugging.md) - Core delegation patterns: [delegation.md](references/delegation.md) - Post-delegation ER actions, including private payloads: [delegation-actions.md](references/delegation-actions.md) - Fees, commit limits, delegation refunds, action charges, and fee-vault economics: [fees-and-commit-economics.md](references/fees-and-commit-economics.md) - Ephemeral Accounts (ER-only temporary state): [ephemeral-accounts.md](references/ephemeral-accounts.md) - Magic Actions (post-commit base-layer instructions): [magic-actions.md](references/magic-actions.md) - Topping up a delegated account with lamports: [lamports-topup.md](references/lamports-topup.md) - Ephemeral SPL Token lifecycle (deposit, transfer, app-program CPI, undelegate, withdraw, Magic ATAs, devnet/mainnet deployment status): [ephemeral-spl-token.md](references/ephemeral-spl-token.md) - TypeScript frontend setup: [typescript-setup.md](references/typescript-setup.md) - Cranks (scheduled tasks): [cranks.md](references/cranks.md) - VRF (randomness): [vrf.md](references/vrf.md) - Pricing Oracle (feed identity, freshness, and safe consumption): [pricing-oracle.md](references/pricing-oracle.md) - Session Keys (scoped temporary authority): [session-keys.md](references/session-keys.md) - Private Payments API (incl. gasless, x402/MPP merchant checkouts, live-feature status): [private-payments.md](references/private-payments.md) - Local development and environment-specific validation: [local-development.md](references/local-development.md) - Reference links & versions: [resources.md](references/resources.md) ## Terminal Self-Heal Proposal Before the final response, review the entire run against this skill's intended workflow. Check: - expected vs actual user-visible outputs - command, script, validation, and artifact results - missed coverage or skipped workflow steps - stale instructions or brittle wording - unexpected script/output mismatches - verification gaps - fallback or impromptu behavior If gaps are found, report them with evidence and request explicit approval for a separate maintenance task. Treat installed skill files as read-only during normal execution.
在 GitHub 查看