Know the system.
Know its limits.

One project. Distinct boundaries.

KRYPTA is being built as a hosted market service for people and software agents. Customers should use the website or an approved remote agent connection, not install a local server. The website, development engines and future onchain settlement remain separate components. A working interface does not imply live financial execution.

1. The public website

   Real read-only market and network data, optional read-only wallet inspection, plus isolated paper demonstrations of orders, managed agents and swaps.

2. The order-book reference v0.4.0

   Development matching, signed policies, managed paper allocations, an HTTP readiness service and test-collateral Solidity contracts.

3. The swap reference v0.1.0

   A Python accounting reference plus separate experimental Solidity contracts, real Groth16 proof tooling and a Poseidon/encrypted-note client. Neither is deployed.

Read the status, not the styling.

Robinhood Chain is not a KRYPTA deployment

Robinhood mainnet uses chain ID 4663; testnet uses 46630. The swap design targets mainnet 4663. The offline order-book engine defaults to a testnet-domain fixture, 46630. These identifiers separate signatures and replay domains; they do not show that KRYPTA contracts exist on either network.

Uniswap publishes v4 deployment information for Robinhood Chain. A deployed third-party venue is not an implemented KRYPTA adapter, audited integration or assurance of liquidity.

Observe the market.

The Markets page reads public trending-pool and OHLCV data from GeckoTerminal. Trending order is the provider’s ranking, not a KRYPTA recommendation or a complete ranking of all assets.

• Select a pool to inspect its price, 24-hour change, market cap, fully diluted valuation (FDV), volume, liquidity and activity.
• Switch between 1-hour and 1-day candle intervals. Historical prices are displayed in USD, with UTC time labels.
• Search and filter the loaded pool list. Sorting changes the loaded results, not the entire market.
• Use the source link to verify pool and token identity independently.

Missing, delayed or unavailable data

A missing market cap stays “—”; FDV is not substituted for it. Public prices can be delayed, incomplete or manipulated, especially in low-liquidity pools. Candle retrieval can fail independently of the pool list.

Refresh retries a public read. A failed refresh may leave older values visibly marked as stale. Sample mode must be selected explicitly and is labeled fictional; it is never silently presented as live data. Switching back to live clears sample values before requesting a fresh feed.

Explore the interface, not an exchange.

The home-page terminal contains fictional ETH/USD prices and a sample order book. Choose a side, enter a limit price and size, then add a sample order. The page records your sample in memory without matching or sending it anywhere.

• Limit prices: 0.01 to 1,000,000 USD, with up to two decimal places.
• Sizes: 0.001 to 1,000 ETH, with up to three decimal places.
• The list is capped at 20 sample orders. Cancel removes one; Reset clears the list.
• Reloading the page clears all samples. There is no account or persistent history.

The separate Python reference does perform deterministic paper matching. The website does not call it, and an interface sample is not an engine fill.

Delegate within a boundary.

The Agents page demonstrates a managed-agent workflow. It is a rule-based, fixed-price simulation, not an AI investment strategy, remote agent service or profit forecast.

1. Configure: enter a fictional allocation, allowed markets, order ceiling, session turnover, position ceiling and expiry.
2. Review: inspect the mandate and acknowledge that all funds are fictional.
3. Activate the demo: preview a sample decision and its policy checks.
4. Apply a simulated fill: explicitly update the local paper position. Receipts remain in this page.

Understand the controls

• Turnover counts accepted simulated notional. Pausing does not restore spent capacity.
• Pause discards a pending decision and blocks new decisions until you resume within the same mandate.
• Halt ends the browser mandate. It does not close existing paper positions. Reset is required to start over.
• Expiry blocks new activity. Quote or market motion is not modeled by the browser demo.
• Loss cutoff is an illustrative circuit breaker, not a guaranteed maximum loss or stop-loss fill. Fixed sample prices mean the page does not model investment returns.

What the offline managed-agent reference adds

