> 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/quorum-staging.md).

# Quorum via PDA staging

A Solana transaction has a size limit, so it cannot carry an arbitrary number of signatures. To support M-of-N quorums of any size without an off-chain attestor, the `rules-policy` program stages member contributions in a program-derived account (a session PDA) and finalises only when the threshold is reached.

## The lifecycle

```
open      create the session PDA, snapshot the current roster into it
contribute  each member adds their signature in their own transaction
            (precompile-verified, recorded against their member slot)
finalize  once M contributions are recorded, do the cross-program call into Ika
close     reclaim the PDA rent
```

### Open

The session opener signs an open challenge; the program creates the session PDA and writes a **snapshot of the current roster** into it (the member slots and the threshold M). The snapshot is the key detail: from this point, a concurrent change to the policy's roster does not affect this session. The session resolves against the roster as it was when it opened, so there is no race between "members are contributing" and "someone is editing the roster".

### Contribute

For each member: the program issues a contribution challenge bound to that member's slot and the session, the member signs it, and the contribution transaction includes a precompile instruction verifying the signature. The program checks the signer is in the snapshot, that they have not already contributed (a dedup bitmap keyed on the 34-byte member slot), records the contribution, and increments the count. Because each contribution is its own transaction, the number of members is bounded only by how many transactions you are willing to send, not by transaction size.

### Finalize

When the recorded count reaches M, anyone can call finalize. The program re-checks that M valid contributions are present in the PDA and then makes the cross-program call into the Ika program to perform the authority operation. Heavier call, longer timeout.

### Close

After finalize (or to abandon a stalled session), close reclaims the rent that the PDA was holding.

## Why staging instead of an attestor

The constraint here is transaction size, not cryptography. The honest fix is to spread the work across transactions and accumulate state on-chain, not to have an off-chain service attest "trust me, M members signed". Staging keeps every signature precompile-verified on-chain, so a compromised Andromeda backend still cannot fabricate a quorum. See [Zero attestor](/hub/andromeda/concepts/zero-attestor.md).

## Replay and single-use

Each session has its own nonce drawn from `next_session_nonce`, so a session cannot be replayed. Within a session, the dedup bitmap on member slots prevents a member from being counted more than once. Contribution and open challenges are domain-separated and bound to the session; see [Domain-separated challenges](/hub/andromeda/on-chain-programs/challenges.md).

## Driving it from the API

Open, contribute, finalize, close, and read are all endpoints; see [Run a recovery](/hub/andromeda/guides/run-recovery.md). Each contribution is challenge-based: get the member's challenge, have them sign, submit.


---

# 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/quorum-staging.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.