authentication and signature

This document defines how creators authenticate manifests in the Aevia protocol and how verifiers validate them. Authentication uses EIP-712 typed-data signing over the canonical hash of the manifest (RFC-1). The signing key is an Ethereum secp256k1 private key operated directly by the creator or via a Privy embedded wallet.

MUST, SHOULD, MAY follow RFC 2119.

• curve: secp256k1 (same as Ethereum).
• public key format: EIP-55 Ethereum address (20 bytes, checksum casing).
• signature format: compact 0x{r}{s}{v}, 65 total bytes (32+32+1), with v ∈ {27, 28}.
• creators MAY hold the private key directly (software wallet, hardware wallet) or delegate via Privy (§7).

The Aevia EIP-712 domain is fixed:

chainId MUST be the chain ID of the target network (Base Sepolia = 84532, Base Mainnet = 8453). verifyingContract MUST be the Content Registry address deployed on that chain.

The domain separator MUST be included in the EIP-712 digest. Manifests signed with the wrong domain MUST be rejected.

The primary signed type is Manifest:

• manifestHash = SHA-256 of the canonical encoding of the manifest with cid and signature fields removed (RFC-1 §5).
• creator = signer address (MUST match manifest.creator).
• createdAt = Unix timestamp in seconds (MUST match parse of manifest.created_at).

To produce the signature, the creator:

1. computes manifestHash per RFC-1 §5;
2. builds the Manifest struct (§4);
3. computes domainSeparator = hashStruct(EIP712Domain);
4. computes digest = keccak256(0x1901 || domainSeparator || hashStruct(Manifest));
5. signs with secp256k1: signature = sign(privateKey, digest).

The resulting signature MUST be placed in manifest.signature in hex-encoded form with the 0x prefix.

Verification is deterministic and offline. Given a manifest M, a verifier MUST:

1. extract M.signature;
2. compute manifestHash (RFC-1 §5);
3. reconstruct the EIP-712 digest (§5.4);
4. recover the signer: recovered = ecrecover(digest, M.signature);
5. verify that recovered == M.creator;
6. (when relevant) verify that createdAt typed-data matches the parse of M.created_at.

Any mismatch MUST result in rejection. No network round-trip is required.

Privy embedded wallet operates as a delegated custody layer: the user authenticates via email/social login, Privy generates and custodies secp256k1 keys under MPC, and exposes a signing API. From the Aevia protocol perspective, a Privy key is indistinguishable from a local software key — the resulting address is registered in the Content Registry normally and the EIP-712 signature is valid under §6.

Clients using Privy MUST request typed-data signing via signTypedData, not personal_sign. Clients SHOULD display the typed-data fields to the user before confirmation, per EIP-712 best practice.

• cross-chain replay: the domain separator includes chainId and verifyingContract, preventing signature reuse between Base Sepolia and Mainnet.
• secp256k1 malleability: verifiers MUST use low-s ECDSA (EIP-2) to avoid malleable equivalent signatures.
• key loss: loss of wallet access means loss of the ability to sign future manifests. Previous manifests remain valid since the signature is already in the Registry.
• Privy social recovery: Privy MAY rotate keys via social recovery; each rotation produces a new address, which MUST be explicitly acknowledged as the same creator identity via cross-signature.