The v0.4.0 order-book reference supports artificial owner-approved allocations, built-in and external signed sessions sharing account-wide limits, and atomic caller-driven target cycles. It tests revocation, halt/resume, stale marks, expiry, loss latching and encrypted local recovery. No background investment service, real deposits or remote enrollment is enabled.

Developer discovery versus customer connection

For engineers only, python -m private_clob.mcp exposes discovery with no accounts, keys or trading authority. Authenticated paper commands require a trusted local host to provision test sessions and a separate local signer. The MCP tools cannot grant themselves permissions, withdraw assets or sign arbitrary transactions.

The development MCP transport is a limited JSON-RPC stdio subset. A separate HTTP readiness service is implemented, but it is not a customer trading gateway or full remote MCP transport. There is no deployed public KRYPTA agent URL or OAuth enrollment. Local tool arguments are plaintext in the host process; never paste private signing keys into a model prompt or this website.

Compatibility belongs in adapters.

KRYPTA Swap is separate from the order-book foundation. Its design takes inspiration from VeilSwap’s shielded-note → public execution → new-note flow, while separating venue-specific execution from the note layer.

Using the website preview

Select fictional USDC, ETH or WBTC amounts, a sample route fee and example tolerance. Preview the quote, review its amounts and simulate the swap. This updates fictional balances and a bounded list of local receipts.

• Quotes expire after 30 seconds. Refresh creates another fictional quote.
• Sample rates are fixed, not live quotes. Fees are examples; gas, price impact and slippage execution are not modeled.
• Example minimum output illustrates a tolerance calculation; it is not an executable guarantee.
• No wallet, token approval, deposit, shielded note, proof or transaction is created. Reload clears the demo.

What the v0.1.0 reference models

The separate Python model covers note ownership/membership checks, nullifiers, domain-bound intents, change/output notes, fees, deadlines, minimum net output, route accounting and atomic rollback. It checks actual model inventory changes rather than simply trusting an adapter’s reported output.

• V2: constant-product arithmetic model.
• V3: a bounded single-range model that rejects tick/range crossing.
• RFQ: unsigned artificial inventory, not a live quote provider.
• V4: production integration remains unavailable. The website’s v4-style fee choice is only an illustration.

Experimental contracts v0.2.0 and real-proof path

The separate contract source includes KryptaShieldedVault, the unchanged upstream Verifier2, a fixed V2PairAdapter, a typed V3RouterAdapter, and an actual Poseidon/AES-GCM note client. Local verification uses the original pinned proof artifacts and valueless fixture assets. The reviewed package passed 31 client/hash/accounting/EVM checks and five genuine Groth16 proof groups, including deposit, swap, output-note recovery, output-note withdrawal and change-note exit. Those local checks are not an audit, live-venue test or deployment. None of this is connected to the paper swap button.

• Immutable asset/adapter allowlists, asset-partitioned trees, global spent-note checks, one to three bounded hops, exact balance accounting, proof-bound route/deadline/fee data and direct proof-based exits.
• V2 and V3 adapters are tested against local fixtures. No live Robinhood token/router addresses, fork tests, v4 integration, production RFQ provider or arbitrary routing are claimed.
• Proof tooling and note encryption are development components. An audited wallet/exit UI, durable client-key storage, relayer and reorg-safe recovery service remain missing.

Routes, amounts, timing, output key/blinding and ciphertext metadata remain public. Reusing output keys can link swaps. Runtime code hashes do not audit behavior or prevent proxy changes. Immutable allowlists cannot recover a token that later freezes.

VeilSwap’s own deployment status must not be confused with KRYPTA’s. KRYPTA has no deployed swap vault or live venue adapter. All real financial actions remain unavailable on this website.

Inspect the actual chain.

The Network console reads the official Robinhood Chain public RPCs. Choose mainnet 4663 or testnet 46630 to fetch a block snapshot and gas price. The RPC chain ID is checked before dependent reads. Responses remain provider-reported data, not independently verified consensus.

