Security

Security Architecture

How we protect brand identities, entitlements, and transaction receipts at every layer.

Cryptographic Foundation

Ed25519 Signatures

All credentials — capsules, entitlements, and receipts — are signed with Ed25519 (RFC 8032). Signatures are detached and base64-encoded, allowing any agent to verify without calling our API.

  • 32-byte public keys, 64-byte signatures
  • Canonical JSON serialization before signing
  • Deterministic: same input always produces same signature
  • No certificate authority required

Domain Anchoring

Brand Capsules are anchored to DNS via TXT records. Agents can independently verify that a capsule's public key matches the domain's published key.

  • DNS TXT record at _registeredbrands.{domain}
  • Contains capsule ID and public key fingerprint
  • Verified during capsule registration
  • Re-checked periodically for revocation

Key Fingerprints

Every public key has a short fingerprint derived from its first 8 bytes (hex-encoded). Fingerprints appear in .well-known manifests and can be compared out-of-band.

  • 8-byte fingerprint from public key bytes
  • Published in rb-merchant.json
  • Used for key rotation announcements
  • Human-readable for manual verification

Threat Model

ThreatMitigation
Capsule impersonation
Ed25519 signatures + domain anchoring. Agents verify the capsule's public key matches the domain's DNS TXT record.
Entitlement forgery
Entitlement tokens are signed by the platform's Ed25519 key. Agents verify the signature against the published issuer_public_key.
Receipt tampering
Receipts carry detached Ed25519 signatures over canonical JSON. Any modification invalidates the signature.
Replay attacks
Verification responses include a unique nonce and timestamp. Entitlements have expiry dates and credit caps.
Key compromise
Key rotation via .well-known/rb-merchant.json. Old signatures remain valid but new issuances use the rotated key.
Trust score manipulation
Scores are computed server-side from verified data. Community flags require a verified capsule to submit.
Payment fraud
USDC payments are verified on-chain. Payment intents expire after 30 minutes.

Infrastructure Security

Data at Rest

All database records are encrypted at rest using AES-256. Private keys are stored in hardware security modules (HSMs) and never exposed in application memory.

Data in Transit

All API traffic is encrypted with TLS 1.3. HSTS headers enforce HTTPS. Certificate transparency logs are monitored.

Audit Logging

Every verification, issuance, and revocation is logged with timestamp, actor, target, and IP address. Logs are immutable and retained for 90 days.

Responsible Disclosure

We maintain a security.txt at /.well-known/security.txt with contact information for responsible disclosure. We respond to reports within 24 hours.

Found a Vulnerability?

We take security seriously. If you've found a vulnerability, please report it through our responsible disclosure process.