> 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/on-chain-programs/rules-policy.md).

# RulesPolicy

`rules-policy` is the program that holds a recoverable dWallet's authority and enforces its recovery rules. Address (devnet): `6TX7qG47Fsocuwmgsgo2q3NLCHrbomoQxQLifapU8Thr`. You drive it through the Andromeda API ([Configure recovery](/hub/andromeda/guides/configure-recovery.md), [Run a recovery](/hub/andromeda/guides/run-recovery.md)); this page is the on-chain detail.

## The rule

A recovery is allowed if **either** the primary owner signs **or** an M-of-N quorum of recovery owners signs, **and** the action respects the configured **daily limit** and **cooldown**. Day boundaries and the cooldown are measured by the Solana clock, never by client input.

## The policy account (PDA) and front-running protection

The policy lives in a program-derived address. The seeds include a hash of the **init authority**, so the address a deployment will occupy cannot be predicted and grabbed by a third party before the legitimate deploy lands. The preview endpoint returns the PDA so a client knows the address ahead of time, but only the holder of the init authority can actually initialise it.

## Member slots

Owners (primary and quorum members) are identified by a canonical, fixed-width **34-byte member slot**: `[scheme byte || identifier bytes || zero padding to 34]`. The identifier length depends on the scheme:

| Scheme                 | Identifier                     | Slot layout          |
| ---------------------- | ------------------------------ | -------------------- |
| Ed25519                | 32-byte public key             | scheme + 32 + 1 pad  |
| Secp256k1              | 20-byte Ethereum-style address | scheme + 20 + 13 pad |
| Secp256r1              | 33-byte compressed P-256 key   | scheme + 33 + 0 pad  |
| WebAuthn (quorum only) | 33-byte compressed P-256 key   | scheme + 33 + 0 pad  |

Fixed width means a single slot value is enough for every on-chain comparison: membership checks, and deduplication via a bitmap so the same member cannot be counted twice in one quorum.

## Replay nonces

The account tracks separate monotonic counters so each kind of action is single-use in order:

* `next_admin_nonce` for configuration changes (primary, roster, thresholds, limits),
* `next_primary_recover_nonce` for primary recoveries,
* `next_session_nonce` for quorum sessions.

A challenge encodes the relevant nonce; the program rejects a stale one. Clients always read the current nonce from the `challenge` response.

## Challenges

Every action that needs a user signature uses a 32-byte, domain-separated challenge that binds the operation tag, the dWallet, the nonce and the member-or-primary slot together, so a signature for one action cannot be replayed for another. See [Domain-separated challenges](/hub/andromeda/on-chain-programs/challenges.md).

## Signature validation

Whatever signature the program acts on (a primary owner's, a quorum member's, the owner's on an admin change) is verified by a Solana runtime precompile in the same transaction. The program proceeds only if the precompile instruction succeeded. Andromeda assembles the transaction and pays the gas but cannot forge the signature. See [Precompile validation](/hub/andromeda/on-chain-programs/precompiles.md) and [Zero attestor](/hub/andromeda/concepts/zero-attestor.md).

## Configuration changes

Roster and threshold changes are typically staged as **pending** and applied in a second step, so a mistake is visible and reversible before it takes effect. The change preview shows the new state; `apply-pending` finalises it. Admin actions are challenge-based and replay-nonced.

## Cross-program call into Ika

When a recovery finalises (a primary submit, or a quorum finalize after threshold), the program makes a cross-program call into the Ika program to perform the actual authority operation. For quorums this happens at finalize time, after the staged contributions have been verified. See [Quorum via PDA staging](/hub/andromeda/on-chain-programs/quorum-staging.md).


---

# 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/on-chain-programs/rules-policy.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.