> For the complete documentation index, see [llms.txt](https://docs.useshadowpay.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.useshadowpay.com/protocol-and-architecture/trust-and-security.md).

# Trust & Security Model

ShadowPay is designed so that custody, transaction validity, and confidentiality don't depend on trusting ShadowPay as a company. Security is layered, and each layer addresses a distinct threat.

***

## Security layers

| Layer              | Threat addressed                                           | Mechanism                                                                                                                                                           |
| ------------------ | ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Custody            | ShadowPay is compromised or coerced into moving user funds | Non-custodial keys, generated and held on-device. ShadowPay never holds private keys.                                                                               |
| Confidentiality    | ShadowPay or a third party reads transaction amounts       | ZK proof generation and decryption happen client-side. ShadowPay's backend only ever sees ciphertext.                                                               |
| Transfer validity  | A malformed or overdrawing transfer is submitted           | Solana's runtime verifies the zero-knowledge range and validity proofs before updating encrypted balances.                                                          |
| Agent overspend    | An agent transacts beyond its authorized limit             | Spend policy checks run before a transaction is signed. A policy-violating transaction is never constructed.                                                        |
| Key loss           | User loses their device and passkey                        | Multi-device passkey sync, exportable keys, and social recovery (post-beta). See [Key Management & Custody](/privacy-and-confidential-transfers/key-management.md). |
| Replay and forgery | Reuse or forgery of a signed transaction                   | Standard Solana transaction signing and recent-blockhash expiry apply, same guarantees as any Solana transaction.                                                   |
| Availability       | ShadowPay's backend becomes unavailable                    | Funds live in standard Solana accounts, not ShadowPay-controlled PDAs. Any Solana wallet can interact with them directly using an exported key.                     |

***

## What ShadowPay can and cannot do

**ShadowPay can:**

* Route requests, render the app, and index on-chain events for a real-time feed
* Generate and send webhook notifications
* Evaluate and enforce spend policies at the point an agent's client attempts to sign a transaction
* Facilitate KYC and selective disclosure workflows you initiate

**ShadowPay cannot:**

* Move your funds without your signature. It never holds your private key.
* Read your transaction amounts. It never holds your decryption key.
* Alter a transaction after it's signed. Solana's runtime rejects anything that doesn't match a valid signature and proof.
* Bypass an agent's spend policy. Policy checks happen client-side before signing, not as a discretionary backend review.

***

## Client-side proof generation

All zero-knowledge proof generation for confidential transfers happens on your device, using WASM, not on ShadowPay's servers. This is a structural choice, not a policy promise: your unencrypted balance and transfer amounts never leave your device in a form ShadowPay's infrastructure could intercept even if it wanted to.

***

## Dedicated RPC

ShadowPay uses dedicated RPC infrastructure (Helius or Triton) rather than public Solana RPC endpoints, for reliability under load. This affects performance, not the trust model. Any transaction submitted through ShadowPay's RPC can equally be submitted through any other RPC provider, since it's a standard signed Solana transaction.

***

## Idempotent submission

Solana transactions expire after roughly 150 blocks (about 60 seconds). ShadowPay uses durable nonce accounts and idempotent submission logic to prevent double-sends if a transaction needs to be retried due to network conditions.

***

## Risks and mitigations

| Risk                                               | Mitigation                                                                                                                                              |
| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Device loss with no synced passkey                 | Export your key proactively and store it securely; social recovery planned post-beta                                                                    |
| Low-power device can't generate a ZK proof quickly | Server-assisted proof generation fallback, using only client-derived inputs, never plaintext amounts                                                    |
| Agent's parent account is compromised              | Spend policy limits bound the damage even if the parent account's session is hijacked; revoke the agent's key immediately from the dashboard            |
| Regulatory action targeting ShadowPay as a company | On-chain funds are standard Solana accounts, not ShadowPay-custodied. Users retain direct on-chain access regardless of ShadowPay's operational status. |
| Solana network outage                              | Redundant RPC providers and a status page; no funds are at risk during an outage, only availability of the app                                          |


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.useshadowpay.com/protocol-and-architecture/trust-and-security.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
