The trust chain

The trust chain is the cryptographic core of MotherShy: a way to prove identity and authorization offline, against a single pinned public root.

Model

There is one Mother (the root authority) that derives agent keys and signs two kinds of statements:

1. Birth certificates — binding an agent's public key to a derivation path (identity).
2. Capabilities — granting an agent a scoped, budgeted, expiring right to spend at a specific site (authorization).

The wall — running on the publisher's infrastructure — verifies both offline using only the Mother's public root. The Mother never needs to be online for a wall to gate traffic.

The signature scheme

Everything is pure RFC 8032 Ed25519. The same messages are signed by Go's crypto/ed25519, @noble/curves/ed25519 (Node/browser/edge), and PHP — byte-for-byte identical. This is what makes one envelope verifiable across all six wall form factors.

The three byte layouts

The trust chain signs three canonical messages. They must be reproduced exactly — field order included — or verification fails:

1. Certificate signing bytes

"birth:" + path + ":" + rawPub(32 bytes)

2. Request canonical

{"agent":<b64>,"site":<str>,"nonce":<int>,"ts":<int>,"amt_microusd":<int>,"window":<int>}

3. Capability canonical (v1)

{"v":1,"id":<str>,"holder":<b64>,"aud":<str>,"actions":["retrieval"],"cap_microusd":<int>,"issued_at":<int>,"expires_at":<int>,"policy_receipt":<str>,"verification_mode":<str>}

See The wire format for the full schema.

Why offline verification matters

• No phone-home — a wall serves traffic even if MotherShy is down.
• No secret at the edge — walls hold only a public root. A compromised wall can't forge credentials.
• Cross-language — the same envelope verifies in V8, Node, Deno, Go, and PHP.

Next

• Capabilities — the spend key in depth.
• Verification modes.