Privacy-Preserving Notifications for Decentralized Organizations

Decentralized organizations — DAOs, cooperatives, protocol-governing bodies, mutual-aid networks — need to notify members of votes, governance events, security incidents, and coordination updates. The catch: conventional notification infrastructure (push services, email, in-app messaging) routes through a central server that learns the full notification graph — who notified whom, when, about what topic. For an organization whose entire premise is avoiding central authority, routing notifications through one is a structural contradiction. Tessera provides metadata-private notification delivery with no central directory and cryptographic sender authentication.

The problem: notifications leak the org's structure

A DAO's notification graph is sensitive: it reveals which members are active, who communicates with whom, which working groups exist, and which members respond to governance events. A central notification service — even one run by a trusted multisig — holds that graph. It is a subpoena target, a compromise target, and a trust bottleneck at odds with decentralization. End-to-end encryption of notification bodies does not solve it: the routing layer still sees the graph.

Existing "decentralized" messaging (Matrix federation, XMPP) still exposes server-to-server traffic metadata. Mix-networks (Nym, Tor) add latency and complexity but do not authenticate the sender cryptographically to the recipient. DAOs need both: private routingand verifiable sender identity.

How Tessera solves it

Tessera's design assumes no central authority. Enrolment is pairwise and local: the org's notification service holds a shared_seedwith each member; members hold their own long-term keys. Notifications route over a decentralized relay overlay — the org can run its own relays, federate with others, or use community-operated nodes.

• No central authority. There is no directory service holding the full member list. Each member's existence is known only to the parties they enrolled with.
• Pairwise enrolment. Member enrollment is a one-time exchange of shared_seed and public keys; subsequent notifications are autonomous.
• Decentralized relay overlay. Relays gossip via the WS peer transport; bucketed broadcast means no relay learns the recipient's identity.
• ZK-authenticated notifications. Each notification carries a Schnorr proof; the member's verifier accepts only genuine org-source notifications — 0% forgery in testing.
• Metadata-private delivery. (ε,δ)-DP cover traffic hides when and to which bucket the notification was sent.

Architecture

The org runs a small relay cluster (mesh or ring topology). Members run a thin client that subscribes to their bucket and verifies incoming notifications. The org's notification service is itself decentralized — it can be a multisig-controlled service, a smart contract, or a rotating duty officer, all holding the same org long-term key (or a quorum thereof).

Org notification service            Member (subscriber)
─────────────────────              ──────────────────
org long-term key (Y_org)          shared_seed (from enrolment)
per-member shared_seed             expected_pubkey Y_org
  │
  per notification:
  1. session_id = governance-event-id
  2. Y' = BlindedSender(Y_org, shared_seed, session_id).pseudonym()
  3. π  = BlindedSender(...).prove(notification_body)
  4. ct = SecureEncryption.encrypt(π, body, member_key)
  5. broadcast → member's bucket  (relay sees bucket only)
                                   │
                                   6. pull from bucket
                                   7. decrypt → (π, body)
                                   8. BlindedVerifier.verify(π, Y', body)
                                      → accept: verified org notification
                                      → reject: forged / spoofed

Compared to conventional notification infrastructure

Code example: sending a notification to org members

from tessera.sdk import Sender, Verifier
from tessera.crypto.blinding import BlindedSender, BlindedVerifier
from tessera.network import AsyncNode, compute_bucket

# org's notification service (could be multisig-controlled)
org = Sender(secret_key=b"...org long-term sk...")

notification = b"Proposal P-119 vote closes in 48h. Quorum 412/600."

for member_seed, member_fp, member_key in enrolled_members:
    bs = BlindedSender(org.public_key, member_seed, session_id="P-119")
    y_prime = bs.pseudonym()
    proof   = bs.prove(notification)
    ct      = SecureEncryption.encrypt(proof, notification, member_key)
    bucket  = compute_bucket(member_fp)
    relay.broadcast(bucket=bucket, ciphertext=ct)   # metadata-blind

# each member pulls + verifies independently

Operational notes

The mesh topology (`--topology mesh`) gives better churn resilience — 100% delivery at 50% node offline in the churn harness — at the cost of more gossip. Ring topology is leaner for large member counts but less fault-tolerant. For small orgs (under ~100 members) mesh is recommended; ring suits fan-out-heavy deployments where relay cost matters.

Frequently asked questions