• Public reads: official RPC requests omit credentials and referrer, time out and show provider failures. No sample values replace a failed request. Public endpoints are rate-limited and are not recommended as a production availability dependency.
• Snapshot freshness: block age and retrieval time are visible; old snapshots are labeled. Refresh is manual. Gas price is not an execution quote or a complete transaction fee.
• Contract inspection: submit a public 0x address to read its bytecode at a specific block. The RPC receives that address. Code presence does not verify source, safety, token identity, ownership or a KRYPTA deployment.
• Optional wallet view: Connect read-only asks the browser wallet to share an account. Account, network and native balance are read through that wallet’s provider. No signing, token approval, network switching or transaction method exists in this integration.
• Changed accounts: a network mismatch stops balance reads. Changing accounts, networks or disconnecting clears prior displayed details; mixed or superseded responses are rejected. Disconnect page does not revoke the wallet’s own permissions.

A hosted product.
No local server for customers.

KRYPTA’s intended customer experience is online: open the website, sign in, choose a managed or external agent, approve its scope and budget, and inspect activity in the browser. This is the product direction, not a claim that customer accounts or hosted trading are enabled today.

1. Website and account layer: hosted frontend, verified identity, account-specific views and server-side authorization.
2. Agent gateway: a deployed remote API or MCP transport with short-lived, scoped sessions, revocation, expiry and owner-approved enrollment. Local stdio commands are development tools, not customer connection instructions.
3. Service operations: durable records, recovery, monitoring, deployment controls and isolation between customers. A local demo process is not a production service.
4. Execution and settlement: only reviewed, deployed integrations may accept real assets. Privacy proofs, custody, risk systems, withdrawals, audits and legal review remain separate launch gates.

Implemented service foundation

The v0.4.0 exchange source includes an HTTP readiness API with GET/HEAD routes at /healthz, /readyz and /v1/capabilities, plus Gunicorn and container deployment instructions. Financial and session routes fail closed with HTTP 503. This is deployment groundwork, not an enabled exchange or an account system.

The current public website provides real read-only market/network observations and paper workflows. No customer account service, remote trading endpoint, managed-agent scheduler or live settlement connection has been deployed or connected to this site. A read-only wallet connection does not change those boundaries.

Different mechanisms. Different claims.

Encrypted order intake

The order-book reference signs and encrypts padded order envelopes. The local operator still has access to decrypted state and keys. This is not enclave confidentiality.

The experimental proof

The order-book proof demonstrates knowledge of a commitment opening. It does not prove solvency, correct matching, full execution or settlement.

Shielded swap design

A production note system may hide which valid input note funded a swap. That does not make the public venue’s route, amounts, timing or output commitment invisible.

Network and relayer metadata

Relayer requests, IP/network observations, gas funding, distinctive amounts and small privacy sets can reveal linkages. Note privacy alone does not provide network anonymity.

Local recovery

Encrypted SQLite recovery protects the order-book journal at rest and supports tested retries. It is not replicated availability, enclave rollback protection or an independent exit mechanism.

What the website stores

The order, agent and swap demonstrations use tab memory, with no localStorage, cookies or backend account persistence in the application code. Reload clears the examples. Documentation search also runs locally. This does not make claims about hosting-platform or third-party provider logging.

Engineering setup, not onboarding.

Customers will not need these commands. They are for engineers with the reference source checkouts, to run isolated development tests. They do not deploy contracts or provide the hosted customer service. The product’s intended flow is described in Hosted service.

Order-book reference · v0.4.0

Requires Python 3.12+ and cryptography==50.0.0. From that reference checkout, use a disposable environment. The activation command below is for a POSIX shell.

python -m venv .venv
. .venv/bin/activate
python -m pip install -e .
python scripts/verify_release.py

The verification script runs offline tests and artificial demos. The reviewed v0.4.0 release records 132 passing tests. That result is not a cryptographic or financial audit.

python -m private_clob.managed_demo
python -m private_clob.mcp

