REDACT / Disclosure
Security and disclosure model

What leaves the client, what does not, and what could go wrong.

This page is the reference for anyone deciding whether to hold or accept a REDACT credential. It lists the disclosure boundary field by field, the threat model, and the audit record.

Boundary

Disclosure boundary

Defined by the circuit's public inputs. Anything not listed on the left cannot be derived from a credential.

Disclosed

  • Origin domainpublic input
  • Field path (hashed)public input
  • Predicate and thresholdpublic input
  • Session timestamppublic input
  • Notary key identifierpublic input
  • Holder addresspublic input
  • Nullifierderived

Not disclosed

  • Session cookies and authorization headersnever transmitted
  • Exact field valueprivate witness
  • Remaining response bodycommitted, unopened
  • Request body and query parameterscommitted, unopened
  • Account identifier or usernamenot in circuit
  • IP address of the clientseen by origin only
  • Linkage across credentialsdistinct nullifiers
Hover a row to read it. REDACT operates no storage and holds no session data at any point.

Threat: notary and client collusion

A notary that cooperates with a client can sign a commitment to a response the origin never sent. This is the primary trust assumption in the protocol.

Mitigations. Verifiers maintain an allowlist of notary keys and can require signatures from k of n independent notaries. REDACT-operated notaries run inside attested TEEs and publish remote attestations alongside each key. Notary operators are economically bonded on the registry contract and can be slashed on proof of misbehavior.

Threat: origin dishonesty

The proof attests to what the origin sent. It does not attest that the origin is correct. A platform that inflates a metric produces a valid proof of an inflated metric.

Mitigations. None at the protocol level. This is a property of oracles in general. Verifiers should treat a credential as exactly as trustworthy as the origin that produced the underlying data.

Threat: circuit soundness bugs

An under-constrained circuit could accept a proof for a false statement.

Mitigations. The circuit is small (roughly 1.1M constraints), fixed, and does one job. It has been audited twice and is covered by a bug bounty. Circuit upgrades require a new version identifier; verifiers can pin to a version.

Threat: client compromise

Malware with access to the browser can already read every session the user is logged into. REDACT does not change this exposure. It also does not introduce new credentials: the extension holds no long-lived secrets beyond the holder's wallet key, which is managed by the wallet, not by REDACT.

Threat: fingerprinting via predicates

A very specific predicate (for example, follower_count = 250412) is functionally equivalent to disclosing the value. Combined with public data it can identify the account.

Mitigations. The client warns when a threshold is unusually precise and rounds thresholds to a coarse grid by default. Equality predicates over identifying strings are only permitted against hashed values. Multi-field disclosure is unsupported.

Threat: replay and reuse

A credential could be minted repeatedly from one session, or a stale proof presented as current.

Mitigations. Each commitment yields a single nullifier; the registry rejects duplicates. Every proof carries the session timestamp as a public input and verifiers enforce their own maxAge.

Audits and disclosure

Circuit audittls-predicate-v2, completed, report published on request
Registry contractaudited, no critical findings, one medium finding resolved
MPC-TLS implementationupstream audited, REDACT fork reviewed
Bug bountyopen, scope: circuit, contract, extension
Responsible disclosuresecurity at the project domain, PGP key in repository

Audit reports and the disclosure policy are available on request during the testnet period.

Read the protocol Verifier documentation