> For the complete documentation index, see [llms.txt](https://shinkalabs.gitbook.io/hub/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://shinkalabs.gitbook.io/hub/andromeda/concepts/policies.md).

# On-chain policies

A policy is a Solana program that **holds the signing authority of a dWallet** and only lets a signature through if a rule is satisfied. Because the program is the authority, the Andromeda API cannot bypass the rule. It can submit transactions, choose timing, and assemble payloads, but it cannot make the program approve something the rule forbids.

Andromeda ships eight audited policy templates, built with the Quasar framework, deployed on Solana devnet.

| Template                                                                        | What it enforces                                                                         |
| ------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
| [rules-policy](/hub/andromeda/guides/deploy-policy/rules-policy.md)             | Recovery rules: primary owner bypass, or an M-of-N quorum, plus daily limit and cooldown |
| [allowlist-destinations](/hub/andromeda/guides/deploy-policy/allowlist.md)      | Signing only for whitelisted destination programs                                        |
| [velocity-guard](/hub/andromeda/guides/deploy-policy/velocity-guard.md)         | At most N signatures per slot window                                                     |
| [time-lock](/hub/andromeda/guides/deploy-policy/time-lock.md)                   | Signing only inside allowed slot ranges                                                  |
| [oracle-conditional](/hub/andromeda/guides/deploy-policy/oracle-conditional.md) | A Pyth price circuit breaker                                                             |
| [passkey-step-up](/hub/andromeda/guides/deploy-policy/passkey-step-up.md)       | A passkey proof required above a threshold                                               |
| [fhe-gated](/hub/andromeda/guides/deploy-policy/fhe-gated.md)                   | A confidential FHE evaluation must approve first                                         |
| [session-keys](/hub/andromeda/guides/deploy-policy/session-keys.md)             | Scoped delegation with on-chain limits                                                   |

## How a policy is created and changed

The flow is the same for every template (see [Deploy a policy](/hub/andromeda/guides/deploy-policy.md)):

1. **Preview.** Resolve your configuration and learn the program-derived address (PDA) the policy will occupy, without creating anything.
2. **Deploy.** Get an unsigned transaction, sign it client-side, and submit it. The PDA is seeded with an init-authority hash so it cannot be front-run. After this the policy program holds the dWallet's authority. See [RulesPolicy](/hub/andromeda/on-chain-programs/rules-policy.md).
3. **Read.** `GET .../{dwalletAddress}` returns the current on-chain state: configuration, nonces, and any pending change.
4. **Change.** Configuration changes are challenge-based admin actions: a `.../challenge` step returns a 32-byte challenge and the expected nonce, the current owner signs it, and a `.../submit` step applies it. Some changes are staged as pending and finalised with a separate `apply-pending` step. Each admin action carries a replay nonce.
5. **Revoke.** Revoking is an admin action like the others: submit the `revoke` action through the challenge/submit flow, and the policy program returns the dWallet's authority to the owner.

The exact endpoint paths depend on the template; for the recovery policy (`rules-policy`) see [Configure recovery](/hub/andromeda/guides/configure-recovery.md). The [OpenAPI spec](https://api.andromedainfra.pro/openapi.json) is canonical.

## Properties shared by every template

* **The Solana clock is the only time source.** No client-supplied timestamps.
* **Strict input validation on-chain.** For example, the WebAuthn challenge field is pattern-matched, not loosely parsed.
* **Per-flow replay nonces.** Each kind of action has its own monotonic counter on-chain.
* **Precompile-validated signatures.** Whatever signature a policy checks (a primary owner's, a quorum member's, a passkey's) is verified by the Solana runtime, not by trusting the API. See [Zero attestor](/hub/andromeda/concepts/zero-attestor.md).

## When to use which

* Treasury that should only touch known programs: `allowlist-destinations`, often combined with `velocity-guard`.
* Trading bot with a temporary, bounded key: `session-keys`.
* Wallet that needs social recovery: `rules-policy`.
* High-value action that needs a second factor: `passkey-step-up`.
* Signature conditional on private logic (compliance, sealed bids): `fhe-gated`.
* Pause everything if a price moves: `oracle-conditional`.
* Action only valid in a window: `time-lock`.


---

# 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:

```
GET https://shinkalabs.gitbook.io/hub/andromeda/concepts/policies.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.