Signatures and ceremonies · Sydney · October 2026
Wippli SignWippli Sign
Certified signatures. Verifiable by anyone.
CeremoniesPermissionsVerifyApplicationsThe processContact
Verify a documentSign a document

Front page

This is
Wippli Sign.

Sign in turn. Keep the record.

Wippli Sign runs signing ceremonies: a key by email, one party at a time, a certificate for every signatory, a seal with an independent timestamp, and a record that a stranger can check without an account.

Own signing authorityTimestamped by DigiCertPublic ledger

Read the ceremoniesThe process
Figure 1 · Ceremony cer_SmC3L6Pb3vDSLedger entry 18
1 · PreparedOrganiser places 5 fields, sends25 Oct 2026, 13:27 UTC
2 · KeyEight digits by email, one party at a timetries limited
3 · SignedParty 1, then Party 2, each in turncertificate per party
4 · SealedPAdES seal, DigiCert timestampsha256 f2a4a492
5 · On the recordAttestation, audit log, public ledgerprf_pOVicTgP_Cui
Stored encrypted under its own keyAnyone can verify at sign.wippli.ai/verify

Ceremony 01 · Documents

A signature that a stranger can check.

Each ceremony issues a short-lived certificate to every signatory, seals the document to the PAdES standard with an independent timestamp, writes an audit log of who opened and who signed, and enters the result in a public ledger. A key by email, in turn; no account, no app, no password.

  • Signing PrepPay per document, no subscription. You organise, they sign, in the order you set. US$9.99 a document.
  • In turnOrganiser first, or any party first. Each signatory sees the signatures before theirs; the organiser is told at every step.
  • CopiesThe signed PDF, the audit log and the proof go to every party when the last one has signed.
Figure 2 · What holds it uppolicy 0.1
  • Issued per ceremony: a certificate per signatory, an attestation of what each filled in, a seal over the PDF and the audit log, a signed proof envelope.
  • Independent of us: time from DigiCert, free verification at sign.wippli.ai/verify, a public hash-chained ledger, storage encrypted per document.
Signing PrepThe ledger

Ceremony 02 · Permissions

An agent asks. A person approves.

A requester, human or machine, states who is asking, what action, for how long, for which task and why. One approver reads a one-page permission request and signs it with an emailed key. The signature becomes a sealed PDF, a sealed audit log, a signed proof that carries the request as claims, and a ledger entry. The proof goes to the service that asked, and that service decides what the grant means.

  • RequestRequester, action, duration, task and reason, as submitted.
  • ApprovalOne named approver, one emailed key, one page to read and sign.
  • ProofThe claims ride inside the certificate, the seal, the audit log and the envelope.
  • CallbackDelivered to the asking service, which grants, limits or refuses.
Figure 3 · The claims, in four placesEC P-256, two hours
  • In the signatory's certificate, issued for that ceremony only and named after it.
  • In the seal, with every party's certificate fingerprint.
  • In the audit log, a sealed PDF with the whole trail: created, emailed, opened, signed, sealed, delivered.
  • In the proof envelope, signed by the authority's proof key, public at a fixed address.
Read the processSigning policy

Verification · Open to all

No account. No call to us.

Checking a Wippli Sign document needs nothing from Wippli. The root certificate and the policy are published. The verify page reads a sealed PDF or audit log and reports what it finds. The ledger is a public hash chain with one entry per completed ceremony.

  • The rootroot.pem under .well-known; its fingerprint is printed in every audit log and on the back of every task board.
  • The policypolicy.json: the version in force, the claims extension, timestamping on, the verify address.
  • The pageSeal intact, signature valid, trusted by the root, timestamp time, and whether the file's hash is on the ledger.
  • The ledgerapi/ledger: every completed ceremony, chained by hash, readable by anyone.
Figure 4 · The docketlive and proposed
01 · Document ceremonieslive
02 · Permission ceremonieslive
03 · Identity check before signingproposed
04 · Ledger anchored outside the serviceproposed
05 · Revocation of a grantproposed
Verify a documentAuthority root

Editorial

Real seals. Plain words.

