Relay
Owner sign in

🏆 Winner — Most Impactful · H0: Hack the Zero Stack with Vercel and AWS Databases

See what an owner sees.

A read-only tour with sample data — no account needed. Four stops: the vault, what the server actually stores, the release state machine, and the tamper-evident audit trail.

Demo environment with fictional sample data — nothing here is a real secret, and nothing you do on this page writes anywhere.

01 · The vault

Ranked by what matters in a crisis

The importance engine scores every item from metadata alone — it never sees a secret. The top of the list is almost always the primary email: the key that unlocks most password resets.

ItemCategoryImportanceGoes toTrigger
Primary email — jordan@example.comEmail
0.97
Sam (spouse)emergency
Password manager master vaultCredentials
0.94
Sam (spouse)emergency
Checking & bill-pay accountBanking
0.88
Sam (spouse)emergency
Life & home insurance policiesInsurance
0.81
Alex (executor)estate
Letter of instruction to executorInstructions
0.78
Alex (executor)estate
Mortgage & deed documentsDocuments
0.66
Alex (executor)estate
Utilities & household subscriptionsSubscriptions
0.41
Sam (spouse)emergency
Family photo archive location + keyDocuments
0.35
Sam (spouse)estate
02 · Zero-knowledge storage

This is everything the server has

Encryption happens in the browser: a per-item AES-GCM-256 data key encrypts the secret, then AWS KMS wraps that key. The row below is the complete server-side record for “Primary email — jordan@example.com” — ciphertext is all there is to steal.

algorithm
AES-GCM-256 (per-item data key, generated in the browser)
ciphertext
q9XoZ0m4vGk7T2cRt8yWfBqUj3nHsA1dLxPvC6eKZrM5wYhN0iJgD4bTQXm8SoEa7Vfl2uHcRpKAyG9jNtW1zM6dSBoLqIxUvhPrEnT3JgYwCk5m0e…
wrapped_data_key
AQIDAHhwZk1Nb2NrS2V5Rm9yRGVtb1RvdXJPbmx5AAAAfjB8BgkqhkiG9w0BBwagbzBtAgEAMGgGCSqGSIb3DQEHATAeBglghkgBZQMEAS4wEQQM…
iv
5c2Fw1nJ9xTQb0Vd
kms_key
alias/relay-h0-mvp
stored columns: ciphertext · wrapped_data_key · iv · kms_key_id · metadata plaintext is not a column
03 · The release state machine

One verified emergency, step by step

Every transition is a strongly-consistent compare-and-set on Aurora DSQL — shown under each step. Owner, verifiers, and the scheduler can all act at once and the machine still advances exactly once. If retries ever exhaust, the row lands back in ARMED.

  1. ARMED2026-06-27T14:02:11Z

    Default-safe. Nothing is accessible.

    The owner checks in on schedule; recipients hold links that resolve to nothing. ARMED is the state the system falls back to whenever anything is uncertain — including when concurrent writes exhaust their retries.

    state = 'armed', version = 3
  2. PENDING2026-06-27T14:02:36Z

    An emergency trigger fires.

    A missed check-in (or a manual emergency) advances the machine. The transition is a strongly-consistent compare-and-set on Aurora DSQL — it succeeds exactly once, no matter how many actors race.

    UPDATE release_state SET state='pending', version=version+1 WHERE id=$1 AND state='armed' AND version=$2
  3. GRACE2026-06-27T14:02:47Z

    Grace window opens; verifiers are asked.

    The owner is notified and can cancel with one check-in. Meanwhile N-of-M trusted verifiers independently confirm the emergency is real. No single person — not even a verifier — can force a release alone.

    UPDATE release_state SET state='grace', grace_ends_at=$3 WHERE id=$1 AND state='pending' AND version=$2
  4. RELEASED2026-06-27T14:03:12Z

    Scoped access opens — and stays reversible.

    Recipients can now decrypt only the items they were granted. When the owner recovers and checks in, the version bump instantly invalidates every recipient token and the vault re-ARMs. Estate releases, by contrast, are permanent by design.

    UPDATE release_state SET state='released', released_at=now() WHERE id=$1 AND state='grace' AND version=$2
04 · The audit trail

Append-only, hash-chained, tamper-evident

✓ chain intact

Each entry’s hash is SHA-256 of the previous hash plus the entry itself, anchored at a genesis of 64 zeros. This chain isn’t an illustration — it’s computed and verified by the same code that runs in production. Edit any line and the chip above flips red.

#1
owner.signinowner
TOTP sign-in from a recognized device
0000000000…000000
29cc7a0707…4748b4
#2
vault.item_createdowner
Item "Primary email" stored (ciphertext + wrapped key only)
29cc7a0707…4748b4
183bb6fd81…654a6e
#3
rules.grantedowner
Sam granted "Primary email" under the emergency trigger
183bb6fd81…654a6e
dfa666ec24…dfb157
#4
trigger.armedowner
Emergency trigger armed — 2 verifiers, 1 confirmation required
dfa666ec24…dfb157
589f5a8bd0…499758
#5
release.pendingsystem
Missed check-in advanced ARMED → PENDING (CAS, version 3 → 4)
589f5a8bd0…499758
47625e01ee…4c8026
#6
release.grace_openedsystem
Grace window opened; owner and verifiers notified
47625e01ee…4c8026
f30a723be3…99908e
#7
verifier.confirmedverifier:alex
Verifier confirmation 1 of 1 received
f30a723be3…99908e
75493a9829…93c173
#8
release.releasedsystem
GRACE → RELEASED (CAS); recipient tokens now resolve
75493a9829…93c173
81efd951e9…c7f57d
#9
access.decryptedrecipient:sam
Recipient unwrapped "Primary email" via KMS (scoped token)
81efd951e9…c7f57d
3010575024…c68f1f
#10
release.rearmedowner
Owner check-in re-armed the vault; version bump revoked all recipient tokens
3010575024…c68f1f
1d75136000…28f396

Caring for an aging parent right now?

Everything above was built for one moment in particular: the call comes, and suddenly you need their bank, their insurance portal, their email — and you need that access to end when the crisis does.

See Relay for caregivers →

Want the full story?

Two minutes of video shows the live system doing everything above — including a multi-region failover.