Limits and errors
What the server enforces and what it returns when you cross it.
Limits and trust
The parts worth knowing before you put something real on this.
Per sealed blob.
Per IP, bursting to 400.
Padded with decoys. The count is not published at all until a round opens, and padded once it has.
Independent operators, none trusted: any three open a batch, two cannot. Meridian Assay, Halcyon Registry, Northwind Trust, Ardent Notary and Vantage Archive.
Security model
Payloads are encrypted in your process against the committee's public parameters, whose digest the client verifies before using them, so a coordinator serving inconsistent parameters fails loudly. The coordinator stores ciphertexts and never holds a key that opens one on its own. Opening a batch takes three of the five operators; two cannot.
Every reveal is checkable after the fact: payloads come back with their positions and a merkle root over the set, and positions are derived from the ciphertext hashes rather than arrival order, so a batch cannot be reordered or quietly edited. The protocol reference documents the committee, the ceremony and the full threat model, and the activity dashboard counts every reveal the network has performed.
The v0 keys come from a single offline dealer. The committee is Meridian Assay, Halcyon Registry, Northwind Trust, Ardent Notary and Vantage Archive, five independent operators, none of them trusted. Their key shares were dealt by one ceremony rather than a distributed key generation, so whoever ran the ceremony could have kept the trapdoor. The threshold, the pairing checks and the merkle root are real and verifiable today; the ceremony is the assumption that remains. Build and integrate against this. Do not put value behind it until DKG ships.
This is the v0 devnet. Parameters, addresses and endpoints are stable, and the committee parameters are documented in the protocol reference.