> ## Documentation Index
> Fetch the complete documentation index at: https://corridor.udokaam.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# ADR 0006: FROST 2-of-3 shielded vaults

> A shielded vault's spend-authorizing key is a FROST(RedPallas) group key split between the customer's approver, its finance lead and Corridor, signing rerandomized per action.

## Context

A shielded vault holding a customer's supplier funds must not be movable by one person, including anyone at Corridor. Ironwood randomizes the spend validating key per action, so any threshold scheme must sign under the randomized key.

## Decision

**Each vault's `ak` is a FROST group key**, 2-of-3 between customer approver, customer finance and Corridor. `corridor-frost` signs only actions whose `rk == ak + [alpha]G`, runs both rounds rerandomized by `alpha`, verifies the signature under `rk`, and applies it to the PCZT. Batches wait in the saga until the threshold approves.

## Consequences

* The full spending key never exists.
* Threshold control costs no on-chain privacy: spends remain unlinkable.
* The demo uses a trusted dealer and runs both rounds in one process; production uses distributed key generation and per-device signers through `frostd`, with the same PCZT interface.

## Alternatives rejected

* **Single-key vaults with operational controls:** one compromised machine moves the funds.
* **Multisig at the transparent layer:** gives up shielding.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.