Just need it signed? Skip straight to the signature.
Upload a document, add signers, dispatch it, and watch it become a signed, certified copy — no approval gate, no stamping, none of the rest of the lifecycle to manage afterward.
Every signer tracked, not one opaque "sent" state
Each signer's status moves independently — you know exactly who has and hasn't opened, viewed, and signed.
Illustrative playback of three real dispatch scenarios — the outcomes shown (OTP retry, watermarking, certificate generation) are real, tested backend behavior, replayed here rather than a live request.
Chosen for each signer, never left to a caller's choice
The method is decided deterministically from the signer's own type.
- 1Individual signer opens the linkOTP
- 2Aadhaar verified through the empanelled ESPeKYC
- 3Signature blob + certificate capturedEvidence
The Aadhaar number and eKYC response are discarded the moment the output artifact is captured — a hard invariant in the code, not a policy layered on top.
- 1Organizational signer authenticatesToken / HSM
- 2Class 3 Digital Signature Certificate appliedDSC
- 3Certificate + transaction ID capturedEvidence
Used for organizational and counter-signers — the higher-assurance method matched to what the signer type actually is.
| Method | Signer type | Verification | Evidence captured |
|---|---|---|---|
| Aadhaar eSign | Individual | UIDAI-empanelled ESP, OTP-based eKYC | Signature blob, certificate, txn ID, timestamp |
| Class 3 DSC | Organizational | Token / HSM-backed digital certificate | Digital signature, certificate, txn ID, timestamp |
OTP step-up, then a watermarked copy
A leaked link doesn't turn into a leaked, un-attributable document.
This applies per recipient, every time — not once per document.
Not a "done" badge — a rendered record
Every completed request produces a certificate you can actually check, not a green checkmark you take on faith.
Certificate of Completion
Vendor NDA · Acme Corp · 3 signers
- Full event sequence12 entries
- Signer methods & timestampsRecorded per signer
- Chain-integrity checkVerified ✓
- Attestation typeSelf-issued (HMAC)
Nothing to configure, all of it real
Every eSign request is a real CLM record underneath — nothing to migrate if you later need approvals or obligations too.
Counterparties and their signers live in one directory — never re-typing an email address you already have on file.
Status per signer, not a single opaque "sent" state — you know exactly where a request is stuck.
Every dispatch and signing call is idempotency-keyed, so a retried request can never double-send or double-sign.
The same tamper-evident chain, every dispatch
Every durable action writes an entry cryptographically linked to the one before it.
Aadhaar numbers are never stored
Only the ESP's output artifacts are kept. The Aadhaar number and eKYC response are discarded the moment that output is captured.
OTP step-up before anything unlocks
Opening a dispatched document requires a one-time code — nothing renders before that check passes.
Idempotent, retried, never doubled
Every vendor call is wrapped in retry-with-backoff and idempotency keys — a network blip retries safely instead of double-sending.
Per-tenant document encryption
Every tenant's documents are encrypted under their own key, with real rotation mechanics — not one shared key protecting everyone.
Tenant isolation on every query
Every database access runs through one tenant-scoped path — enforced by the database itself.
A public, checkable chain
A public endpoint re-walks a tenant's audit chain and confirms nothing has been altered — not a private admin-only tool.
Roadmap
Said outright, the same way the rest of Xirag's product docs work.
Aadhaar eSign and Class 3 DSC are mocked pending empanelment
Both sit behind a real, method-distinguished interface with a MockESignatureProvider until the corresponding ESP is empanelled. Everything around the seam — retry, idempotency, evidence capture, certificate attachment — is real and tested; only the vendor call itself is standing in.
The Certificate of Completion is a self-issued attestation
It proves this system computed this exact certificate content at this moment — it is not an RFC 3161 or PAdES-LTV trusted timestamp from an independent third party. Stated on the rendered certificate itself, not hidden.
No sign-execution UI for internal signers yet
Executing a signature needs a document hash computed from the actual document bytes client-side — that flow, and the counterparty's own unauthenticated recipient page, aren't built into this console yet.
Nothing to configure. Just send it.
The same signing engine as Xirag CLM, none of the setup.
Open Xirag eSign Need approvals, playbooks, and obligations too? See Xirag CLM →