MagicBlock company primary sources — 2026-08-12

Project status in this pass

• This pass was not about expanding MagicBlock the product surface from scratch.
• The goal was the narrower HEARTBEAT taxonomy question: does MagicBlock need a separate companies/ note because the named operator boundary is analytically useful beyond the existing project note?
• The answer looks like yes. The live docs now expose enough operator-shaped material — routing, public endpoints, TEE environments, pricing, status, audits, and auth-bearing payment surfaces — that the company boundary materially improves control-surface analysis.

Primary-source snapshots

1) Official homepage

• URL: https://www.magicblock.xyz/
• Key excerpt:
  • The homepage presents MagicBlock as a real-time engine and the backend for the new financial internet.
  • It claims 1 ms block time, under-50 ms end-to-end latency via co-location, zero fees, and compliant privacy through Ephemeral Rollups plus Intel TDX.
  • This is useful because it frames MagicBlock as an always-on service and performance shell, not only a paper architecture.

2) Documentation index (llms.txt)

• URL: https://docs.magicblock.gg/llms.txt
• Key excerpt:
  • The docs index exposes a broad first-party surface: product overviews, pricing, security, system status, whitepaper, ER/PER docs, router docs, private-payment flows, oracle docs, and VRF docs.
  • The breadth matters because it shows one named operator curating the canonical path across execution, privacy, data, and support surfaces.

3) Product overview

• URL: https://docs.magicblock.gg/pages/overview/products.md
• Key excerpt:
  • The products page says MagicBlock is your backend for the new financial internet.
  • The same page groups Ephemeral Rollups, Private Ephemeral Rollups, Ephemeral SPL Token, prediction-market/trading flows, Solana VRF, and a pricing oracle in one vendor-controlled surface.
  • This supports a company split because the practical surface is a bundled platform, not just one protocol primitive.

4) Magic Router docs

• URL: https://docs.magicblock.gg/pages/ephemeral-rollups-ers/introduction/magic-router.md
• Key excerpt:
  • Magic Router is described as a dynamic transaction-routing engine that decides whether transactions should execute on Ephemeral Rollups or Solana based on transaction metadata.
  • The docs emphasize a single RPC endpoint, no manual routing logic, and routing to the fastest available endpoint.
  • The page also exposes a public Magic Router devnet endpoint, which makes endpoint operation part of the company boundary rather than only a concept in the protocol note.

5) Oracle docs

• URL: https://docs.magicblock.gg/pages/tools/oracle/introduction.md
• Key excerpt:
  • MagicBlock says it ingests Pyth Lazer feeds and updates Ephemeral Rollup accounts every 50–200 ms depending on asset.
  • The docs say arbitrary data sources can also be turned into MagicBlock oracles, and that the chain pusher will be open-sourced later.
  • The page publishes concrete development endpoints: Magic Router devnet, Solana devnet, ER devnets for Asia / EU / US, and a TEE devnet endpoint. This is strong evidence of an operator-run service topology worth preserving separately from the product architecture.

6) Private Payments / Ephemeral SPL Token docs

• URL: https://docs.magicblock.gg/pages/private-ephemeral-rollups-pers/api-reference/per/introduction.md
• Key excerpt:
  • The docs describe private, compliant onchain transfers with shielded amounts, destinations, and timing, using stealth handles and queued settlement.
  • They point developers to the broader Ephemeral SPL Token API for deposits, transfers, withdrawals, balances, stealth pools, swaps, and auth.
  • This matters because it shows MagicBlock packaging an app-facing auth-and-settlement control plane, not only low-level execution acceleration.

7) Pricing docs

• URL: https://docs.magicblock.gg/pages/overview/additional-information/pricing.md
• Key excerpt:
  • The pricing page says MagicBlock’s pricing is modeled after decentralized cloud infrastructure.
  • It says the goal is predictable compute costs for developers plus flexibility for enterprises needing priority access or dedicated resources.
  • This is direct evidence that the company boundary matters: resource allocation and commercial access are explicitly part of the service design.

8) Security & audits docs

• URL: https://docs.magicblock.gg/pages/overview/additional-information/security-and-audits.md
• Key excerpt:
  • MagicBlock says all core programs have undergone professional audits.
  • The page lists the Delegation Program and Solana VRF Program, including GitHub repositories, program IDs, and named audit firms, and also references a private Permission Program with audit TBC.
  • This shows a company-managed trust shell around which programs are live, public, audited, or still private.

9) Systems Status page

• URL: https://docs.magicblock.gg/pages/overview/additional-information/system-status.md
• Key excerpt:
  • MagicBlock publishes a dedicated system-status page embedded in the official docs.
  • Even though the fetched content is mostly the iframe wrapper, the existence of a first-party status surface still matters analytically: it marks MagicBlock as an operator publishing service-health truth for its managed stack.

10) GitHub organization

• URL: https://github.com/magicblock-labs
• Key excerpt:
  • The GitHub organization describes MagicBlock as ultra-low-latency, on-demand runtime infrastructure for fully onchain applications.
  • It highlights open-source repositories for validator software, the ephemeral-rollups SDK, the delegation program, examples, token support, session keys, and Unity tooling.
  • This reinforces that the company is maintaining a broad implementation surface rather than only posting docs around a thin hosted API.

Working conclusion

MagicBlock now clears the bar for a separate companies/ note. The project note is still useful for the product-layer question — how delegated execution, private payments, oracle freshness, and VRF fit together on Solana — but it is no longer enough on its own. The named operator runs the router, publishes the endpoints and status surface, curates audits, commercializes priority and dedicated resources, and packages the developer-facing auth / settlement shell around the stack.