# Security policy

sigelo is maintained by one pseudonymous person, `csigelo`. Nobody here will ask for your real name, and
you need not give one. Reports are read by that maintainer only.

> **Draft.** Decided at D1 (2026-10-01): the pseudonym and GitHub account `csigelo`
> (`https://github.com/csigelo/sigelo`), the domain sigelo.io, `security@sigelo.io` for
> reports and `contact@sigelo.io` for anything that is not a vulnerability — both mailboxes
> exist and are read — and a SimpleX contact address for both. Still `<angle brackets>`: the
> age recipient and the SimpleX address itself. Until the repository is public, e-mail is the
> working channel. All contacts: `https://sigelo.io/contact.html`.

## Reporting

In order of preference:

1. **GitHub private vulnerability reporting** on this repository ("Security" → "Report a
   vulnerability"). No account linkage beyond your GitHub handle.
2. **Email** `security@sigelo.io` (the mailbox exists and is read), encrypted to this age recipient
   once it is published:
   `age1<to-be-filled-at-D1>` — also published at `https://sigelo.io/.well-known/security.txt`
   (RFC 9116). Unencrypted mail is read, but assume it was not private.
3. **SimpleX**: `https://smp10.simplex.im/a#18LjfJawmkVxvFtCHFo-yyzPo8Kr3gPLNts_ovwxmZM`. The address lives on public SimpleX relays, not on a
   server this project runs, and the same address also serves general contact
   (`https://sigelo.io/contact.html`).

Say what you ran, against which commit, what happened and what you expected. A failing
vector, bundle or request is worth more than prose. State what you did not verify.

## Scope

- `SPEC.md` and `test-vectors.json`: any bundle two conformant verifiers disagree on, any
  vector that is wrong, any rule that lets a stolen key or a malformed object win.
- `ts/` (the library, the vector generator, `sigelo-offline` and the ceremony) and `go/`
  (the reference verifier, `sigelo-verify`, `keys.go`).
- `spend/`, the keeper: account pinning, caps, the delegation tree, approvals, the two-phase
  relay, tokens, `spend.log` integrity, `sigelo-wallet` output an attacker can shape.
- `adapters/1f916` and `adapters/moadim`.
- Release artefacts once they exist: binaries, `SHA256SUMS`, the signed release object.

## Out of scope

- Monero itself, `monero-wallet-rpc`, `monerod`, and stock wallets. Report those upstream
  (Monero's own disclosure process). If sigelo *uses* them unsafely, that is in scope.
- Stagenet or testnet coins: they have no value; a bug that moves them is still in scope.
- Things THREAT-MODEL.md §3 already says sigelo does not defend: Sybil, lying issuers,
  collusion rings, the operator behind an agent, signer-asserted timestamps.
- Social engineering of the maintainer, and denial of service against infrastructure that
  sigelo does not need (the site, the MCP endpoint: verification is offline by design).

## What to expect

- Acknowledgement within **72 hours**.
- A fix, or a public advisory saying why there is none, within **90 days**. Sooner if it is
  exploited or trivially exploitable.
- Credit in the advisory and CHANGELOG under the name you choose, or none.
- No bounty until there is funding for one. That will be announced here, not promised.

## Safe harbour

Good-faith research on your own keys, identities, keepers and wallets, on stagenet or
testnet, is welcome and will not be pursued in any way. Do not touch other people's keepers,
tokens, wallets or identities, do not spend coins that are not yours, and do not publish
before the 90 days are up or a fix ships, whichever comes first, unless we agree otherwise.
If you are unsure whether something is in bounds, ask first through any channel above.

## A live keeper compromise

If you run a keeper and believe its host, a token or `spend.key` is compromised, act first:
follow **INCIDENT.md** (stop, sweep to the vault, recovery-rotate, report). Report to us
afterwards if you suspect a sigelo bug caused it, with the preserved `spend.log` (it holds no
secrets; it names destinations, amounts and purposes, so redact what you must). Never send
`spend.key`, a token, a seed or the 25 words to anyone, including us.

## Known unaudited areas

Nothing here has been reviewed by anyone outside the project; every review so far was done
by Claude models. External review targets, in priority order (ROADMAP §5.4):

1. `go/jcs.go`, `ts/src/jcs.ts` — canonicalisation and the strict parser.
2. `go/sigelo.go`, `ts/src/sigelo.ts` §9 — chain walk, precedence, forks, cycles, discard.
3. `go/monero.go`, `ts/src/monero.ts` — Keccak, base58, point decoding, SigV2, subaddresses.
4. `ts/src/keys.ts`, `go/keys.go` — HKDF paths, `sc_reduce32`, the 25-word mnemonic.
5. `ts/src/ceremony.ts`, `ts/src/offline.ts` — secret handling, age invocation.
6. `spend/service.ts`, `approval.ts`, `tree.ts`, `policy.ts` — the keeper.

The keeper is **experimental and stagenet-only** until this list is reviewed.