TRUST & SECURITY
Read-only by construction.
NOSHASHI reads the XRP Ledger and applies your rules. It holds no keys, takes no custody, signs nothing and broadcasts nothing — and the claims on this page are checked against the code by test.
NO PRIVATE KEYS
NOSHASHI never asks for, generates or stores an XRPL secret, seed or private key.
No XRPL wallet or key-pair library is imported. The app will not send a message containing an XRPL secret seed to any AI model: it checks every message before sending and refuses. The keys NOSHASHI does hold are of other kinds: model-provider API keys and the Compliance API secret sit in the operating system keyring, and nsh_live_ API keys are stored only as SHA-256 hashes.
NO CUSTODY
NOSHASHI holds no client assets and controls no account on the ledger.
Addresses are entered to be read. There is no deposit address, balance under management or withdrawal path.
NO SIGNING
No code path signs an XRPL transaction.
The signing commands (sign, sign_for, submit_multisigned, wallet_propose, channel_authorize) appear nowhere in the covered code, which a test checks. NOSHASHI does sign messages of its own kind — webhook deliveries carry an HMAC — which is unrelated to ledger transactions.
NO BROADCAST
Nothing is ever submitted to the ledger.
The submit command appears nowhere in the covered code, which a test checks. Every command that is sent is on the published read-only list.
01 / Data path
From the ledger to the receipt.
Every verdict follows this path. Open a stage to see what happens there and where it is implemented.
01 XRPL MAINNETPublic XRP Ledger servers, read over WebSocket and HTTPS.
The app connects directly to public servers: xrplcluster.com, s1.ripple.com and s2.ripple.com, in failover order (the Network view also compares xrpl.ws). The Compliance API reads s1 and s2 over HTTPS. No NOSHASHI server sits between the app and the ledger. Only read commands are sent; the full list is below and is checked by test.
Source: src/lib/xrpl/link.ts · src/lib/xrpl/client.ts
02 VALIDATED STATELedger state is read from the last validated ledger, never an open one.
Every state read asks for ledger_index "validated" or reads a validated range. A transaction counts as final only when the server says validated: true; until then it is shown as not final.
03 NORMALIZATIONRaw ledger fields become comparable facts.
Drops become XRP exactly; hex fields are decoded; Ripple-epoch times become UTC; delivered_amount is used instead of Amount; a field the ledger did not return stays empty rather than becoming zero.
Source: src/lib/xrpl/client.ts · supabase/functions/noshashi-verify/read.ts
04 ANALYSISDeterministic engines: issuer controls, concentration, liquidity, credentials, provenance.
Each engine is ordinary code over the normalized facts. The same input produces the same output. No language model runs in this path.
Source: src/lib/desk/
05 POLICY ENGINERules applied to the facts: the domain registry and, when set, an institutional policy.
Institutional policies are versioned and hashed. In an organization, the person who submits a policy cannot also activate it; activation is checked on the server.
Source: src/lib/policy.ts · src/lib/desk/institutional.ts · supabase/functions/noshashi-policy-activate/
06 DECISIONGO, HOLD, NO-GO or INSUFFICIENT DATA, from the rule results alone.
The verdict is a fixed function of which rules passed. The AI assistant can explain a verdict but has no path to change one.
Source: src/lib/policy.ts
07 EVIDENCEWhat was read, which rules applied, what each found.
Each verdict keeps its check list, so it can be walked backwards from the verdict to the facts. Investigations are hash-chained: each event includes the hash of the one before it.
Source: src/lib/desk/evidence.ts · src/lib/desk/investigations.ts
08 CRYPTOGRAPHIC RECEIPTA SHA-256 digest over a fixed, canonical form of the decision.
Anyone holding the receipt body can recompute the digest and see whether it was altered. A digest is not a digital signature: it proves the body is unchanged, not who produced it.
Source: src/lib/policy.ts · src/lib/desk/evidence.ts
02 / Ledger commands
The only commands NOSHASHI sends.
account_info · account_lines · account_objects · account_tx · amm_info · book_offers · fee · gateway_balances · ledger · ledger_entry · nft_buy_offers · nft_sell_offers · server_info · subscribe · tx
Never sent: submit, submit_multisigned, sign, sign_for, wallet_propose, channel_authorize, validation_create, wallet_seed. A test fails the build if any of them appears in the covered code.
03 / Data
Where your data goes.
| Who | What | Why |
|---|---|---|
| Public XRPL servers | The addresses, transactions and order books you ask about. | To read the ledger. These servers are run by third parties and see your queries. |
| Your device | The workstation's verdict ledger, settings and cases outside an organization. | Kept locally on purpose; not transmitted. |
| Supabase (NOSHASHI's hosted database) | Account, subscription, organization data, shared cases, audit log, API receipts, hashed API keys. | Accounts, billing entitlements and anything shared across an organization. |
| Stripe | Payment details, entered on Stripe's own page. | Billing. NOSHASHI never sees card numbers. |
| Have I Been Pwned | The first five characters of a SHA-1 hash of a new password, sent from NOSHASHI's server. | To refuse passwords known from breaches. The password itself never leaves NOSHASHI. |
| An AI provider you choose | Your questions and the context attached to them. | Only if you configure a hosted provider. The default is a model on your own machine, and the app shows which applies. |
04 / Human oversight
- A policy submitted by one member must be activated by another; the server refuses self-activation.
- Policy exceptions are requested by one member and decided by another, and every decision is written to an append-only audit log.
- Investigations are opened, prioritised and closed by people. The AI assistant can be asked about a case but cannot create, change or close one.
- Every call to an AI model is recorded with digests and sizes, so what was sent and when can be shown without keeping a second copy of the text.
05 / What this page does not claim
- NOSHASHI trusts the public servers it reads from. It does not verify ledger proofs or validator signatures itself, and individual reads are not cross-checked between servers (the Network view compares servers separately).
- A receipt digest shows the receipt was not altered. It is not a signature and does not by itself prove NOSHASHI issued it.
- If you configure a hosted AI provider, your prompts are processed by that provider under its terms.
- NOSHASHI holds no security certification (such as SOC 2 or ISO 27001) and makes no claim of regulatory compliance. It is software that reads the ledger and applies rules; the decisions stay yours.
Scope
These statements cover the NOSHASHI desktop app (src/, src-tauri/), the public website (site/, api/) and NOSHASHI's Supabase functions (supabase/functions/). Nothing else is covered.
Security questions or a disclosure: contact us. Institutional review: Enterprise.