Architecture
How the onchain, application and external pieces fit together.
Three zones
Onchain holds value: the token's curve or pool, the fee-sharing configuration, each machine's business wallet, collectible assets, and confirmed transfers.
The GRAIL application keeps the records: machine registry, inventory ledger, event scheduler, attempt validation, draw commitments, holder accounting and delivery jobs.
External services supply data and work: marketplace discovery, RPC and indexing, model and media providers, the randomness source, authorized X posting, and the physical custodian.
Key flows
- Value: curve/pool → business wallet → collectible purchase → transfer to winner.
- Requests: the app asks RPC for balances, marketplaces for listings, models for decisions.
- Metadata: the custodian links each NFT to its physical card; it isn't an onchain transfer.
Attempt validation
Gameplay runs on engine claw-v1, a deterministic simulation. A submitted attempt is its seed plus input log; the server replays it and gets the identical result, so scores can't be forged.
Text equivalent of the diagram
Pump curve/pool → (value) business wallet. Fee config → (metadata) machine registry. Business wallet → (value) collectible assets → (value) confirmed transfers. Machine registry, inventory ledger and delivery jobs → (requests) RPC/indexing. Inventory ledger → (requests) marketplace. Event scheduler → (requests) randomness. Agents → (requests) model providers and X. Collectible assets → (metadata) physical custodian.