How the integrity architecture works.

What is hard to do here, by design

• Fake thousands of people
• Impersonate a public figure without being challenged
• Change what people already signed
• Manipulate the public count
• Extract personal data
• Falsify a government or institutional status

Signature integrity

Every signature stores the version and the SHA-256 hash of the exact Accord text that was agreed to. Published versions are immutable: changing the wording creates a new version and leaves every earlier signature pointing at the old text. Completion is idempotent, so a retried request returns the same signature instead of creating a second one.

Audit chain

Consequential actions are written to an append-only log where each entry hashes the previous entry’s hash together with its own contents. Deleting or editing any row breaks every hash after it, so tampering is detectable even by someone with database access.

Data separation

Contact details are encrypted with AES-256-GCM and stored in a separate schema with no foreign key into the public application tables, so it can be moved to its own database with its own credentials without a migration. Lookups use keyed HMACs rather than plaintext.

Counter integrity

One transactional database is the only source of truth. Counters are recomputed from it on a schedule and compared; a mismatch is reported rather than quietly corrected. A signature and the event that updates the counters commit in the same transaction, so they cannot drift apart.

Reporting a vulnerability

A published security contact and a coordinated disclosure policy are required before public launch and are not in place yet. Exploit details are never published before remediation.

Bot and abuse protection

Layered, because no single check is sufficient. Email verification gates every count. A hidden honeypot field catches naive scripts and answers them exactly as it answers a person, so a bot cannot tell it was caught. Rate limits apply per endpoint. A risk score combines a bot challenge, signup velocity per network and per email domain, and known throwaway email providers.

Two deliberate restraints. A shared IP address never rejects a signature on its own, families, schools, offices and public networks legitimately produce many real signatures from one address. And a throwaway email domain only nudges the score; it is never a rejection by itself.

A raised score asks for a verification check. It never silently rejects, and the score is never disclosed. What we store for this is deliberately blunt: a keyed hash of a network prefix rather than an address, the domain half of an email, and coarse buckets, enough to see a botnet, not enough to profile a person. Those records are deleted after 30 days.

Signer control

A signer can correct their name, change their country, change whether they are listed publicly, export everything we hold, and withdraw entirely, through a single-use magic link, with no account and without contacting anyone. Withdrawal revokes every active session for that signer immediately.

Not in place yet

• Independent penetration test
• WAF and CDN protection
• Independent identity verification
• Signed daily transparency manifests
• Backup and restore exercise