Ryntra Guard — developer preview
Evidence before settlement.
A reviewable record after it.
Guard is a provider-neutral decision and settlement evidence layer for programmable money. It normalizes an intent, resolves the evidence that intent requires, evaluates one versioned policy, preserves human authorization as a separate act, and reconciles what the network actually confirmed against what was authorized.
- Arc Testnet MVP · Developer Preview
- 28 operations · 25 paths
- OpenAPI 3.1
- No hosted endpoint
Quickstart
There is no hosted endpoint and no key issuance, so the honest quickstart is not `curl` against a URL. It is three steps that each end in something you can verify yourself.
1 — See the model working
The Arc workspace runs the same kernel this API exposes. It needs no account: the intent, the evidence status, the policy decision, the authorization boundary and the reconciliation are all visible as objects rather than as screenshots.
2 — Read the contract
openapi/ryntra-guard-v1.yaml is OpenAPI 3.1 and describes exactly 28 operations across 25 paths. Nothing is documented there that is not implemented, and the test suite for this page fails if the two ever disagree.
3 — Run it locally
The bounded public extraction at github.com/ryntra-io/ryntra-arc-demo is MIT-licensed and self-contained. It is an extraction taken at b8af07a0f2e7 and bounded public extraction; it predates the corrective candidate and does not prove source or deployment parity.
There is no production base URL, no signup, no API key issuance and no rate-limit tier. The OpenAPI document lists one local server, which is the truth rather than a placeholder.
Architecture
Guard is not a second engine beside the Workspace. Both surfaces resolve through the same Evidence Kernel, which is why an integration cannot be shown a fact the product would render differently.
01 — Observe
Plannedfuture-supported-instruments · Arcus · supported-tokenized-assets
- Takes
- An asset, a venue, a wallet, a market session.
- Creates
- Facts, flags, explicit unknowns, each with a source and an observation time.
- Accountable
- Ryntra Scanner, reading external providers.
- Never
- Declare an asset safe. Popularity is evidence of attention, not of safety.
Integration modes
| Mode | What it means | State |
|---|---|---|
| Advisory | Guard returns evidence status, rule evaluations, the decision and its reasons. The partner decides what to do with it and keeps full control of the flow. | Implemented in source |
| Application-gated | The partner application requires a valid decision before it opens its signing flow. The gate lives in the partner product; Guard supplies the decision it gates on. | Implemented in source |
| Orchestrated | Guard prepares the exact payload — target, calldata, value, fee ceiling — and binds it to an execution fingerprint. The user or partner wallet still signs it. | Implemented for the recorded Arc operation |
| Signer-enforced | A wallet or custody layer refuses to execute without a valid decision. That enforcement lives in the signer, not in an advisory API, and Ryntra does not have it. | Designed, not built |
Persistence and durability
The lifecycle store declares its own durability rather than assuming it. Where a deployment shape cannot preserve state safely, a state change is refused instead of being silently lost.
- Memory — ephemeral. Suitable for local exploration and nothing else.
- File — single-writer. Safe for one process; not for a serverless deployment with concurrent instances.
- Postgres — the multi-writer implementation, with a compare-and-set contract on every atomic ledger operation.
/health reports which adapter is in use. Live multi-writer Postgres evidence for the current candidate is unverified.
Guard API
Every implemented operation, grouped by what it is for. This is the whole surface, not a selection — a partner should be able to see its real size before deciding whether it fits.
Authentication
- BearerAuth — a tenant-scoped API key. Server-to-server only; never embed it in browser code.
- PayoutPrincipalAuth — an opaque payout principal token. The server stores only SHA-256 digests and derives tenant, principal and the REQUESTER / APPROVER / EXECUTOR / POLICY_ADMIN / AUDITOR roles from its registry. No role implies another, and an ambiguous configuration fails closed.
- Mutating operations accept
Idempotency-Key, and every operation accepts a correlation id that is echoed back in the response and the logs. - Errors are structured rather than prose: a stable code, the reason, and the field that caused it.
Intent lifecycle
The complete decision path: create a versioned intent, resolve evidence, evaluate one immutable policy, record human authorization, reconcile a partner-executed transaction, then read the receipt.
Proven end to end once on Arc Public Testnet for one exact operation
| Method | Path | What it does |
|---|---|---|
| GET | /v1/intents | List the tenant-scoped intent ledger, newest first |
| POST | /v1/intents | Create a versioned execution intent |
| GET | /v1/intents/{intentId} | Get one tenant-scoped intent |
| POST | /v1/intents/{intentId}/preflight | Evaluate current evidence against the exact server-owned immutable policy |
| GET | /v1/evaluations/{evaluationId} | Get a tenant-scoped public evaluation |
| POST | /v1/intents/{intentId}/authorize | Record explicit human authorization for the exact fingerprint |
| POST | /v1/intents/{intentId}/executions | Record or reconcile a partner-executed Arc Testnet transaction |
| GET | /v1/intents/{intentId}/status | Get independent evidence, policy, authorization, execution and reconciliation states |
| GET | /v1/intents/{intentId}/receipt | Get a finalized intent-to-settlement evidence receipt |
Treasury payouts
A role-separated payout instruction with two-approver human authorization, an atomic daily-outflow reservation, an unsigned execution package and independent reconciliation of an externally obtained transaction hash.
Implemented in source · no live wallet-signed payout has been performed
| Method | Path | What it does |
|---|---|---|
| GET | /v1/payouts | List the authenticated tenant's Arc payout ledger |
| POST | /v1/payouts | Create one Arc Public Testnet USDC payout instruction |
| GET | /v1/payouts/{payoutId} | Get one tenant-scoped payout and its bound artifacts |
| POST | /v1/payouts/{payoutId}/preflight | Collect fresh Arc evidence and evaluate the exact payout |
| POST | /v1/payouts/{payoutId}/approvals | Approve or reject the exact payout fingerprint |
| GET | /v1/payouts/{payoutId}/execution-package | Get the ten-field unsigned wallet transaction package |
| POST | /v1/payouts/{payoutId}/executions | Record an external transaction hash and independently reconcile it |
| GET | /v1/payouts/{payoutId}/status | Get the payout lifecycle projected from stored artifacts |
| GET | /v1/payouts/{payoutId}/receipt | Get the payout evidence receipt |
Payout policies
Tenant-owned, versioned policy. A version is written and then activated as a separate act, so a rule can never change under an instruction that was already approved against it.
Implemented in source · release parity unverified
| Method | Path | What it does |
|---|---|---|
| GET | /v1/payout-policies | List tenant payout policies |
| POST | /v1/payout-policies/{policyId}/versions | Create a new immutable policy version |
| POST | /v1/payout-policies/{policyId}/versions/{version}/activate | Activate one exact policy version |
Payout beneficiaries
Versioned recipients with an activation delay. Adding a destination and being able to pay it are deliberately two different moments.
Implemented in source · release parity unverified
| Method | Path | What it does |
|---|---|---|
| GET | /v1/payout-beneficiaries | List tenant beneficiaries |
| POST | /v1/payout-beneficiaries | Create a beneficiary |
| POST | /v1/payout-beneficiaries/{beneficiaryId}/versions | Create a new immutable beneficiary version |
| POST | /v1/payout-beneficiaries/{beneficiaryId}/versions/{version}/activate | Activate one exact beneficiary version |
| POST | /v1/payout-beneficiaries/{beneficiaryId}/disable | Disable a beneficiary |
Capabilities & health
What the prototype says about itself. `/v1/capabilities` returns public capability truth; `/health` returns non-sensitive readiness, including which persistence adapter is actually in use.
Implemented in source
| Method | Path | What it does |
|---|---|---|
| GET | /v1/capabilities | Get public prototype capability truth |
| GET | /health | Get non-sensitive prototype health |
SDK & examples
A headless TypeScript client and one runnable server example live in the monorepo. Neither is published, and the client never handles a private key.
What the client does
- Types every request and response against the OpenAPI contract.
- Carries the tenant credential in a header on the server side, and refuses to run in a browser context where that credential would be exposed.
- Passes
Idempotency-Keyand correlation ids through without inventing retry behaviour of its own. - Never signs, never broadcasts and never holds key material. Execution stays with the partner’s wallet or custody layer.
The one worked example
The example walks the intent lifecycle end to end against a local server: create the intent, run preflight, read the evaluation, record authorization, submit an externally obtained transaction hash for reconciliation, then fetch the receipt and recompute its integrity digest independently of the application.
That last step is the point of the example. A receipt you can only verify by asking the system that issued it is not evidence.
Limits & boundaries
The responsibility boundary is part of the interface. An integration that assumes any of the following is integrating against a product that does not exist.
- Ryntra never receives a private key, a seed phrase, an entity secret or withdrawal authority.
- Ryntra never signs, and never broadcasts on a user's behalf.
- A policy result is not a safety, legality, compliance or profitability opinion.
- Evidence can be partial, stale, conflicting or unavailable, and the API says which.
- The partner keeps its own brand, UI, wallet relationship and execution provider.
- No model sits on the decision path. Deterministic code returns the outcome.
Operational limits, stated
- One lifecycle has been proven end to end on Arc Public Testnet: a direct-EOA ERC-20 USDC transfer, reconciled, receipt rcpt_b6b010ec3d5e4be19b4c26cdfce28e73. 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.
- No independent security audit has been performed.
- Testnet assets have no intended monetary value. The network may reset, change or be unavailable, and mainnet support is not claimed.
- No payout has been executed with a live wallet signature. The payout surface is implemented in source and its live behaviour is unverified.
Not published
These are in the product canon and are not built or not released. Listing them as available is the one thing an evidence layer must never do — so they are listed here instead, in the same type size as everything that works.
| Surface | Where it actually stands |
|---|---|
| npm package | A headless TypeScript client exists in the monorepo with one runnable server example. It is not published to a registry, and it never handles a private key. |
| MCP server | Agent access to the evidence and decision model is a canon direction behind its own gate. No MCP tool is exposed today. |
| Webhooks | There is no outbound delivery, no signing secret and no retry policy. State is read, not pushed. |
| x402 access | Machine-payable access is in the canon and is not implemented. |
| Hosted API | The OpenAPI document lists one local server. There is no hosted production endpoint, no key issuance and no SLA. |
When one of these ships it will appear in the capability register first, with its scope and its stated limitation, and only then on this page.
Contract & changelog
| Contract | OpenAPI 3.1, 28 operations across 25 paths, validated in CI. No endpoint is documented that does not exist. |
|---|---|
| Versioning | Every path is under /v1. Receipts and policies carry their own schema versions, and existing receipt bytes are asserted unchanged when a new version is added. |
| Public extraction | 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. |
| Capability truth | Maturity for every claim on this page lives in the capability register, reviewed 2026-08-08. |
Building on Arc, or integrating Guard? hello@ryntra.io