How Code Four Sign meets the ESIGN Act and UETA

1. Intent to sign

A signature is an act the signer performs, not a mark the system places. A signer draws or types a signature and adopts it by selecting "Adopt and sign this agreement"; only then is that signature bound to the signature and initials fields that belong to them. Nothing is signed while a signer is still working: every value they enter is a draft until they complete, and the completion itself is one step they take after reviewing the document.

The consent statement the signer agrees to at that moment says, in its own words, that they intend their electronic signature to have the same effect as a handwritten one.

2. Consent to do business electronically

Before a signer can complete, the review step shows them the consent statement in full, with its version number, together with a link to the Signer Terms. A checkbox on that statement gates the "Adopt and sign" action; the service refuses a completion whose session has not accepted the current version.

When a signer accepts, the ledger records the version they accepted and a SHA-256 hash of the exact text they were shown. Every consent statement ever used is kept in the source, so the text behind any hash can be produced. A signer who does not agree can decline from the signing page, and the sender is told.

3. Association of the signature with the record

When a sender sends a document, the service freezes a snapshot: the exact PDF bytes (by hash), every field and where it sits, every recipient, the signing order and the consent statement. The snapshot is hashed, and from that moment every event in the envelope's ledger names that hash. What the signer sees is what everyone signs; the document cannot change after send, and a sender who needs a change must void and send again.

When the last signer completes, the service renders the executed PDF from the snapshot and the saved values, hashes each executed document, and seals a completion manifest that lists the original hashes, the executed hashes, the parties, the consent version and the first and last event hashes of the ledger. The completion certificate and the executed PDF both carry those hashes.

4. Record retention and erasure

Completed evidence — the executed PDFs, the completion certificate, the sealed manifest and its signature, the send-time snapshot and the ledger — is written to versioned, create-only storage that the service itself cannot overwrite or delete, in the United States (Google Cloud, us-central1), encrypted at rest with customer-managed keys and in transit with TLS. In production the evidence storage carries a seven-year retention period. Our position is records over erasure: the manifest, the hashes and the ledger are never altered by anyone, including us.

Erasure exists for a lawful request and works by pseudonymization, not deletion. On a completed, voided, declined or expired envelope, a signed-in Code Four operator can replace a signer's name and email address with a tombstone, remove the values they typed and the images of their signature and initials, revoke every link they hold, and withdraw the executed PDFs and the certificate from every download. The ledger gains one row recording that this happened, with counts, never values. Earlier ledger rows that name the signer are kept as sealed, because rewriting one would break every hash after it and with it the evidence for the contract; the sealed manifest likewise keeps the parties it named and the hashes of the withdrawn documents, so a copy someone still holds can be checked. The signer's own copies, and the sender's, are theirs to keep.

5. Integrity

Every event in an envelope — created, sent, opened, consent accepted, signed, completed, sealed — is a row in a hash-chained ledger: each row carries a SHA-256 of its own contents and the hash of the row before it. Altering or removing any row breaks every hash after it, and the chain is recomputed from the rows alone whenever it is read.

The completion manifest is signed by a Cloud KMS asymmetric key (EC P-256, SHA-256). Anyone holding a completed PDF can check it at sign.codefour.us/verify: the service hashes the bytes they upload, finds the sealed manifest they belong to, verifies the KMS signature, recomputes the ledger chain and the snapshot hash, and reports each check separately. The evidence package (evidence.zip) holds the originals, the executed PDFs, the ledger, the snapshot, the signed manifest and the public key, so the same checks can be run with OpenSSL and no Code Four service at all.

The completed PDF also carries a digital signature inside the file (PAdES, ETSI.CAdES.detached) made with the same KMS key under a self-issued Code Four Sign certificate, with an RFC 3161 timestamp from a public timestamp authority when one answers. A PDF reader shows it in its signature panel and flags any later edit; the reader will report the certificate as unknown because it is self-issued, not issued by a public CA. The manifest hashes the signed bytes, so the reader and the verifier are checking the same file, and the manifest remains the primary evidence.

6. Identity

A signing link is minted for one named recipient of one envelope and is sent only to that recipient's email address. The mailbox is the identity. Links are 256-bit random tokens stored only as hashes; they expire with the envelope or after thirty days, and every link a signer holds stops working the moment they complete or decline or the envelope is voided.

Where the sender chooses it, a signer must also enter a six-digit one-time code emailed to the same address (valid ten minutes, five attempts, with resend limits), or an access code the sender gave them separately, before they see the document. Code Four staff who countersign are identified by their Code Four account. Attempts at these gates are rate-limited and recorded.

7. What we record

Each ledger row records the moment it happened, the actor (the recipient, a Code Four operator, the service or the connected system), the signer's network (IP) address as seen at our own edge, the browser's user-agent string (truncated to 400 characters) and the signing session it belonged to. The ledger never carries a signing token, a one-time code, an access code, the text a signer typed or the strokes they drew: values appear only as hashes, and the values themselves live in the record.

A drawn signature is stored as geometry only: the shape of the strokes, normalized to the pad. How quickly it was drawn is not kept.

8. What we do not do

Plainly, so nothing here is read into the service that is not in it:

• We do not verify a signer's legal identity, check a government ID, or use biometrics. Identity is the mailbox, plus the one-time or access code where the sender asks for one.
• We do not claim eIDAS advanced or qualified signature status, and we make no claim of SOC 2, ISO 27001 or HIPAA certification on this page.
• We do not sell, share or use a signer's data for any purpose other than executing and evidencing the document they were sent.
• We do not index this site for search engines, and signing links are never published; every link is personal.
• We do not give legal advice. Whether an electronic signature is enforceable for a given document in a given place is a question for the sender's counsel.