Skip to content
Exedra Gate docs

Signing and evidence packs

The signing flow

Prepare a document, add signers, place the fields each signer must complete, then send. An envelope moves through created, sent, and then completed, declined, voided or expired. The client dashboard is /app/issuer/signing. Reusable templates live at /app/issuer/templates.

Signing runs on Exedra Gate's own signing engine. There is no external e-signature vendor in the path.

The audit log

Every step writes to an append-only audit log that is hash chained, meaning each entry commits to the one before it. Removing or altering an entry after the fact breaks the chain, which is what makes tampering detectable rather than invisible.

What an evidence pack is

When signing completes, Exedra Gate generates an evidence pack: a JSON record, a PDF rendering and a manifest, stored as immutable artifacts. The pack contains the envelope metadata, the signer records, the document hashes and the ordered audit trail.

What a pack proves and what it does not

A pack shows that specific documents, identified by their SHA-256 digests, were signed by identified signers in a recorded order at recorded times, and that the record has not been altered since it was sealed.

It does not prove that the contents of a document are true, that a signature was a good idea, or that anyone was legally entitled to sign. It is a record of what happened, not a judgement about it.

Signature and timestamp

The pack hash is signed with Ed25519 using a managed key, and the key id is written into the pack, the manifest and the PDF header so an old pack can still be checked against the key that signed it after a rotation.

An independent RFC 3161 timestamp authority timestamps the manifest hash. When timestamping is set to required, a failure means no evidence pack is produced. That is deliberate: a pack without an independent timestamp is not the artifact we promise, so the system refuses rather than issuing a weaker one.

Verifying a pack

Every pack is yours to download and keep, at any time, for as long as you want it. Download them before you close your account and you keep them afterwards.

Nothing about a pack is proprietary. The hashes are SHA-256, the signature is Ed25519 and the timestamp is an ordinary RFC 3161 token, so an auditor or an expert can check one with standard tooling: compare the document hashes to the manifest, check the signature over the pack hash against the public key for that key id, and check the timestamp with openssl ts -verify.

What the timestamp establishes: an independent authority attests that this content existed at that moment. That is evidence a court can weigh. It is not the same as an eIDAS qualified timestamp, which carries a legal presumption on top; if you need that stronger form, ask us about it before you rely on it.

Where to find them

/app/issuer/evidence has two views: the sealed packs, with the seal state, the digest and an in-app viewer, and the workspace evidence ledger of evidenced events visible to you.

Taking your packs with you

Every sealed pack is yours to download and keep, at any time. /app/issuer/evidence has a single action that exports all of them at once, so you do not have to download them one at a time. Workspace owners and admins can run it.

Most workspaces get one zip archive, with a folder per pack, an index and a readme that explains what each file is. A workspace holding a very large number of packs gets a manifest of download links instead, because an archive that size cannot be assembled in one piece reliably. The manifest states which case applies and how to fetch the files, and support can supply a small retrieval script that does it for you.

If your subscription is set to end, we email the workspace owners and admins twice: once when the cancellation is recorded, and again about a week before access ends. Each message names how many sealed packs the workspace holds and links straight to the export. You can mute those messages in your notification settings, in which case we record that they were not sent.

The export keeps working for 30 days after your access ends. A final invoice should not be the first you hear about this.

Obligations after closing (covenant tracker)

Once an envelope is sealed, an owner or admin can record the obligations that follow from it: a title, a due date, an owner in the workspace, and whether a document is required to mark it met. Each obligation and every change to it is written into the envelope's audit trail as a process fact (recorded, record filed, waived, due date passed), so a later evidence pack shows what was promised and what record was filed. The platform makes no finding about performance.

  • The owner and the workspace's owners and admins are reminded two weeks before, three days before, and once when the date passes. A passed date shows the obligation as Due date passed and writes "due date passed, no record filed" to the trail; that is information, not a consequence or a finding. It can still be marked met late, or waived with a reason.
  • Mark met records the fingerprint of the data-room document that shows it was met. Waive records the reason.
  • If you tick Visible to all investors related to this workspace, every investor you have invited can see the title, due date and status, nothing else. The reminders run only once the workspace's scheduled job is registered by the operator.

The tracker records and reminds. It does not hold, move or release anything.

Dual-key attestation (four-eyes finalize)

A workspace owner or admin can require that an envelope is attested by two or more different team members before it can be sealed. Each attestation is a passkey signature over the final documents, recorded in the envelope's tamper-evident audit trail and carried into the evidence pack.

  • Roles that may attest are set in the policy (by default: owners and admins). A member attests from the envelope row under Attest with passkey. The first time, the browser asks you to create a passkey; attest once more to record it.
  • The envelope shows Awaiting attestation 1/2 until the policy is met. Eligible members who have not attested are notified in-app and by email.
  • Attestations must happen inside the policy window (the default is set by the operator). If the window lapses, an owner or admin can Reset window; the count then starts again from zero.
  • Sealing cannot bypass this step, including a forced finalize. The evidence pack lists every attestation, and the offline verifier (exedragate-verify, check 8) re-verifies each passkey signature under the key recorded in the trail.

What the record proves: that the recorded keys produced genuine signatures over that document set, inside the window, by distinct accounts. It does not by itself prove who holds those keys; passkey enrolment is a workspace record.