Electronic signatures

Chaindoc produces PAdES Advanced Electronic Signatures (cryptographic signatures embedded directly inside the PDF) and adds an independent blockchain-anchored integrity proof. This page covers the signing workflow, what the signer sees, compliance, the audit trail, and how anyone can verify a signed document.

If you're new to Chaindoc, the quick start guide walks you through sending your first signature request. For the full API reference, see API documentation. Learn more in the eIDAS Regulation (EU) No 910/2014.

How Chaindoc signatures work

Every Chaindoc signature is a PAdES-BES (PDF Advanced Electronic Signature, Baseline-B). the same standard used across European e-signature platforms. Each signature is a cryptographic PKCS#7/CMS container embedded inside the PDF, tied to a dedicated per-user certificate issued by Chaindoc's Certificate Authority. On top of that, a hash of the signed document is anchored to the blockchain, giving you a second, public-verifiable integrity channel. Learn more in the ESIGN Act of 2000.

What you get in the signed PDF

• A cryptographic signature (ECDSA P-256) that a standard PDF reader will show as "Signed and all signatures are valid" for each signer
• A signer certificate issued by Chaindoc's CA, linked to the signer's verified email
• Signing time and reason/location metadata embedded in the signature dictionary
• The document hash anchored on-chain, with the transaction hash stored in the certificate of completion

Legal compliance

Because every signature is PAdES with a dedicated per-signer certificate, it satisfies the four criteria for an Advanced Electronic Signature under Article 26 of eIDAS (EU Regulation 910/2014):. Learn more in the PAdES standard (ETSI EN 319 142).

• Uniquely linked to the signatory: the ECDSA key pair belongs to a single user.
• Capable of identifying the signatory: the X.509 certificate binds the key to the signer's verified email.
• Created under the signatory's sole control: private keys are encrypted at rest and released only for that user's signing actions.
• Linked to the signed data so tampering is detectable: any byte-level modification invalidates the PAdES signature.

Recognised under

• eIDAS: Electronic Identification and Trust Services (EU). Chaindoc signatures qualify as Advanced Electronic Signatures under Article 26.
• ESIGN Act: Electronic Signatures in Global and National Commerce (United States).
• UETA: Uniform Electronic Transactions Act (United States, adopted in most states).
• PIPEDA: Personal Information Protection and Electronic Documents Act (Canada).
• Electronic Transactions Act (Australia).
• Information Technology Act (India).

Signing workflow

Creating a signature request

Actually, you can create a request through the dashboard or the API. The steps are the same either way:

1. 1
   Actually, upload a document (PDF, Office formats, or image. up to 250 MB through the current upload API).
2. 2
   Add signers by email.
3. 3
   Optionally pre-place signature fields on specific pages (see field types below).
4. 4
   Set a deadline and an optional message.
5. 5
   Actually, choose whether the flow is embedded (iframe inside your app) or email-link-based.
6. 6
   Send.

From the Server SDK: chaindoc.signatures.createRequest(...). See API documentation → Signatures for the full request body.

Signature field types

Actually, when pre-placing fields on a PDF (the optional fields array in the create-signature-request call), the following field types are supported:

• signature: the signer's visible e-signature glyph. The cryptographic PAdES signature is always attached to the document regardless of whether you place a visible field.
• initials: for initialing pages or clauses.
• date_signed: auto-filled with the signing timestamp.
• text: free-form text (name, title, comment).
• checkbox: consent or acknowledgment.

Fields use percentage-based placement (resolution-agnostic) and are bound to a specific signer by email. See the API reference for the exact shape of PlacedFieldDto.

Signing order

Signature requests are parallel: every signer receives an invitation at the same time and can complete their signature independently. The request completes once all signers have signed. Sequential and conditional signing aren't supported.

Reminders

If a signature request has a deadline, Chaindoc automatically sends reminder emails to signers who haven't signed yet at 7 days, 3 days, and 1 day before the deadline. The schedule is fixed. there's no per-request override today.

What signers see

The signing flow

1. 1
   Email invitationThe signer receives an email with a secure link. No Chaindoc account is required.
2. 2
   Email OTPActually, after clicking the link the signer enters a one-time code sent to their email. this verifies control of the address before they can view the document.
3. 3
   Document reviewThe document opens with any pre-placed fields highlighted, showing exactly where to sign, initial, or fill in information.
4. 4
   Sign and confirmThe signer draws their signature on a canvas, uploads an image of their handwritten signature, or reuses one saved from a previous Chaindoc session. They fill any required fields and confirm. The backend produces the PAdES-signed PDF with the signer's ECDSA key and records the event in the audit trail.
