Ryntra Handbook
Product truth, current capabilities,
security boundaries and integration guidance.
One document instead of four. Every capability figure below is rendered from the same registry the product reads, so this page cannot claim more than the product does — and a claim that ages out of its review window downgrades itself here without anyone editing a sentence.
- 26 registered capabilities
- Registry reviewed 2026-08-08
- All claims within review window
- No dates · No percentages
Overview
Ryntra is a venue-neutral Risk, Strategy & Evidence OS for programmable assets. It helps a person understand what they are about to do, write the rule down before acting, check it against evidence that carries its own freshness, authorize it in their own wallet, and keep a record that survives the outcome.
What it is for
- Before an action — the evidence a decision depends on, with its provider, observation time and validity stated rather than assumed.
- At the moment of authorization — one deterministic policy result and one human act, recorded separately from each other.
- After settlement — what the chain actually confirmed, compared with what was authorized, and a receipt that can be checked independently.
What it is not
- Not an exchange, broker, custodian or adviser.
- Not a compliance certification, and not legal or tax advice.
- Not a guarantee of safety, execution success or profit.
- Not an autonomous system. No model sits on the decision path; deterministic code returns the outcome and a person authorizes it.
Current stage, stated plainly
Ryntra is founder-led and pre-release. 8 capabilities are live inside exactly the scope listed in Current capabilities. One complete lifecycle has been proven end to end on a public testnet, once, for one exact operation. Everything else is paper, preview, in build or behind a gate, and the register says which.
No independent security audit has been performed, and reliability work — idempotency under load, replay and time-of-check-to-time-of-use protection, RPC failure handling, recovery and monitoring — is a separate gate that is not complete.
Product model
There is one Evidence Kernel. Everything a person or an application sees is a surface over it, which is why a fact cannot be true in one product and false in the other.
| Surface | Who it is for | What it does |
|---|---|---|
| Ryntra Workspace | Self-directed people | Understand risk, plan, check the plan against evidence, authorize a supported action in your own wallet, and review what happened. The human-facing product and the reference implementation of the kernel. |
| Ryntra Guard | Applications and teams | The same evidence, decision, reconciliation and receipt model consumed through documented boundaries. A developer preview — see Developers. |
| Evidence Kernel | Neither — it is underneath both | Intent, evidence status, policy decision, human authorization, settlement, reconciliation and receipt. One implementation, shared. |
Why evidence, policy, authorization and execution are kept separate
Collapsing them is what makes a system unreviewable after the fact. If the policy result and the human act are one object, nobody can later tell whether a person agreed with the rule or was simply carried past it. If execution is not separate from authorization, an uncertain broadcast has no safe state to fall back to.
- Human authorization is bound to the intent revision, the evidence root and the execution fingerprint. Changing the amount, asset, recipient, chain, route or calldata invalidates it.
- An uncertain broadcast keeps the captured transaction hash and moves to a reconciliation-required state. It never triggers an automatic second broadcast.
- Unknown never renders as complete. Missing, stale or unsupported evidence stays visible instead of being defaulted to zero.
Current capabilities
The register the rest of the site reads from. A badge that says “Live” elsewhere is only honest because the scope behind it is here: what the claim covers, where it stops, and when it was last checked.
Usable now, inside the exact scope stated on the row. Not a promise about anything outside it.
| Capability | Scope | Stated limitation | Reviewed |
|---|---|---|---|
| Arcus spot RFQ | Arcus · arcus-spot-rfq · USDG↔TSLA · USDG↔AAPL · USDG↔AMD | Wallet-signed RFQ execution is limited to USDG↔TSLA, USDG↔AAPL, and USDG↔AMD on Arcus spot. Route availability, wallet state, and user eligibility are checked separately for every attempt. | 2026-08-08 |
| Arcus account read | Arcus · arcus-perps-clob · authorized-arcus-account-markets | Reads supported Arcus account data by public wallet address only. It does not authorize live perps, withdrawals, another user, or execution on another venue. | 2026-08-08 |
| Arcus trade-key setup | Arcus · arcus-account-authorization | This Arcus-only setup does not enable live SmartTrade or perps execution and never gives Ryntra withdrawal authority. | 2026-08-08 |
| Supported-route readiness | supported-paper-markets · arcus-supported-spot-assets | The current checks cover supported paper plans and Arcus spot inputs. They are not a safety guarantee, eligibility verdict, universal scanner, or proof that execution will succeed. | 2026-08-08 |
| Specialist RWA risk context | Arcus · supported-tokenized-assets | Shows verified fields for supported tokenized-asset contracts only. It is not a universal RWA, issuer, oracle, eligibility, or safety assessment. | 2026-08-08 |
| Portfolio heat | Arcus · connected-wallet-supported-stock-token-holdings | Shows exposure, concentration, and correlated-family warnings only for supported Stock Token holdings in the connected public wallet. It excludes USDG cash and does not claim complete, cross-venue, or scenario-loss portfolio risk. | 2026-08-08 |
| Uniswap quote comparison | Uniswap · uniswap-rhchain-amm · same-supported-spot-pair-and-exact-input-amount | Compares the same supported pair and exact input amount as the Arcus quote. It is informational only: no Uniswap route selection or execution is shipped, and unavailable or empty liquidity remains explicit. | 2026-08-08 |
| Telegram decision recap | supported-paper-and-observed-records | Summarizes records in the current beta scope. A delivered message is not a trade instruction, execution receipt, or complete ReviewRecord. | 2026-08-08 |
Proven end to end on a public testnet for one exact operation. Testnet assets have no intended monetary value, and mainnet support is not claimed.
| Capability | Scope | Stated limitation | Reviewed |
|---|---|---|---|
| Arc intent normalization | Arc Public Testnet · USDC | Covers the direct-EOA ERC-20 USDC transfer normalized in the recorded run. Other operation types are modelled but unproven. | 2026-08-08 |
| Arc evidence and policy preflight | Arc Public Testnet · USDC | Evidence status and policy decision are independent axes evaluated by deterministic code against one versioned policy. No model participates, and `ALLOWED_BY_POLICY` asserts nothing about safety or legality. | 2026-08-08 |
| Arc human authorization | Arc Public Testnet · USDC | The authorization record is a distinct act from the wallet signature and is bound to the intent revision, evidence root and execution fingerprint. A material change to amount, asset, recipient, chain, target or calldata invalidates it. | 2026-08-08 |
| Arc Testnet settlement | Arc Public Testnet · USDC | One owner-authorized transfer of 1.000000 USDC on Arc Public Testnet, chain 5042002. The wallet owner signs; Ryntra holds no key, seed phrase or withdrawal authority. Mainnet is not claimed. The App Kit swap is a separate operation with its own record and proves nothing about this one. | 2026-08-08 |
| Arc expected-versus-actual reconciliation | Arc Public Testnet · USDC | Compares the authorized effects with the effects read back from the chain, matching only the ERC-20 Transfer log. Arc emits the same movement twice — 18-decimal native and 6-decimal ERC-20 — and reading the wrong one is a 10^12 error. | 2026-08-08 |
| Arc Execution Receipt | Arc Public Testnet · USDC | A structured, hash-checkable record linking intent, evidence, decision, authorization, settlement and reconciliation. It is integrity-checkable, not an immutable legal receipt, and nothing is anchored onchain. | 2026-08-08 |
Runs, but simulated. Nothing reaches a venue and no value moves.
| Capability | Scope | Stated limitation | Reviewed |
|---|---|---|---|
| SmartTrade plan | supported-paper-markets | Records and simulates a plan only. It creates no real order and does not imply that a live route will be added or become eligible. | 2026-08-08 |
| Decision journal | supported-paper-records · observed-arcus-fills | Covers paper records and observed Arcus fill context. The complete disposition, reconciliation, ReviewRecord, and StrategySpec version lineage are not shipped. | 2026-08-08 |
Exists in the product but is not publicly released.
| Capability | Scope | Stated limitation | Reviewed |
|---|---|---|---|
| Strategy Lab V1 | supported-import-fixtures | Local review candidate only: not deployed, absent from navigation, persistence-disabled, and unable to execute trades. Manual and template operation remains authoritative. | 2026-08-08 |
Registered work that has not started. Never rendered as available, and never as under way.
| Capability | Scope | Stated limitation | Reviewed |
|---|---|---|---|
| Risk and readiness scanner | future-supported-instruments | No user-facing cross-venue scanner is shipped. The landing block demonstrates the method on fixed sample values and is labelled with this maturity. Future discovery must show provenance and freshness and cannot present a recommendation as certainty. | 2026-08-08 |
| Personal workspace | future-supported-instruments | No configurable Simple/Pro workspace is shipped. The landing preview shows the intended arrangement and carries this maturity. Depth may change how much is shown, never what is true. | 2026-08-08 |
| Complete decision loop | future-supported-strategy-evidence | The full StrategySpec to deterministic readiness to disposition to DecisionReceipt to ReviewRecord to human-approved next StrategySpec loop is not shipped as one product flow. | 2026-08-08 |
| Complete portfolio risk | future-complete-multi-asset-portfolio | Portfolio-wide exposure, concentration, correlation, and scenario loss across normalized venues and asset classes are not available in the current product. | 2026-08-08 |
| Multi-venue overlay | future-normalized-connection-scope | No additional user-facing venue is selected or shipped. The first accepted connection may be manual or read-only and may be no venue at all. | 2026-08-08 |
| Replay and robustness | future-supported-strategy-evidence | Walk-forward, regime, and replay evidence depends on verified data rights and may emit only paper or no-trade records until separately released. | 2026-08-08 |
Deliberately behind a further gate — security, reliability or authorization work comes first.
| Capability | Scope | Stated limitation | Reviewed |
|---|---|---|---|
| Professional order-flow views | feed-supported-clob-instruments | DOM, tape, footprint, and true volume profile require a suitable CLOB trade feed and verified display and storage rights; RFQ and AMM data cannot substitute. | 2026-08-08 |
| Guarded automation | future-mandate-scoped-instruments | Automation is not shipped and cannot start before scoped authority, simulation, human authorization, limits, idempotency, kill switch, audit, and incident gates pass. | 2026-08-08 |
| Independent sequencer monitoring | supported-robinhood-chain-routes | Ryntra does not independently monitor Robinhood Chain sequencer uptime because the current surface has no verified observable source. The signal remains unknown, never healthy by assumption. | 2026-08-08 |
Decision method
How a decision is made, and how the words describing it are defined. This section is the reason a state word on any Ryntra surface means the same thing on every other one.
The stages
| Stage | Takes | Produces | Never |
|---|---|---|---|
| Observe | An asset, a venue, a wallet, a market session. | Facts, flags, explicit unknowns, each with a source and an observation time. | Declare an asset safe. Popularity is evidence of attention, not of safety. |
| Plan | An intention, a risk budget, the limits a person is willing to accept. | A PlanDefinition: entry, exit, invalidation, max loss, required evidence. | Invent a target, a size or a level the user did not choose. |
| Gather evidence | A normalized intent and the evidence that intent requires. | An EvidenceBundle: provider, source reference, observed-at, validity, coverage, digest. | Fill a gap with a plausible value. Missing stays missing, and stale stays stale. |
| Evaluate policy | The intent, the evidence bundle, and one versioned policy. | ALLOWED_BY_POLICY, REVIEW_REQUIRED or BLOCKED_BY_RULE, with the rule that produced it. | Mean safe, legal or profitable. It means the action matched the configured rules against the evidence available at that moment. |
| Authorize | Exactly what will be sent: target, calldata, amount, recipient, fee ceiling. | An authorization record bound to the intent revision, evidence root and execution fingerprint. | Sign for you. Ryntra holds no key, no seed phrase and no withdrawal authority. |
| Execute | The authorized payload and the fingerprint it was bound to. | A submission, a transaction reference, and an execution state that survives failure. | Rebroadcast on its own after an uncertain result. The captured hash is kept and the state says so. |
| Reconcile | The effects that were authorized and the effects the chain actually confirmed. | A reconciliationStatus of NOT_RECONCILED, RECONCILIATION_REQUIRED, MATCHED or DEVIATION_RECORDED — and, only after finalization, a structured receipt. | Smooth over a difference. A drift is reported as a drift. |
| Review | The receipt, the original plan, and what the person actually did. | A review record and the next version of the plan — approved by a human. | Promote a review into a recommendation, or a past outcome into a forecast. |
Five independent axes
A decision has five states, and they are tracked separately on purpose. Collapsing them into one verdict is the specific way a missing input disappears: a run with unresolved evidence and a clean policy result would read the same as a run with both.
Allowed by policy does not mean safe, legal or profitable. It means the action matched the configured rules against the evidence available at that moment — two things a reader can check, and neither of which is a promise about what happens next.
How maturity is defined
- Live — Usable now, inside the exact scope stated on the row. Not a promise about anything outside it.
- Testnet — Proven end to end on a public testnet for one exact operation. Testnet assets have no intended monetary value, and mainnet support is not claimed.
- Paper — Runs, but simulated. Nothing reaches a venue and no value moves.
- Preview — Exists in the product but is not publicly released.
- In build — Designed and specified, and being built. Never rendered as available.
- Planned — Registered work that has not started. Never rendered as available, and never as under way.
- Behind a gate — Deliberately behind a further gate — security, reliability or authorization work comes first.
- Research — A direction in the canon with no adapter and no implementation.
Rules that run without anyone editing a page
- Every claim carries a review window — 30 days for live and route claims, 90 for roadmap claims. Past it, the claim renders as re-verifying rather than at its old confidence, on every surface at once.
- Route-bound claims are re-checked against the route registry at read time. A route that drifts downgrades the claim automatically.
- Missing, stale, conflicting or unsupported evidence makes the system fail closed: the action is refused or held rather than proceeding on an assumption. An unknown never renders as a complete or green result.
- A capability is never promoted by copy. Marketing text is not the source of product truth, and the tests fail a page that tries.
- No entry carries a delivery date, a percentage or a countdown. Progress is gate-based: a capability moves when its evidence exists.
Where the decision method stops today
The complete StrategySpec → readiness → disposition → DecisionReceipt → ReviewRecord loop is the target model. It is not shipped end to end today, and the register above is where the boundary between the model and the product is drawn.
AI may explain, formalize, compare, translate and review. It never supplies a missing fact, decides policy, authorizes, signs or executes. Strategy Lab is a preview and is not publicly released.
Evidence & receipts
One operation has been proven end to end on a public testnet. It is recorded here in full, because a lifecycle that only completes in a diagram is not evidence of anything.
| Operation | Direct-EOA ERC-20 USDC transfer · 1.000000 USDC |
|---|---|
| Network | Arc Public Testnet · eip155:5042002 |
| State | TESTNET — direct-EOA ERC-20 USDC transfer only |
| Transaction | 0x6476dc81a38f0cbe385eab5162f391d7954a992a443db7d268e07b2698b8d5f9 |
| Reconciliation | MATCHED · ONCHAIN_VERIFIED — expected fee 0.001548973026 USDC, actual 0.001530838950 USDC, read back from the chain rather than from the estimate. |
| Receipt | rcpt_b6b010ec3d5e4be19b4c26cdfce28e73 · receipt hash and SHA-256 integrity recomputed independently of the application. |
| Not covered | Two recorded runs prove this lifecycle completed twice — one direct-EOA USDC transfer and one App Kit USDC→EURC swap. Two operations are not a reliability claim, mainnet is not claimed, and no other pair, amount or route is proven. |
What a receipt contains
- The versioned intent and its revision.
- The evidence root, with provider, source reference, observation time, validity and coverage for every input.
- The policy version, its digest and the deterministic decision it returned.
- The human authorization, recorded as a separate act with its own binding.
- The execution fingerprint — exact target, calldata and native value.
- Expected effects, actual effects, and any drift between them.
- A receipt hash and an integrity digest, both checkable outside the application.
No personal data and no full receipt is written onchain. Public proof may redact privacy-sensitive fields, but never so far that the run stops being verifiable against the chain.
Security & custody
A control layer is only as credible as the things it refuses to be able to do. These limits are structural rather than policy, and this section ends with what has not been independently reviewed.
Custody
- Ryntra never accepts deposits and holds no user funds.
- There is no deposit address, no pooled balance and no withdrawal path, because there is no component that could hold one.
- Assets stay in the user’s own wallet throughout the entire lifecycle.
Keys and signing
- Ryntra never requests or receives a seed phrase, a private key or an entity secret. No interface asks for one, and no support conversation ever will.
- Ryntra never signs and never broadcasts on a user’s behalf. There is no autonomous execution path.
- Human authorization is recorded as an act distinct from the wallet signature, and bound to the intent revision, the evidence root and the execution fingerprint.
Secrets, data and environment separation
- Server credentials stay server-side and never appear in a browser bundle, a response or a log. The test suite fails if network configuration leaks into the client.
- A network that carries real value cannot be selected by configuration drift. Choosing one raises an explicit gate error instead of silently falling back to testnet.
- The lifecycle store keeps the intent, its evaluation, the authorization, the execution record and the receipt. Every object is tenant-scoped.
- The Arc testnet surface is deployed as its own project with its own database. It shares neither a deployment nor a data store with anything else.
- Administrative surfaces are gated by their own authenticated session and their secrets are deliberately absent from the testnet deployment — so those routes refuse everyone there, including the founder.
- The lifecycle store declares its own durability. Where a deployment shape cannot preserve state safely, every state change is refused rather than silently lost.
- What is collected, why, for how long, and how to have it removed is set out in the privacy notice.
What has not been reviewed
- No independent security audit has been performed. Nothing on this site should be read as an audited or certified system.
- The Arc lifecycle has one recorded successful run. That is evidence the lifecycle works, not a reliability claim.
- Reliability work — idempotency under load, replay and time-of-check-to-time-of-use protection, RPC failure handling, recovery and monitoring — is a separate gate and is not complete.
- Evidence can be partial, stale, conflicting or unavailable. The product reports that state rather than hiding it, but reporting it is not the same as removing the risk.
Disclosure
If you find a security issue, write to hello@ryntra.io with enough detail to reproduce it. Please do not test against other people’s wallets or data, and give us a chance to fix the issue before publishing it.
There is no bug-bounty programme and no dedicated security address yet. Saying so is more useful than publishing an inbox nobody monitors.
Ecosystem workspaces
A chain settles. A venue executes. They are listed apart because they are not the same thing — and a direction appears here once it is registered, not once it works.
Most of these are registered and not built, which is what the state word says. Nothing below is a partnership, an endorsement or a claim of support by the named project.
Chain packs — where value settles
| Chain | State | Role | Where it stops |
|---|---|---|---|
| Arc | Testnet | Stablecoin-native settlement. One recorded lifecycle proof, end to end on public testnet. | One operation is proven: a direct-EOA ERC-20 USDC transfer. Reliability under load is not established, and mainnet is gated behind canon Gate D. |
| Robinhood Chain | Live | Tokenized-asset settlement. Stock Tokens, market-hours and reference-price evidence. | Execution is bounded to three registered spot routes. The Stock Token read-only API and the testnet chain are not integrated or verified. |
| Ethereum / EVM core | Research | The shared EVM foundation Base, Arbitrum and Robinhood Chain would all reuse rather than each rebuild. | No adapter exists. The direction is in canon §11 and sequenced behind Arc. |
| Solana | LiveRead-only | Token-2022 asset semantics: mint identity, issuer powers, transfer-affecting extensions, exact transfer preflight, owner policy, and live read-only venue quotes. | Reads are live and read-only, including mainnet swap quotes through Jupiter's lite tier with the review-policy verdict inline. Execution has no code path: the first signed lifecycle is the founder-gated devnet packet RYN-SOL-A7, and mainnet execution sits behind its own later canary gate. |
| Stellar | Testnet | Issuer controls, trustline requirements, holder rights and eligibility, anchors and the on/off-ramp boundary, path payments, and RWA asset semantics. | One operation is proven: an owner-signed classic XLM payment on Stellar Testnet, reconciled against the ledger and receipted. Mainnet is read-only and the browser is not permitted to reach it. Policy evaluation and route evidence are registered as planned and not built, which is why every receipt carries policyVersion and routePlanHash as null. Every value-moving operation beyond the proven one carries its own gate. |
| XRPL | Research | Cross-currency payment paths, issued assets and issuer controls. | Not in the product canon until a governance-class decision adds it. Read-only issued-asset scanning would come first. |
Venue adapters — how an action is quoted or executed
| Venue | State | Role | Where it stops |
|---|---|---|---|
| Arcus Spot | Live | The current execution provider for supported Robinhood Chain spot routes. | Wallet-signed RFQ execution covers USDG↔TSLA, USDG↔AAPL and USDG↔AMD only. Every other pair is unsupported, not merely unlisted. |
| Arcus Perps | LiveRead-only | Perpetuals market data, account reads and paper planning on live data. | No order is ever submitted. Order lifecycle, fills, funding and liquidation semantics must pass canon Gate G2 before anything executes. |
| Uniswap v3 | LiveRead-only | Independent on-chain quote comparison against the executing route. | Quotes only, and honestly: at verification the stock-token v3 pools held no liquidity, which the comparison reports rather than hides. Nothing executes through it. |
| 0x | Research | A candidate second route on Robinhood Chain, for comparison before anything else. | No adapter exists. The first step is a non-broadcast quote canary — no production switch, fee, signature or funds action. |
| Hyperliquid HyperCore | Research | A professional perpetuals venue. HyperCore is the venue; HyperEVM would be a separate chain pack and is not this. | A read-only adapter exists behind the venue seam and was live-probed, but no user surface ships it. Builder-code economics stay off until disclosure, revocability, a fee cap and legal review all pass. |
Roadmap
What is being built, kept apart from what is live. Nothing here carries a date, a percentage or a countdown — a capability moves when its evidence exists, and it moves in the register above first.
| Direction | State | What it means today | Stated limitation |
|---|---|---|---|
| A broader scanner | Planned | Facts, flags, unknowns and freshness beyond the currently supported scope — never a safety score. | No user-facing cross-venue scanner is shipped. The landing block demonstrates the method on fixed sample values and is labelled with this maturity. Future discovery must show provenance and freshness and cannot present a recommendation as certainty. |
| The complete decision loop | Planned | Plan to readiness to disposition to receipt to review to the next plan, as one continuous flow. | The full StrategySpec to deterministic readiness to disposition to DecisionReceipt to ReviewRecord to human-approved next StrategySpec loop is not shipped as one product flow. |
| A personal workspace | Planned | Simple and Pro depth over the same facts, arranged the way you actually work. | No configurable Simple/Pro workspace is shipped. The landing preview shows the intended arrangement and carries this maturity. Depth may change how much is shown, never what is true. |
Ryntra has no token promise, no airdrop and no allocation. A token remains optional only through a future readiness gate, and no evidence, policy or safety behaviour will ever depend on one.
FAQ
Can Ryntra move my funds?
No. There is no deposit path, no withdrawal capability and no signing key. Your wallet signs; Ryntra records what you authorized and reconciles what the chain confirmed.
Does an AI decide anything?
No. Deterministic code returns every policy result. AI may explain, formalize, compare, translate and review, and it is never on the decision path.
What does “Live” actually mean here?
Usable now, inside exactly the scope on its row in Current capabilities — and nothing outside it. If the claim ages past its review window it downgrades itself to re-verifying automatically.
Is this on mainnet?
No. The proven lifecycle ran on Arc Public Testnet. Testnet assets have no intended monetary value, the network may reset or be unavailable, and mainnet support is not claimed.
How do I get access?
Through one confirmation in the Telegram bot at /beta. No email, no password, nothing to deposit. It is a confirmation gate, not a product login.
Can I build on it?
The Guard surface exists as a developer preview with a versioned HTTP API and an OpenAPI contract. What is implemented and what is deliberately not published is listed on Developers.
Changelog
What this document is bound to, and how to tell whether it has gone stale.
| Capability registry | 26 entries, reviewed 2026-08-08. Every claim is inside its review window. |
|---|---|
| Proven lifecycle | One direct-EOA ERC-20 USDC transfer on Arc Public Testnet, reconciled and receipted. Receipt rcpt_b6b010ec3d5e4be19b4c26cdfce28e73. |
| Public repository | github.com/ryntra-io/ryntra-arc-demo Bounded MIT extraction at b8af07a0f2e7216fc972756a1af84f91ea688298, published ahead of the current source. Bounded public extraction; it predates the corrective candidate and does not prove source or deployment parity. |
| Superseded pages | /methodology, /status and /security were four public documents restating the same boundaries. They now redirect into this one, and their old anchors keep working. |
This page has no operational status feed. It reports capability maturity and its review dates, which is not the same thing as uptime — and publishing a status page that measures nothing would be worse than not having one.