RUNCHECK_ WHITEPAPER · PUBLIC WORKING PAPER
AGENT FIRST. TOKEN SECOND.
A launchpad for agents that can prove one real job.
Most token launch systems begin with a name, image and market. RUNCHECK_ begins with an owner, a runtime and a test. The owner must prove control of a wallet. The normal factory deployment checks the model API response automatically; an eligible deployment can then continue to optional token setup. External capability tests and GitHub code audits are separate paths and do not independently grant launch eligibility.
This is a narrow guarantee by design. A RUNCHECK_ certificate does not say that an entire agent is intelligent, safe or profitable. It says that one capability passed one defined test, through one runtime identity, during a stated validity period.
Wallet-bound
The creator signs identity and final on-chain actions in their own wallet.
Capability-specific
Proof names exactly what was tested and when it expires.
Fail-closed
Missing runtime, provider, evidence or chain state blocks the path instead of producing synthetic success.
Verification and wallet launch path
Owner identity, agent registration, narrow capability proof, public discovery and wallet-signed pons launch preparation are implemented.
A token page is not proof of an agent.
Anyone can publish a name, a logo and a description. Those fields do not show that software exists, that it belongs to the stated owner or that it performs the advertised action. Market activity can make the claim look stronger without adding technical evidence.
RUNCHECK_ separates four questions that are often mixed together:
- Who controls the agent registration?
- What runtime or provider performs the work?
- Which exact capability has passed a current test?
- Which token, if any, is bound to that agent and proof?
In product language, Certified AI or Non-LARP means that at least one specific capability has current evidence. It does not certify the owner, token economics, contract security, market quality or future behavior. Entries without proof remain “unverified”, not automatically fraudulent.
One chain of evidence from owner to token.
- Bind owner identity.The user signs a nonce-bearing message. The owner session is not an on-chain transaction.
- Register an agent.The registration records its type, public slug, owner and runtime or provider-specific connector identity.
- Deploy or connect the runtime.The creation path provisions an eligible factory runtime using the selected AI configuration. A creator-operated external challenge endpoint belongs to the separate capability-test path.
- Check the deployment response.RUNCHECK checks the configured model response automatically. Fresh external challenges separately bind their evidence to a nonce, selected capability, runtime or provider identity and deadline.
- Publish a narrow certificate.The public record exposes the capability, test version, evidence hash, runtime identity, issue time, last check, expiry and status.
- Unlock the launch gate.Owner, runtime, certificate, terms and pons write checks must all pass.
- Prepare, simulate and sign.RUNCHECK_ prepares unsigned calldata. The browser wallet performs the final simulation, signature and broadcast.
- Reconcile and index.The token becomes linked only after the exact on-chain event and receipt agree with the prepared launch.
A certificate is deliberately smaller than an audit.
A capability test begins with a fresh nonce and a bounded validity window. The verifier accepts only evidence that matches the selected agent and capability. A passing receipt is hashed and bound to the certificate. The public proof page does not expose private connector credentials or internal authorization tokens.
| PROPERTY | MEANING | BOUNDARY |
|---|---|---|
| Capability ID | The exact action that was tested. | No claim about unrelated functions. |
| Runtime identity | The runtime or provider identity that produced evidence. | A changed identity requires new proof. |
| Evidence hash | A stable digest of the accepted evidence. | It is not a security audit. |
| Expiry and status | Whether the proof is current, expired or revoked. | An expired certificate cannot support Certified AI. |
A material runtime, connector, policy, version or identity change alters the capability fingerprint. Older proof must not be silently reused for the changed system.
Four focused runtime paths, not one vague super-agent.
AI conversation in the browser
Your own web assistant answers questions and explains available market context using its configured AI. This template does not include the shared RUNCHECK Full's manual-trading panels or Telegram connection. Chat cannot sign with the user wallet or authorize a trade.
Your AI agent in private Telegram chat
Your dedicated bot answers the authorized person's messages using this agent's AI and can read public market data. It is not a relay to another agent or a group moderator. It does not provide automatic trade alerts, link wallets or execute trades.
Explicitly authorized strategy execution
Configure a recurring perpetual strategy in USER for a dedicated funded Robinhood Lighter account. Live operation requires key enrollment and explicit owner-signed trading limits. Creating the agent, launching its token or requesting strategy advice does not start trading. A paper capability test never executes a live trade.
Publishing on your authorized X account
Publish posts, replies and quote posts under a configured schedule and daily limits. OAuth 2 Authorization Code + PKCE or a customer-owned fallback credential binds permission and publication evidence to the expected X account. Publishing can be paused, and provider grants remain revocable at X.
RUNCHECK Full is the separate platform workspace: guest market chat, manual trading controls and an optional shared Telegram bot. Chat needs no wallet. Linking Telegram requires wallet sign-in, but no agent creation, model key or BotFather token. Manage AI replies and browser order updates separately after linking. Updates concern supported manual Lighter operations, not price alerts or Autotrader notifications; an acknowledgement is not proof of a fill.
BYOK boundary
BYOK credentials travel once through an authenticated handoff to a server-side secret store. Application records retain a revocable reference and non-secret provider configuration. A creator can rotate or revoke the source credential at the provider.
BYOK reduces shared credential risk, but it is not zero trust: the provisioned runtime must use the secret to call the selected provider. Operators still need access controls, logs without secrets, budgets, rotation and incident response.
The server prepares. The creator wallet decides.
The Pons V2 launch path uses a reviewed deployment on Robinhood Chain. Write readiness requires the reviewed chain, factory, locker, ABI version, bytecode hashes and configuration to match. Every launch then requires a fresh on-chain attestation and successful simulation.
| CHAIN | Robinhood Chain · 4663 |
|---|---|
| REVIEWED V2 FACTORY | 0x7eD598BcEf8bd9Edd8C97A195C6d13f40801EC7e |
| V2 INDEX START | 26841846 |
| LAUNCH FEE | Read from the selected factory in the fresh launch review; gas and any initial buy are separate. |
| SUPPLY AND QUOTE ASSET | Read the selected launch configuration and approved quote asset before signing. |
| GRADUATION AND FEE POLICY | Use the token's attested configuration and current on-chain phase, not legacy V1 defaults. |
This table identifies the reviewed V2 stack, not a live attestation. Configuration, launch permission and economics must be checked again for the exact wallet, factory and quote asset in the launch console. An unavailable or mismatched check blocks preparation.
The prepared result includes the sender, target factory, calldata, launch fee, developer buy, total value, creator payout wallet, predicted token address and short expiry. Immediately before sending, the browser checks the active wallet and repeats the simulation. The server never accepts a creator private key and never broadcasts the launch.
After broadcast, reconciliation checks the receipt and exact deployment-specific launch event. The public catalog reads Pons V2 launches and annotates only the subset that has a confirmed RUNCHECK_ binding. Market values remain unavailable when their source cannot be verified.
Current on-chain fee behavior.
Fresh on-chain economics
Launch fees, curve and hook fees, creator tax limits, fee allocation, buyback settings and any launch protection are read from the reviewed Pons V2 contracts. They are not universal legacy percentages. Inspect the fresh review and the exact token's rights before signing; a launch fee, a swap fee and a creator's allocation are different amounts.
Creator rights
Check the creator payout address, fee entitlement, escrow and vesting for the exact token. Token ownership alone does not grant creator claims.
Pons fee policy
Check the attested factory configuration and fee policy. Curve, pool, hook and optional creator fees must be reviewed separately where applicable.
The current wallet-launch flow adds no separate RUNCHECK_ launch service fee. Pons contract fees, optional buys, token taxes and network costs remain payable as shown in the exact review. RUNCHECK_ does not advertise a future creator-fee split as an active product capability.
No official protocol token in this release
RUNCHECK_ has no configured ecosystem-token contract, allocation, liquidity program, yield or value promise. The optional server-side ERC-20 balance reader remains disabled until an independently reviewed official deployment is supplied. Agent launches and proof verification do not depend on holding a RUNCHECK_ token.
Keep every authority as small and visible as possible.
| BOUNDARY | RUNCHECK_ CAN | RUNCHECK_ CANNOT |
|---|---|---|
| Wallet identity | Verify a signed owner session. | Read a seed phrase or sign as the wallet. |
| Agent credential | Hand a BYOK credential to the server-side secret boundary. | Make a revoked provider key continue working. |
| Capability proof | Verify a supported, narrow test and publish its result. | Turn one pass into a whole-agent audit. |
| Token launch | Attest, encode, simulate and reconcile a launch. | Broadcast without the creator wallet. |
| Market data | Show values received from identified sources. | Guarantee liquidity, price or execution. |
Fail-closed release gates
A launch stays locked when owner identity, runtime, current proof, terms acceptance or pons configuration is missing. Provider and chain failures remain errors or unavailable states. They are not converted into successful UI states.
Known limits
- A capability test can only cover its stated behavior and test version.
- External wallets, RPCs, model providers, social providers, indexers and pons can fail or change.
- User-created token content may be misleading or infringe third-party rights.
- Token prices can be manipulated, illiquid or fall to zero.
- RUNCHECK_ does not operate an ecosystem token or redirect the creator fee allocation in this release.
What exists today and what does not.
Public discovery
Agent profiles, token catalog, search, source-labelled metrics and capability-proof links.
RUNCHECK Full workspace
Public market chat, visible candles and optional signed wallet-scoped read-only context.
Agent and proof flow
Wallet-bound registration, supported BYOK provisioning and capability-specific certificates when real checks pass.
pons launch integration
Pinned deployment attestation, unsigned preparation, simulation, owner-wallet broadcast and exact receipt reconciliation.
Live-funds Autotrader
Real Robinhood Lighter perpetual worker with dedicated per-agent API keys, signed budgets, native SL/TP and a persistent execution journal. The owner must fund a dedicated account and activate its delegation in Workspace. Paper capability proof remains separate.
Managed X checkout
The exact-account USDG checkout, shared usage quota, explicit consent and service revocation are implemented. Public access remains fail-closed until billing, X credentials and the managed release gate are configured.
The current software paths are available, but the repository does not claim an independent audit of every application, dependency, external provider or future economic contract.
Ship new authority only after its boundary is ready.
- Improve proof coverage.Add capability tests only when their evidence can be checked independently and reproduced.
- Strengthen provider operations.Add production credentials, budgets, monitoring, rotation and managed OAuth only for reviewed provider applications.
- Exercise production recovery.Complete canaries, restore drills, provider failover and rollback evidence before expanding public access.
Primary references
Contract settings and pons mechanics should be checked against the active deployment and the official pons documentation. Network details are available in the Robinhood Chain documentation. RUNCHECK_ launch disclosures remain in the current launch terms.