Signatures and EIP-712
Attested flows (attestedDecrypt, attestedCompute) require the user to prove control over their address.The JS SDK does this by asking the user to sign an EIP-712 message that binds:
- the caller’s address,
- the requested operation (decrypt, compute),
- and the handles / parameters involved in the request.
e.allow or e.reveal) can request an attestation for it, and prevents a malicious party from replaying or forging decryption/computation requests.
Attested Decrypt
Use an off-chain covalidator to decrypt a handle for an authorized user and receive a signed attestation of the plaintext. Refer to Attested Decrypt for full examples. High-level flow:- A contract exposes an encrypted handle (e.g. created with
e.rand()), and grants access withe.allow. - The authorized user calls
zap.attestedDecrypt(...)from the JS SDK, which talks to the covalidator. - The response contains the plaintext plus the covalidator signature, enabling the user to post the plaintext back on-chain if needed.
Attested Reveal
If the contract already callede.reveal(handle), anyone may request an attested decryption because the handle is considered public. See Attested Reveal. The SDK call zap.attestedReveal([...handles]) returns plaintexts plus signatures that can be re-submitted on-chain. Warning: once e.reveal runs, the ciphertext is public forever.
Attested Compute
Sometimes the goal is to evaluate a predicate (e.g.creditScore >= 700) instead of exposing the raw value. Attested Compute executes the computation off-chain, still requiring the handle to be shared via e.allow or e.reveal. The SDK call zap.attestedCompute(...) returns the result (such as an ebool) alongside a covalidator signature so the decision can be verified on-chain without re-running the computation.