5. 5
   Signed copy deliveredAll parties receive the PAdES-signed PDF along with a certificate of completion once every signer finishes. The PDF will display "signed and all signatures are valid" in any standard PDF reader.

How signers produce a signature

Actually, three methods for the visible signature glyph. the cryptographic signing happens the same way regardless of which method you pick:

• Draw with a mouse, trackpad, or touchscreen.
• Upload an image of a handwritten signature.
• Reuse a signature saved from a previous session.

Blockchain verification

Separate from the PAdES signature inside the PDF, Chaindoc writes a hash of the signed document version to the blockchain. This is an independent, permanent record (no one, including Chaindoc, can alter or delete it after the fact) and it gives you a second channel to detect tampering even if the PDF's signature layer is stripped or damaged.

What gets recorded on-chain

• A cryptographic hash of the signed document version.
• A unique transaction hash (txHash) for the anchoring event.
• Chain ID so verifiers know which network to query.
• Timestamp of the transaction.

How to verify a signed document

There are two independent paths, and both should agree:

• Any PDF reader. Open the signed PDF in Adobe Acrobat, Preview, Foxit, etc. The reader will show "Signed and all signatures are valid" and display each signer's certificate details. This verifies the PAdES signature.
• Blockchain check via chaindoc.io/pdf-verify. Upload the file. Chaindoc re-hashes it, queries the on-chain record, and shows integrity status, signing timestamps, and signer details.

Actually, programmatic blockchain verification is also available via POST /api/v1/documents/verify and chaindoc.documents.verify() in the Server SDK. useful when you want to re-check integrity from your own backend instead of the public portal.

Audit trail

Every signature event generates a record with the fields you'd present to a court or auditor if a signature is ever disputed:

• Request creation. who sent the request, when, to which recipients.
• Per-signer signing timestamp (millisecond precision, UTC).
• Signer IP address and user-agent string (captured at the moment of signing).
• Email-OTP verification timestamp for each signer.
• Decline events. timestamp, reason (up to 500 characters), and signer identity.
• PAdES signature metadata. certificate serial, issuer, signing time.
• Blockchain anchoring. transaction hash and chain ID.

Certificate of completion

Generated automatically as a PDF once all parties have signed. It bundles:

• Document title and version identifier.
• All parties, their email addresses, and their actions.
• Signing timeline.
• Signature images / typed names.
• Blockchain transaction hash and chain ID.
• Reference to the PAdES signature inside the signed PDF.

Cancelling and declining

Sender: cancel a request

You can cancel any pending signature request before completion. The request moves to the cancelled status and all signers are notified. This is logged in the audit trail and can't be undone. if you need to send the same document again, create a new request.

Signer: decline

Actually, a signer can decline instead of signing and add a reason (up to 500 characters). The request transitions to a cancelled/rejected state and Chaindoc emits signature.request.rejected with the signer email, reason, timestamp, and document identifiers.

Best practices

• Use clear document titles. Consulting Agreement 2026-04 beats Contract_v3_final_FINAL.pdf.
• Compress large PDFs before uploading. the API accepts files up to 250 MB, but smaller files render faster for signers.
• Place signature fields where signers naturally expect them (bottom of the page, next to a printed name line).
• Label fields clearly (Client signature, Manager approval) not just Signature 1.
• Actually, test the signing flow against a test email address of your own before sending to real recipients.
• Set a realistic deadline. 7 to 30 days is typical for most contracts.
• When distributing the final PDF, keep it intact. re-saving through a non-compliant PDF tool can strip or break the PAdES signature layer (the blockchain anchor still holds, but you lose the PDF-reader validation).

Troubleshooting

Signer didn't receive the email

Actually, ask the signer to check spam and promotions folders first. Corporate filters sometimes block signing links. adding chaindoc.io to the allowlist fixes that. If the address was wrong, you can cancel the request and re-send to the correct one.

Signing link expired

Once the deadline passes the request moves to expired. Create a new signature request for the same document version to restart the flow.

Drawing a signature doesn't work on mobile

Make sure the browser allows touch input on the canvas area. If it still doesn't cooperate, the signer can fall back to typing or uploading an image. all three methods produce the same PAdES signature under the hood.

PDF reader shows "Signature isn't valid"

Usually means the file was modified after signing. saved through a lossy tool, re-compressed, or OCR-processed. The blockchain anchor still lets you prove the original was signed by Chaindoc; upload the file to chaindoc.io/pdf-verify to see the last on-chain state. For safekeeping, always archive the as-delivered PDF.

For API-specific problems, see API documentation. For webhook delivery issues, the webhooks guide covers retries and debugging.