Skip to main content

Evidence Sharing

Because the Zap Protocol is a federated open standard, users can strengthen their identity by having it verified by multiple independent Identity Authorities at once.

How Cross-IA Verification Works​

All verification modes require the user to publish the challenge token publicly — in a Discord/Telegram message, a bio, tweet, gist, or DNS TXT record. The verification act is therefore independently re-checkable by anyone.

The evidence tag in Kind 35522 contains the public URL of that post (evidence_url), the challenge that appeared in it (challenge), and the pre_auth_code used to generate it. Any IA can:

  1. Read Kind 35522 from relays (via #d filter)
  2. Fetch evidence_url
  3. Confirm challenge is present in the content
  4. Cryptographically verify the challenge is session-bound: bech32-decode the npv1 token, strip the 2-byte TLV header to get the 32-byte session hash, then compute SHA256(hex.Decode(p_tag_pubkey) || []byte(evidence.pre_auth_code)) and assert it matches. This proves the challenge was issued for this specific user and session — not replayed from another.
  5. Issue its own Kind 35522 for the same d tag and p tag — without requiring the user to re-verify

This is the zero-trust cross-IA attestation model: the public post is the proof, and anyone with relay access can verify it.

Limitations​

  • If the user deletes the post, cross-IA re-verification fails. The user must re-verify with each IA from scratch.
  • Bot Challenge evidence (Discord/Telegram) requires the post to still be publicly accessible at the evidence_url. Channel restrictions or post deletion will break re-verification.
  • A receiving IA may require a fresh verification regardless of existing evidence — this is a policy decision, not a protocol requirement.
  • Privacy: The evidence tag is always cleartext. user_id and username are visible to anyone who reads the relay. There is no privacy mode for evidence.