Version 2026.08

Signature methodology

Each signature is sealed with an HMAC-SHA-256 over a canonical payload and chained to the signature before it, so removing, reordering or altering any signature breaks the chain. A trusted third-party timestamp binds an independent time to the signed content.

Most platforms answer "is this legally binding?" with marketing. Here is the mechanism instead, along with a plain statement of what it does not establish, so your counsel can reach their own view rather than taking ours.

What this is not

  • This is a tamper-evident electronic signature, not a qualified electronic signature under eIDAS and not a digital signature backed by a certificate issued to the signer. We do not claim either.
  • The HMAC key is held by the platform. That means the chain proves nobody has altered a signature without the platform detecting it; it does not prove anything against the platform itself. A signer-held private key would be required for non-repudiation in that stronger sense.
  • We do not assert that a given signature is legally binding in your jurisdiction. Whether an electronic signature binds depends on the governing law of the contract, the parties, and the document type, and that is a question for your counsel, not for a platform.
  • Identity assurance is by email control plus, optionally, an access code. We verify that the person holding the invited mailbox signed. We do not perform identity document verification at the moment of signing, so the signature evidences that mailbox, not a passport.
  • The trusted timestamp proves when the content existed, not who created it and not that either party agreed to it.
  • A voided document keeps its signatures and its chain. Voiding records an intent to retire the document; it does not erase what was signed.

What a signature here is

  • When a party signs, the platform builds a canonical payload naming the document, a SHA-256 hash of its exact content at that moment, the signer, the party slot they signed as, the timestamp, and the hash of the previous signature in the chain.
  • That payload is serialised with sorted keys, so the same facts always produce the same bytes regardless of the order they were assembled in, and sealed with HMAC-SHA-256.
  • Because each signature carries the previous one’s hash, the signatures form a chain. Removing one, reordering them, or editing a signed payload breaks every link after it, and the public verification page detects the break.
  • Once a document is fully signed it becomes immutable. Editing and edit-sharing are both rejected, and a database trigger enforces this rather than trusting the application layer.

What the content hash proves

  • The hash is taken over the document body as it stood when signed. If a single character changes afterwards, the hash no longer matches and the verification page says so.
  • Every downloaded PDF carries a QR code, a verification link, the document id, and a 32-character fingerprint of that hash, so a recipient holding a printed or forwarded copy can check it against the record without an account.
  • A holder of the verification link can retrieve the canonical content and compare it against their copy. This is the case that matters: a doctored copy whose QR still points at the genuine, unaltered original.
  • The issuer letterhead is presentation, not content. It is drawn live from the issuing company’s profile and sits outside the signed and hashed body, so a company that later changes its address does not invalidate documents it signed under the old one.

Independent time

  • Signing requests an RFC 3161 timestamp from a public Time Stamping Authority over the canonical content hash, and stores the returned token.
  • This binds a trusted third party’s signed statement of time to the content. It requires no signing certificate of our own: the TSA’s own publicly trusted chain does the vouching.
  • The verification page renders the timestamp as "Independently timestamped <time> by <TSA>", and re-checks the stored imprint against the current content hash each time it is displayed.
  • Timestamping is fail-open by design. If the TSA is unreachable the signature still completes, without a timestamp, rather than blocking a trade on a third party’s uptime.

Who signed

  • A signing invitation is bound to one email address and, optionally, to one party slot in the document, so an invitee cannot sign as a party other than the one they were invited as.
  • Recipients authenticate with a one-time code sent to that address before they can sign. There is no signup and no password, but there is a verified account behind the signature, which is what puts a signer id in the audit trail.
  • An access code can be required in addition, set by the document owner and shared out of band. That is a second factor on the act of signing itself.
  • Only the most recent signer may withdraw their signature, and only while the document is not yet fully signed. Once every required party has signed, the document is complete and locked for everyone.

What we record and who can see it

  • Document content and form data are encrypted at rest with AES-256-GCM. The plaintext columns have been dropped: encrypted storage is the only storage.
  • Staff cannot read document content through the admin portal. The only content-access path is a superadmin break-glass console that opens a time-boxed access window.
  • When a break-glass window opens or closes, the owner receives an in-app notification and an email, both of which bypass notification preferences and cannot be switched off, and the event is written to the document timeline.
  • The activity timeline records creation, edits, shares, signatures, amendment requests, voiding and staff access, with the actor and time on each.

What would make it stronger

  • A PAdES signature backed by a certificate from a trusted authority (AATL or eIDAS) would show the trusted ribbon in a PDF viewer and bind the signature to an identity vouched for by that authority. This is deliberately deferred until such a certificate is provisioned rather than approximated.
  • Identity document verification at the moment of signing would raise the identity assurance from mailbox control to a verified person. Business Verification already does this at the account level; tying it to the signing act is a separate step.
  • A signer-held key would give non-repudiation against the platform. That is a meaningfully different product, and we would rather say plainly that we do not do it than imply that we do.

Check a document for yourself

Every document has a public verification page that validates the signature chain, shows the content fingerprint, and reports the trusted timestamp. Anyone holding the link or a downloaded PDF can use it, with no account. If a verification result looks wrong, that page is the fastest way to establish it.

Screening methodologyContact support