Precompile Studio is a Ritual-native workspace for composing, checking, and tracing async precompile calls.
The goal is to feel closer to Postman or Tenderly than a chain dashboard: one primary action composer, live readiness checks, and a trace surface that helps builders understand what happened after they sign.
Beta status: HTTP, JQ, and Scheduled JQ are available. LLM is marked degraded while Ritual's executor issue persists. Agent remains inspection-only with prior history and escrow recovery; new paid launches are paused.
Production: https://www.precompilestudio.xyz
- Ritual testnet RPC health check
- Live block number and latency
- Browser wallet connection
- Ritual chain switch/add flow for chain ID
1979 - Wallet balance readout
- RitualWallet deposit flow for funding precompile escrow
- Owned HTTP consumer using Ritual's async-envelope unwrapping pattern
- Foundry coverage for successful, HTTP-error, and reverted precompile calls
- HTTP consumer calldata generation and wallet submit flow
- HTTP consumer bytecode verification before wallet submit
- Persisted HTTP transaction history scoped by wallet or local browser, with receipt polling
- Explorer-linked HTTP transactions using Ritual's
/tx/{hash}route - Transaction hash import for externally submitted HTTP calls
- HTTP history JSON copy/import for moving traces between browsers
- HTTP history status filters for pending, confirmed, and failed transactions
- Distinct transaction, precompile, and HTTP response states decoded from
receipt.spcCalls - Expandable HTTP response headers and formatted JSON or text bodies
- Local saved HTTP consumer contracts scoped by wallet
- Local saved TEE executors scoped by wallet
- Local recipe presets for saving and reloading composer fields
- Built-in HTTP, LLM, JQ, Sovereign Agent, and Scheduled JQ recipe examples
- Live HTTP, LLM, JQ, and Scheduled JQ calldata composers plus an inspection-only Sovereign Agent composer
- Per-wallet Sovereign Agent registry, lifecycle, and consumer-escrow recovery diagnostics
- Per-wallet Scheduled JQ consumers with atomic funding, scheduling, cancellation, withdrawal, and lifecycle evidence
- Request preview with copy action
- Copyable normalized call JSON for encoded live recipes
- Copyable Foundry
cast sendcommands for encoded live recipes - Guardrail inspector for common pre-submit blockers
- Local secret-looking field warnings before copying or sharing drafts
- Responsive app layout for desktop and mobile
- Docs: https://docs.ritualfoundation.org
- Faucet: https://faucet.ritualfoundation.org
- Explorer: https://explorer.ritualfoundation.org
- RPC: https://rpc.ritualfoundation.org
Use MetaMask for Ritual testnet transaction submission. Rabby can connect and read state, but currently converts Ritual custom transactions to a legacy transaction type rejected by the Ritual RPC and does not provide the raw-signing fallback needed to broadcast the supported form. The studio reports this limitation directly instead of silently disconnecting or blocking Rabby.
HTTP, JQ, and Scheduled JQ are publicly usable. Scheduled JQ discovers or creates one deterministic contract owned by the connected wallet. The Agent composer and prior harness history remain readable, but new paid Agent launches are paused: the current GLM-4.7 route requires roughly 0.31 RITUAL of worst-case in-flight protocol escrow, so the former 0.02 RITUAL bounded profile cannot execute. LLM submission is implemented but currently depends on a degraded Ritual executor path.
npm install
npm run devOpen the local URL printed by Vite.
See DESIGN.md before making UI changes. The app should stay close to Ritual Explorer's calm, dense, dark builder-tool aesthetic and avoid generic dashboard sprawl.
npm run buildThe build verifies recipe example JSON and ABI smoke encoding before writing production output to dist/.
npm run test
npm run consumer:test
npm run test:e2eVitest covers every recipe encoder, Ritual receipt outcomes, Scheduler lifecycle recovery, and mocked EIP-1193 wallet flows. Foundry covers the owned consumer contracts. Playwright exercises HTTP, JQ, LLM, Agent, and Scheduled JQ paths at desktop and mobile widths and checks decoded evidence and horizontal overflow. GitHub runs all three suites before production deployment, then verifies every deployed contract address in the production bundle with npm run smoke:production.
The studio defaults to its owned HTTP consumer at 0x30a2132b7f47A30E2D55A191F6723161C232263C, which exposes callHTTPCallRaw(bytes) on Ritual testnet.
The source lives at contracts/HttpPrecompileConsumer.sol, with envelope handling in contracts/utils/PrecompileConsumer.sol. Deployment and smoke-transaction evidence are tracked in deployments/ritual-testnet.json.
Use the HTTP composer to encode a request, select a registered TEE executor, and submit callHTTPCallRaw(bytes) through the configured consumer. The studio checks that bytecode exists at the consumer address before enabling wallet submission. Users still pay their own gas and confirm the transaction in their wallet.
Submitted HTTP transactions are stored locally, scoped to the connected wallet when available, and polled through the Ritual RPC until a receipt is available. The trace decodes Ritual's five-field HTTP output from receipt.spcCalls, keeping transaction confirmation, precompile errors, and target-server HTTP status separate.
External transaction hashes can also be imported into HTTP history, which is useful when a call was submitted from a wallet, terminal, or explorer outside the current browser session.
HTTP history can be copied or imported as JSON, allowing trace evidence to move between local browsers without connecting a backend account.
HTTP consumer addresses can be saved locally and reused from the consumer panel. Saved consumers are scoped to the connected wallet when available, with a local fallback before wallet connection.
contracts/LlmPrecompileConsumer.sol applies the same Ritual envelope-unwrapping pattern to LLM inference. It stores compact hashes and lengths for completion and model metadata plus error and conversation-history evidence. Full model output remains in receipt.spcCalls for the studio to decode without duplicating large response bytes in contract storage.
The deployed Ritual testnet consumer is 0x6f78351167AA672e75948dc802FDf96f77E87Dfa. The studio submits non-streaming calls through it, polls the settled receipt, and decodes completion, usage, model metadata, and executor errors from spcCalls. Capability 1 is the verified LLM registry slot; streaming remains a separate capability and is not sent through this path.
TEE executor addresses can also be saved locally from recipes that need an executor, currently HTTP, LLM, and Sovereign Agent. The executor value still comes from TEEServiceRegistry; the studio only remembers addresses the builder has confirmed.
The Agent recipe can still read prior wallet-owned children of Ritual's SovereignAgentFactory at 0x9dC4C054e53bCc4Ce0A0Ff09E890A7a8e817f304. The original harness at 0x8067904eA53D7D0418AC0B5F87d2b4c7a59dE2Fe remains a readable public demo while disconnected. New factory-harness deployment and launch are disabled because the official harness rolls into successor Scheduler windows.
The studio discovers capability-0 executors and their public keys from TEEServiceRegistry, selects the first currently valid service when the previous choice has left the registry, and encrypts the credential-free Ritual provider configuration in the browser. Native zai-org/GLM-4.7-FP8 with ZeroClaw remains the free-provider profile. Executor addresses are intentionally not pinned because Ritual rotates the valid registry set.
The Studio reads existing harness ownership and series history by reconciling Scheduler and Agent events. That history is diagnostic only and does not make the factory harness a bounded test path.
Direct Sovereign Agent submission remains circuit-broken after a provider-failed request charged 0.50784 RITUAL without a reliable pre-signing quote. Ritual's official factory harness is also blocked for new launches because its rolling windows are not a true one-shot path. The repository now includes a per-wallet consumer that schedules one callback, rejects a second invocation, and never creates a successor; it remains unavailable in production until deployed and verified live.
The rollout gates are documented in docs/agent-verification.md.
The Scheduled JQ recipe uses ScheduledJqConsumerFactory at 0x705e1393280062D95d6e3B522223eD3f28b9548b to create one deterministic consumer per wallet. Each child owns its Scheduler calls and RitualWallet escrow, runs JQ through precompile 0x0803, records the latest decoded callback result, and allows only its wallet owner to fund, schedule, cancel, or withdraw. The original consumer at 0x7243c1A2cA1Ea555416951480B147c27b17eA668 remains a readable public demo when no wallet is connected.
The studio calculates Ritual's fixed 0.01 RITUAL Scheduler reserve plus the complete execution budget. When the consumer is short, fundAndSchedule deposits exactly the shortfall and creates the schedule in one wallet confirmation. Lifecycle reconciliation uses recent Scheduler events first, durable synthetic Scheduler block transactions after RPC log retention, and the consumer's recorded terminal state as the final authority.
The factory smoke created child 0x43beC43EBc45df36B0738Dfa13F9e406F08333e4 for the deployer. Its atomic fund-and-schedule transaction 0xa2d45aff240e5019a4405bbe719dd9b62575a83f8c4c2b15d58169f68649bf86 created call 3147825; Ritual executed it in transaction 0x6823f7fba193301d594b4d5cad5c94ae1bdbc20362ec9e83c6df92859c2e718b at block 45,403,040, and the child stored the decoded uint256 result 1979. Full deployment evidence is in deployments/ritual-testnet.json.
Composer fields can also be saved as local recipe presets. Presets are stored in the browser, can be loaded back into the matching recipe tab, and can be copied/imported as JSON. See docs/presets.md, examples/http-preset.json, examples/llm-preset.json, examples/jq-preset.json, examples/agent-preset.json, and examples/scheduler-preset.json for the preset format.
See contracts/README.md for build, test, and deployment details, and ROADMAP.md for the remaining milestones.
For a button-by-button verification walkthrough, see docs/test-guide.md.
Recommended settings:
- Framework preset:
Vite - Install command:
npm install - Build command:
npm run build - Output directory:
dist
After importing the GitHub repo into Vercel, add the custom domain in Vercel and copy the requested DNS records to the domain registrar.
This repo deploys through GitHub Actions instead of Vercel's native GitHub integration.
Required repository secrets:
VERCEL_TOKENVERCEL_ORG_IDVERCEL_PROJECT_ID
The workflow runs on pushes to main and can also be triggered manually from the GitHub Actions tab.
The ordered milestones and their completion state live in ROADMAP.md.
Precompile Studio is available under the MIT License.