The seal rests on the Wippli Sign root, not on a public certificate authority. The timestamp is the independent part. Every page and every email says exactly that, and no label can make them name an authority the timestamp does not point to. What a signature binds depends on the law that applies to you.

Signing policyAuthority root
Figure 5 · What is real, what the limits arepolicy 0.1

Ceremonies · what is real

  • The seal and the timestamp are real and verifiable by anyone
  • Every signatory gets a certificate issued for that ceremony alone
  • Keys are eight digits, tries are limited, and documents are encrypted at rest
  • Every completed ceremony is on a public hash-chained ledger

Limits · what it is not

  • Identity means holding the emailed key; a document and selfie check is not yet a step
  • A grant ends when the receiving service ends it; the engine records the duration and has no revocation call
  • The ledger's root hash is not yet published outside the service
  • Nothing here is legal advice

Practical applications

Where a sealed signature earns its keep.

01

Contracts between strangers

One organiser, up to four parties, in the order you set. Each party's own certificate and attestation sit inside one proof, checked by anyone without an account.

Ceremony, organiser-led
02

Agent permissions

An AI agent asks for a specific action for a set time; a named person approves it by signing. The approval travels as claims inside a verifiable proof, and the asking service decides what it allows.

Ceremony as a permission
03

Insurance claims

Claimant, assessor and insurer each sign their part in turn. The audit log shows who saw what and when; the sealed file is the version everyone holds.

Ceremony, sequential
04

Board resolutions

Directors sign one resolution in sequence, each seeing the signatures before theirs. The proof names the count of signatories and the time of each seal, nothing more.

Ceremony, multi-party
05

Procurement sign-offs

A purchase, a variation or a release is approved with the request itself written into the certificate. The receiving system verifies the proof before it acts.

Ceremony with claims
06

Rehearsed, then signed

Where a process should be rehearsed before anyone signs, our sister platform no-legal-advice.com runs the simulation and the ceremony here seals the outcome.

Simulation at no-legal-advice.com

An invitation

Certified ceremonies, for every process.

Insurance, construction, health, finance, education, public bodies: wherever a signature has to be checked by a stranger, or an agent's action needs a named person's approval, we can set the ceremony up. One product is live today; the method travels.

Contact us sign@wippli.ai
Write to usSee the store

Tell us the parties, the order and what the record must prove. We answer with a proposal and a first run.

A ceremony, simulatedPreparing
Service agreement
Party 1 · signature
Party 2 · signature
Key emailed · 8 digitsKey emailed · 8 digits
  1. 01Organiser places the fields and sendsOrganiser
  2. 02An eight-digit key goes to Party 1 by emailWippli Sign
  3. 03Party 1 opens with the key and signsParty 1
  4. 04A key goes to Party 2; the organiser is toldWippli Sign
  5. 05Party 2 sees the first signature and signsParty 2
  6. 06Sealed with a certificate and an independent timestampWippli Sign
  7. 07Copies and audit log to everyone; proof on the public ledgerOn the record

The Scott process

Four moves, one record.

Named after Scott Evans' paper on claims, published policy and reckonable signatures. A named person grants a requester a specific action for a set time, and the grant is recorded so that a stranger can verify it. Wippli Sign implements the approval and the record; the service that asked implements the grant.

Figure 6 · The processRequest · Approval · Proof · Callback
01 Request claims

Who asks, for what, how long, which task, why

A person, an agent or a service raises the request. Nothing is shortened: the one-page permission states what signing will mean.

Here: the permission request form
02 Approval key

One approver, one emailed key, one page

The approver enters the key on the task board, reads the page and signs. Identity is possession of the key, and the tries are limited.

Here: the key gate on the board
03 Proof seal

Sealed PDF, sealed audit log, signed envelope, ledger entry

The claims are written into the signatory's certificate, the seal, the audit log and the proof, which is public at a fixed address.

Here: api/proofs/prf_pOVicTgP_Cui
04 Callback grant

The asking service decides

The proof is posted to the service that asked. It verifies the seal against the published root, matches the claims to its own request, and answers: granted until, or refused.

Here: the receiver's answer
Claims in every certificate · published policy · public ledgerRead a proof

this is

Wippli Sign