SHA-256 integrity hashing. Structural minor/guardian handling. Automatic revocation. Not marketing fluff — here's exactly what happens under the hood.
Every participant at a park must sign a Release of Liability (waiver) before they can participate. The system enforces this at every entry point — online booking, onsite registration, POS check-in, and ticket claiming. A waiver is always tied to a specific park and a specific user. If a user visits multiple parks on the platform, they sign a separate waiver for each park.
The signing process has 6 steps, triggered after registration, booking, or ticket claiming.
After registration, booking, or ticket claiming, the user is redirected to the compliance page.
The system checks whether the user already has a valid waiver for that park. If they do, the compliance step is skipped entirely.
The user sees the park's full Release of Liability text, a summary of their personal details, and is asked to provide their address, type their full legal name, draw their signature, and confirm acceptance.
On submit, the system captures and stores all waiver data including cryptographic hashes.
A background job generates a PDF copy of the signed waiver and stores it alongside the waiver record.
The user is sent back to wherever they came from — booking confirmation, registration, or claim overview.
Every signed waiver records 15 data points for legal protection and forensic traceability.
Yes. The system computes a SHA-256 hash over a canonicalized JSON representation of all waiver data — name, email, phone, date of birth, document text, signature name, IP, user agent, and address. This hash is stored on the waiver record and printed on the PDF.
If any field in the waiver record were ever altered after signing, the hash would no longer match. This provides cryptographic proof that the stored waiver data has not been tampered with since the moment of signing.
The signature image has its own separate SHA-256 checksum, computed at upload time. This independently proves the signature file has not been modified.
This is stronger than Smartwaiver's document ID approach (an opaque identifier, not cryptographic proof) and ROLLER's encryption-only approach (no publicly documented per-waiver hash).
A minor (anyone under the park's legal age, typically 18) cannot sign their own waiver and cannot be the booking owner. A parent or legal guardian must create their own account, sign the waiver on behalf of the minor, and add the minor as a participant.
A Zod validation schema checks the date of birth against the park's legal age. Underage submissions are rejected with clear guidance for both minors and confused parents.
The first screen asks: Adult or Child? Selecting Child forces the adult to register first.
When claiming a ticket for a child, the system requires an adult to be identified first.
When staff requests a waiver for a minor, an overlay requires them to search for and select the responsible adult first.
The signedBy field always points to the adult who signed — never the child. The PDF clearly shows 'Signed for: [child]' and 'Signed by: [parent]'.
The signedBy and userId are separate first-class fields in the data model. The signer-to-participant relationship is structural, queryable, and enforced by code — not just a text-level distinction on a form like Smartwaiver or ROLLER.
Yes. When staff edits a user's profile via POS, the waiver is automatically invalidated and must be re-signed with current data. Staff can also explicitly request a new waiver, which revokes the current one and sends a compliance request to the tablet.
Every re-signing creates a new WaiverVersion. All previous versions are preserved and queryable. The complete signature history for a user at a park is always available.
| Feature | wakesys | Smartwaiver | ROLLER |
|---|---|---|---|
| Drawn signature capture | |||
| Full document text preserved per signing | |||
| SHA-256 integrity hash per waiver | (doc ID) | ||
| SHA-256 checksum on signature image | |||
| IP address captured | |||
| Browser user agent captured | |||
| PDF generation per waiver | |||
| Separate signedBy / signedFor in data model | No (form-level) | No (form-level) | |
| Per-user waiver version history | |||
| Automatic revocation on profile change | |||
| Age verification at booking checkout | N/A (no booking) | At waiver level | |
| Age verification at onsite registration | N/A | At waiver level | |
| Real-time POS waiver request | N/A (no POS) | ||
| Waiver expiration with reminders | |||
| SOC 2 Type II certified |
We believe in being transparent about what the system does and doesn't do.
Age verification is not identity verification. There is no ID upload or biometric check — the system relies on truthful input, consistent with how all online booking systems operate.
PDFs are generated asynchronously. The database record with its integrity hash is the authoritative record, not the PDF.