What You Are Actually Agreeing To When Someone Makes You a Guardian

You are agreeing that, together with enough other guardians, you can hand control of someone's identity to a new key. That is the power, and it is the whole point, and it means the people who choose you are trusting you not to combine with the others.

What the system gets right, before anything else

The rules live on the chain, not on our server. The set of guardians and the number required are read from an on-chain recovery policy, which is the source of truth. Our backend cannot quietly lower the threshold or add a guardian, it collects approvals and submits them.

Each attempt is bound to a nonce. Approvals you give for one recovery attempt cannot be replayed into another one, and the check matches what the chain enforces rather than being a server-side convention.

And when the chain is unavailable, the endpoint fails loudly. It returns a 503 saying on-chain recovery is required, it does not fall back to a local approximation. That is the right behaviour and it is worth saying, because the wrong version of this is a system that "works" while skipping the part that made it trustworthy.

Now the trade, which our own code documents and defends

The invitation is a bearer capability. Our source says so directly:

The invitee accepts by presenting the invite_token (the capability, an unguessable UUID emailed only to them …). We deliberately do NOT require the accepter's email to match guardian_email, OAuth / seed-only users may not expose an email, and the token already proves authorization.

The reasoning is sound. Someone who signs in without ever exposing an email address cannot be matched against an invited address, and refusing them would break a legitimate case.

The consequence is real and belongs on this page: whoever holds that link becomes the guardian. Not the person it was addressed to, the holder. If the message is forwarded, sitting in a shared inbox, or read by anyone with access to that mailbox, that person can accept in your place, and the account owner will believe you are a guardian when you are not.

So guardianship inherits the security of the mailbox the invitation landed in. If you are being invited, and it matters, ask to be invited by identifier rather than by email, that path exists.

What you can and cannot do as a guardian

You can:

Approve a recovery, contributing one signature toward the threshold.
See requests waiting for you, and decline by doing nothing.
Be removed by the person who added you, at any time.

You cannot:

Act alone. Below the threshold your approval does nothing.
See their credentials, their shares, or their activity. Guardianship is recovery authority, not a window into the account.
Stop a recovery that reaches the threshold without you.

The threat model, stated plainly

Enough guardians acting together can take over the account. That is not a flaw; it is the mechanism. Social recovery replaces "lose the key, lose everything" with "enough of your chosen people can restore you", and the same door opens for collusion.

Three consequences worth thinking about before you agree:

You are a target. If somebody wants that account, compromising you is one of the paths.
Choose independence, not convenience. Guardians who share a household, a device, an employer or a mailbox are closer to one guardian than to several.
A completed recovery mints a new root key. What that resets on the holder's side is not nothing, relationships keyed to the old identifier do not automatically follow.

What is unproven here