Everything you need to sign.
Evidence designed to be checked.
Most platforms list a hundred features and gate the ones that matter behind an enterprise tier. DrakonSign does the opposite: a focused signing engine where the trust layer — an evidential record designed to support enforceability — is standard on every plan. Everything below is shipped and live; the few things that aren’t are labelled.
The trust layer
Every envelope leaves a chain of evidence behind it. Each link below is a real artifact you can download, inspect and re-verify — not a brochure claim.
Hash-chained audit trail
auditCreated, sent, verification started, code sent, inbox verified, protected PDF accessed, signed, completed — every event is SHA-256-linked to the one before it, with a UTC timestamp and actor. Events driven by a browser request also record the IP address and user agent; events the platform raises for itself have no request behind them and record neither. Alter, remove or reorder any record and every hash after it stops matching.
Completion artifacts
sealThe moment signing completes, the signed PDF and its certificate are fingerprinted and those hashes are recorded in the chain. Completion artifacts are published once and never rewritten in place, so a fingerprinted file cannot be silently swapped.
PAdES seal + RFC 3161 timestamp
padesWhen signing completes, DrakonSign applies a self-issued PAdES B-T seal if the signing key and RFC 3161 timestamp authority are available. Standard PDF readers can verify byte integrity but show the self-issued signer as an untrusted issuer unless its certificate is trusted separately. B-LT and B-LTA long-term validation material is not shipped. Every level is measured on the produced file rather than assumed. If the timestamp authority is unavailable, a PAdES B-B degradation is recorded rather than hidden — but only when the signature itself validates; otherwise the completion records that a timestamp is present but unverified, that there is a signature that did not verify, or that the seal state is unknown because the file could not be read back. If the signing key is absent, the completion artifact remains unsealed and that degradation is recorded.
External chain anchoring
anchorIf the independent RFC 3161 timestamp authority answers when signing completes, its token anchors the exact COMPLETED event hash and its preceding prefix. Later verification validates that prefix independently and separately reports later events or damage outside the timestamp; when the authority does not answer, an immutable fail-open missing-anchor event is recorded. No completion anchor is expected before completion.
Certificate of completion
certificateA separate PDF — its own file with its own fingerprint, not an appendix bound into the signed document — generated for every envelope that completes. It records signer attribution, event times and verification method, plus IP and browser metadata only for applicable browser-driven events, without guaranteeing human identity or location; it also carries both document fingerprints and a chain-verification statement.
Live verification
verifyOne click in the dashboard, or one API call, recomputes the entire chain from scratch. It validates an external RFC 3161 anchor through the completion checkpoint independently of any later suffix, reports an invalid anchor as a prefix integrity failure, counts later events outside that timestamp, reports suffix damage separately, and treats no anchor as a degradation only when the audit history reached completion.
The full technical story — algorithms, standards, what’s self-issued and what’s independently attested — is on the Security page.
Sending & signing
Recipient roles are routing labels, not legal roles: Signer, Witness and Approver all take the identical ceremony and differ only in ordering and in the word printed on the certificate. There is no statutory witnessing here, which is one of the reasons deeds and other witnessed instruments are excluded — see which documents suit DrakonSign.
Multi-signer envelopes
Several recipients on a single envelope, in the routing order you set, each with their own signing link. Signer, Witness and Approver are routing labels: they order the envelope and print next to that recipient on the certificate of completion, and all three go through the identical ceremony — the same inbox one-time code, the same consent wording, the same fields. There is no statutory witnessing and no separate approval ceremony. CC is the one role that differs: CC recipients do not sign and are not emailed, and are recorded on the certificate of completion.
Signing order
Route signatures in tiers: everyone in a tier signs in parallel, tiers sign in turn. Or leave it flat and let everyone sign at once.
Five field types
Signature, initials, date, text and checkbox — placed precisely on the page, assigned per signer.
Automatic field placement
Signature, date and initial labels detected in your PDF automatically. Review, adjust, send. Deterministic label matching, not a language model — reliable on the documents it recognises, and it simply finds nothing on the ones it doesn't.
Reusable templates
Save a draft envelope — its PDF, recipient roles, signing order and field placements — and stamp out a fresh draft with new names whenever you need it. Drafts only: once an envelope is sent it is evidence, not a template.
Status tracking
Draft, sent, PDF accessed, partially signed, completed — with verification starts and declines recorded in the audit chain, not swept away.
Evidence downloads
The original, the completed signed PDF and the certificate of completion — from the dashboard or the API, with the seal state measured on that completion recorded as it was found.
The signer’s side
Your counterparty never chose your software. Their experience is two minutes long, works on any device, and quietly captures strong evidence at every step.
No signer accounts
Signers receive a personal, expiring link. No registration, no app to install, no password to invent.
One-time code verification
A 6-digit code confirms control of the signer's email inbox before the document is shown — 10-minute expiry, strict attempt caps. This supports attribution; it does not prove human identity or signature genuineness.
Sessions that don't leak
After verification, a short-lived signing session opens — carried in a header, never in a URL, so signing links can't leak through logs or referrers.
Versioned consent
Consent to sign electronically is captured explicitly, and the exact consent text shown is versioned into the record.
Decline to sign
A signer can decline. The decline becomes a chain event with the rest of the evidence — the envelope isn't quietly deleted.
No trackers, ever
Signing pages set no cookies, run no analytics and make no third-party requests — a signer never receives a cookie from us. Signing a document talks to us and no one else.
Automation, and where AI actually is
No chatbot bolted on the side. Field placement is automated and involves no model at all. The two features that do call a language model are off by default and switched on per organisation from Account — because turning them on sends document text to Anthropic in the United States, which is a decision to make deliberately, not one to inherit.
Automatic field placement
Upload a PDF and signature, date and initial labels are detected and placed for you — one API call or one click. You review and adjust; the machine does the drudgery. This one is deterministic label matching, not AI: nothing leaves the platform, and it works whether or not you have the AI features enabled.
Plain-English signer summary
Opt-inA short, neutral summary shown to the signer before they sign — fewer confused phone calls, fewer abandoned envelopes. Advisory only: it is never part of the evidence, never sealed, and the signer is told to read the document itself. Enable it per organisation in Account.
Clause extraction & risk flags
API onlyKey terms, dates and obligations surfaced for the sender before anything goes out, from POST /api/documents/{id}/ai/analysis. Real and callable today, with the same per-organisation opt-in. It is API-only: the dashboard does not call or display clause analysis.
Smart reminders
RoadmapOne-click reminders are built in today; this is the next step — nudges timed to signer behaviour rather than a dumb three-day clock.
Your account, your keys
Invite colleagues into your workspace and give each of them a role — owner, admin or member. Owners handle billing and API keys; admins manage people; members send envelopes. Roles cost nothing extra: there is no per-seat charge, and everyone draws on the same organisation allowance. One person belongs to one workspace, and an invitation is a single-use emailed link that you can withdraw at any time.
Passwordless sign-in
A magic link to your inbox, a session in your browser. No passwords to store means no passwords to breach.
Instant provisioning
Subscribe and Stripe drops you into your dashboard, already signed in, before the receipt lands. A single-use sign-in link follows by email. No API key is created for you and none is ever emailed — you make one when you want one.
API keys, managed properly
Create and revoke org API keys from the dashboard. The plaintext is shown once when you create a key; after that DrakonSign stores only its hash and cannot recover the original value.
Billing that keys can't touch
Manage your plan in the Stripe customer portal, from a signed-in session only. A leaked API key can send documents — it can never touch your billing.
Included here. Extra elsewhere.
| Capability | DrakonSign | The incumbents, typically |
|---|---|---|
| Tamper-evident audit trail | Every plan, every envelope | Often gated to enterprise tiers |
| Certificate of completion | Every completed envelope, automatically | Varies by plan |
| REST API access | Included on every plan | Typically a separate, per-invite bill |
| Pricing | Published, in pounds, on this site | “Contact sales” |
| Signature verification | Recompute it yourself, any time | Take the platform's word for it |
| Where it runs | Live service in London — app, database and documents; encrypted 30-day backups on globally distributed Tigris | US-default, region on request |
“Typically” means exactly that — based on the public pricing and feature pages of the major e-signature providers as of July 2026. Check ours against theirs; that’s the point.
Not shipped yet, said plainly
Per-organisation branding, an org-wide policy that could require two-step sign-in for everyone (two-step is optional, per person, and nothing can mandate it), behaviour-timed reminders, a sealing certificate readers trust out of the box (Adobe AATL) and qualified signatures (QES) are on the roadmap — not in the product today. The last two are substantial engineering, not a change of certificate: see the Security page for why. When a page on this site names a feature without a roadmap label, it’s live.
Try the whole engine free for a month
Every feature above — trust layer included — is on the Starter trial. Billing only starts after 30 days or your 3rd envelope allowance is consumed, whichever comes first.