The MCP command waits for newline-delimited requests on stdin. Its empty-policy default can discover tools but cannot trade. Stop it with your terminal’s interrupt when finished. Provisioning signed test sessions is a separate trusted-host step.

Swap reference · v0.1.0

Requires Python 3.12+; its model uses the standard library. Run from the separate KRYPTA Swap checkout. Do not run these commands in the order-book folder.

python scripts/verify_release.py
python -m krypta_swap.demo

The reviewed v0.1.0 release records 26 passing tests. These Python fixtures use synthetic tokens, artificial inventory and a local vault identifier. No RPC, wallet or remote relayer is called. The separate contracts v0.2.0 package uses Node 22+ and its own compile/accounting/proof commands; it is not executed by the Python verification script.

Exchange contract development

The exchange source also includes a valueless test-collateral vault and inbox, cumulative withdrawals, timeout refunds and an immutable verifier interface. The shipped verifier rejects every settlement proof. Compilation and 17 passing local EVM tests demonstrate specific behavior, not production safety. These contracts are not deployed and must not receive real assets.

Production readiness must stay blocked

# Order-book reference:
python -m private_clob.readiness --require-production

# Separate swap reference:
python -m krypta_swap.readiness --require-production

Both commands intentionally return exit code 2 while production gates remain unmet. Passing unit tests does not authorize changing that gate or accepting real funds.

Production is a separate release.

These are requirements, not completed integrations or a launch schedule. Readiness must be established for each product independently.

• Proofs and privacy: complete audited circuits/verifiers, correct public-input binding and a threat model that covers metadata leakage.
• Confidential execution: for the order-book design, real enclave attestation, secure key release, upgrades and recovery.
• Asset safety: custody, deposits, withdrawals, token identities, exact accounting, recovery and independently usable exit paths.
• Venue adapters: verified deployed contracts, supported token behaviors, price boundaries, approvals and atomic failure handling.
• Risk systems: robust oracles, funding/liquidation/shortfall handling for derivatives, stress testing and account-wide controls.
• Operations: durable state, replay/rollback protection, availability, private client recovery, incident response and confidential agent transport.
• Independent review: security, cryptography, financial risk and qualified legal/product review before real funds.

A spot liquidity quote cannot fill a perpetual order or supply margin by itself. The quote adapter, order book and separate swap layer must not be treated as interchangeable liquidity.

Documentation is part of the release.

This page is a reviewed snapshot, dated above. It is not an automatic live audit of code, markets or third-party deployments.

1. 2026-11-06

   Read-only network integration & hosted direction

   Added real Robinhood Chain snapshots, public bytecode inspection and optional read-only browser-wallet balances. Documented the v0.4.0 exchange HTTP readiness API and test-collateral contract foundation, clarified hosted onboarding and separated engineering setup from the product experience. No live financial execution is enabled.

2. 2026-11-06

   Documentation revision 2026.11.06.1

   Added this searchable guide, capability status, privacy boundaries, local setup and release-maintenance checks.

3. 2026-11-06

   Separate Swap preview

   Published the paper swap page and documented the offline v0.1.0 accounting/adapters reference. Neither is a live private-swap service.

4. 2026-11-06

   Agents & managed paper accounts

   Published the Agents workspace. The separately reviewed order-book reference reached v0.3.0 with managed mandates and local recovery.

5. 2026-11-06

   Public website & markets

   Published the KRYPTA site with read-only market intelligence and a clearly separated fictional order interface.

How updates are maintained

1. Review changed behavior and the affected implementation’s actual release evidence.
2. Update instructions, status, privacy caveats and release notes together with the feature.
3. Record a new documentation revision and review date. The site’s release check flags changed website source until that review is recorded.
4. When the reference checkouts are available, compare their versions, readiness files and recorded test results against this snapshot.
5. Run documentation, unit and browser checks, then publish the reviewed site update.

The source-change check catches drift; it cannot judge whether prose is true. External repositories and third-party deployments still require an explicit review. No background auto-refresh or guaranteed update cadence is implied.