An identity that needs no institutional countersignature

Money never needed a bank's permission. Identity shouldn't need a government's.

A verifier who actually cares about "is this the same entity I dealt with before, and do people I trust vouch for it" never needed an institution in the middle — that's a real, working subset of the identity problem, not the whole thing. It sidesteps the much harder problem of self-issued state-recognized credentials (professional licensing, legal capacity, regulated- goods age verification) rather than pretending to solve it.

Nostr already demonstrates persistent, portable, keypair-based identity with no platform lock-in, at real production scale. NIP-98 (HTTP auth via signed events) and NIP-58 (badges) are already-standardized patterns for sign-in and attestation. NIP-57 ("zaps") already proves identity plus Lightning payment works in production. persona doesn't invent new wire formats where an existing one already does the job — it fills in the two pieces Nostr deliberately leaves unsolved.

Standard Nostr primitives, one new event kind

A persona is a standard secp256k1 Nostr keypair — no new key format, no new signature scheme. Reputation is built from a new attestation event kind (kind:3300): a signed claim, from one key about another (or about itself), typed by a reverse-domain-namespaced claim_type (net.persona.core.skill, net.persona.core.arbiter_commitment, and so on) — the same permission-free minting pattern NIP extensions already use for event kinds, applied one level down to claim types instead of forcing a centralized registry to bless new claim shapes.

That attestation format — the event shape, the open claim-type registry — is a general-purpose protocol layer, not something inherently identity-specific; persona is the identity/recovery/ trust product built on top of it, not the protocol itself.

Every attestation is content-addressed and independently re-verifiable: a third party fetches the raw event, checks its signature from scratch, and re-derives everything else (claim hash, embedded payment receipt, trust weight) without trusting any intermediary — including persona's own reference code.

Relative to the viewer, never a global score

There is no canonical persona reputation number. A verifier weighs a claim against their own web-of-trust graph — a bounded-depth, decay-by-half walk from their own trusted set, PGP-style — not a universal score anyone could capture by controlling it. This is a deliberate, non-negotiable design constraint, not an implementation detail: any single canonical trust number is a single point someone can buy, coerce, or subvert, which defeats the entire point of not needing an institutional countersignature in the first place.

Economic cost, never proof-of-personhood

An attestation only counts toward a subject's weighted trust if it was published with either a small Lightning-metered payment attached (L402), or backed by a bonded stake that's slashable if the claim is later disputed and found false — the same bonded- reporting pattern real systems like Kleros and Augur's dispute bonds already use.

The dispute-adjudication mechanics themselves — who arbitrates, how a slashed stake actually gets seized on-chain, what stops the adjudication step from being gamed — are genuinely hard, only partially resolved (see Bonding & slashing below), and stated as such rather than glossed over.

Social recovery, reusing the attestation primitive — not a second system

A persona designates recovery guardians via a recovery_guardian attestation claim; a threshold of matching recovery_confirm claims from those guardians authorizes recovery. It's the same claim/attestation machinery built for reputation, reused rather than duplicated — no separate guardian-recovery subsystem to maintain or reason about independently. The underlying key-splitting is standard Shamir secret sharing (SSKR-style, GF(256)), with shares delivered guardian-to-owner over NIP-44 encrypted events.

Bitcoin-native escrow for disputed attestations

Bonds and challenge stakes are held in plain Bitcoin script — no custodian, no sidechain, no smart-contract-chain trust assumptions. A dedicated design pass considered and rejected moving this to an EVM chain (Hyperliquid's HyperEVM specifically evaluated with real numbers: 24 validators, BFT to ~1/3 malicious, and every BTC-bridging path onto an EVM chain requires trusting some off-chain signer set — bridge exploits total over $2.8B since 2022). The deeper reason to stay Bitcoin-native: no chain's consensus can adjudicate a dispute's actual substance anyway — that's a human judgment call, not on-chain-computable data — so borrowing a smart-contract chain buys nothing but a new trust assumption.

The scripts

Two static, upfront-configured P2WSH scripts, each a single script with no escalation transaction:

• UniversalScript — mutual settlement any time (no timelock), the arbiter siding with the attester, the arbiter siding with the subject, or — as a last resort — a CSV (BIP68) timelocked self-release if nobody ever engages.
• ReinforcedScript — adds a fifth branch: both of two independently, previously pre-committed arbiters agreeing settles the dispute with no live disputant input needed at all, available only when the subject has published a standing arbiter_commitment attestation ahead of time.

Settlement is plain PSBT: an unsigned packet each cooperating party signs independently, with hand-written finalizers (the standard library's own multisig finalizer can't recognize OP_IF-branching or single-key-CSV scripts as plain multisig) that independently re-validate every precondition — including CSV sequence — rather than trusting that a present signature implies a satisfiable branch.

Known, accepted residual

If two independently pre-committed arbiters genuinely disagree under ReinforcedScript, there's no live tie-break baked into the static script — whichever competing spend confirms first wins. Accepted as a rare case (both arbiters must actually disagree) rather than solved with more machinery, and documented as such rather than hidden.

Real-node proof, not just simulation

Every branch — funding, signing, broadcast, mempool acceptance, and confirmation — has been exercised against a real Bitcoin node's actual consensus engine (btcd, regtest), not just validated in-process. All seven non-fallback branches across both scripts pass live. The one deliberately uncovered case: the CSV fallback branch's live-node timing (BIP68 needs real elapsed median-time-past; regtest has no fast-forward primitive for it) — the underlying sequence-comparison logic is already proven identical at the consensus-engine level, so this is a stated scope boundary, not a silent gap.

L402-metered attestations, backend-agnostic

An attester who wants a paid attestation weighted more heavily requests a receipt from a gateway; the gateway responds with a real L402 402 challenge (macaroon + Lightning invoice); once paid, the gateway signs a Receipt that gets embedded in the finalized attestation event — independently re-verifiable by any third party against the gateway's own public key, without trusting the gateway's word for it after the fact.

Proven end-to-end against persona's own real code with a simulated L402 gate (no infrastructure cost); a real Aperture + Lightning-regtest integration is deliberately staged separately, given the genuinely larger setup it requires (two funded channel-connected nodes, a real Aperture deployment).

The Bitcoin escrow scripts need eyes that aren't ours

Everything above has been tested extensively — consensus-engine- level script execution tests, full PSBT build→sign→finalize→ extract→re-validate round trips, and live regtest broadcast/ confirmation for every non-fallback branch of both scripts. That is necessary and it is not sufficient. Self-testing, however rigorous, shares blind spots with the person who wrote the code — independent review is a different category of assurance, not just a bug hunt, and it's the one thing this project cannot give itself.

If you write or review Bitcoin script for a living and have half an hour to look at two scripts and a hand-written PSBT finalizer, this is a concrete, scoped ask — not "audit the whole repo."

Shared philosophy, no runtime dependency

What's built, what's still open

In short: the identity, trust, recovery, payment, Lightning integration, and browser-extension signer layers are all done and tested. The Bitcoin escrow layer is implemented and proven against a real node, but — by design — not treated as mainnet-ready until it clears independent review.