Signed. Sealed. Verifiable.
Every PDF signed on eContract carries four layers: the signer’s certificate-based signature, an organization seal, a platform seal and an RFC 3161 timestamp. Every action is logged in a hash-chained audit trail.
4-Layer Signing Architecture
Each signed PDF carries four cryptographic layers, applied in this order.
Signer Signature
After the signer confirms a one-time email code, the signature is applied with an X.509 certificate issued by the workspace’s own certificate authority.
Organization Seal
The organization’s digital seal, applied automatically, shows that the document was sent from its workspace.
Platform Seal
eContract’s platform seal shows that the document went through eContract’s signing process.
Timestamp Authority (TSA)
An RFC 3161 timestamp from a timestamp authority records when the document was signed.
Changes After Signing Are Detectable
Each signature covers a cryptographic hash of the document. If the PDF is changed after signing — even by one character — the hashes no longer match and verification reports it.
- Cryptographic hash verification on every signature layer
- Check any signed PDF on the public verification page
- Verification shows each signature, its certificate and the timestamp
- Audit trail events are hash-chained, so edits to the log can be detected
All 4 signature layers verified. No modifications detected.
Document modified after signing. Hash mismatch on Layer 2 (Organization Seal). Original integrity compromised.
Every Action, Recorded and Hash-Chained
The audit trail records who did what and when for each contract. Its weight as evidence depends on the court and the jurisdiction.
Who
The signer’s email, confirmed by a one-time code, and the certificate used to sign
When
The time of each event, plus an RFC 3161 timestamp on the signed PDF
Where
The IP address of each action
What Device
Browser and operating system (user agent)
What Action
Created, sent, viewed, signed, declined — each step is logged
Hash Chain
Each event is linked to the previous one by a SHA-256 hash, from creation to the final signature
PKI Certificate Hierarchy
Your Workspace’s Own Certificate Authority
Each workspace has its own certificate authority under the eContract root CA. This is an internal PKI: the certificates are not issued by a public or government-accredited certificate authority.
- A separate certificate authority for each workspace
- Private keys are stored encrypted on eContract’s servers
- Certificates for seals and signatures are issued automatically
- Certificate details are shown on the verification page
Anyone Can Verify. No Account Needed.
Our public verification page at econtract.online/verify lets anyone check a signed PDF: each signature, its certificate chain, the timestamp and whether the file changed after signing.
Built on International Standards
PAdES-T
PDF Advanced Electronic Signatures with a timestamp, embedded in the signed PDF.
RFC 3161
Internet X.509 PKI Time-Stamp Protocol — a timestamp authority records when the document was signed.
SHA-256
Secure Hash Algorithm — used to fingerprint documents and to chain audit trail events.
X.509
International standard for public key certificates — used for every signature and seal on the platform.
Privacy
How we handle personal data is described in our Privacy Policy.
Security FAQ
How does eContract protect a signed contract against changes?
Every signed PDF carries four layers: the signer’s certificate-based signature, the organization seal, the platform seal and an RFC 3161 timestamp. If the file is changed after signing, the hashes no longer match and verification reports it.
What is PAdES-T and why does it matter?
PAdES-T (PDF Advanced Electronic Signatures with Timestamp) is a standard format for signatures inside PDF files, with a timestamp from a timestamp authority. PDF readers and verification tools can check the signatures, and the timestamp shows when the document was signed.
How are private keys protected?
Private keys are stored encrypted on eContract’s servers. Each workspace has its own certificate authority under the eContract root CA: Root CA → Workspace CA → organization and signer certificates. This is an internal PKI, not a public or accredited certificate authority.
Can anyone verify an eContract-signed document?
Yes. Anyone can upload a signed PDF at econtract.online/verify. The page checks each signature, the certificate chain and the timestamp, and shows whether the file changed after signing — no account required.
What information is recorded in the audit trail?
Each event is logged with who performed it (a team member, or a signer whose email was confirmed by a one-time code), when, the IP address, the browser (user agent) and what was done (created, sent, viewed, signed, declined). Events are linked by a SHA-256 hash chain, so changes to the log can be detected.
Which standards does eContract use?
X.509 certificates for signatures and seals, PAdES for signatures in PDF files, RFC 3161 for timestamps, and SHA-256 for document hashes and the audit trail hash chain. Connections use HTTPS (TLS).
Ready for Verifiable Contracts?
Create a free workspace and send your first contract for signature in a few minutes.
Get Started Free