Threshold Vault presents

A switch we cannot stop.

Threshold Vault does not store your switch, your message, or your recipients. The switch runs on infrastructure you own, and the code that runs it is open.

i · Architecture

Where the switch lives.

Three columns. What runs on your own Cloudflare. The single billing row on our side. And what never reaches us under any circumstance.

Your Cloudflare
  • durable_object_timer
  • stage_machine (armed → warning → grace → triggered)
  • alarm_scheduler
  • check_in_endpoint
  • recipient_send_path
  • control_page
Our side
  • billing_record (Stripe + our DB, active tier only)
  • monitor_registry (Monitoring tier only)
  •   · switch_url
  •   · read_only_monitor_token
  •   · owner_email, last_seen
  • nothing_else
Never transmitted
sealed_message_bodyrecipient_identities (with aliases)check_in_tokenowner_personal_data_after_retention
ii · Core guarantees

What we commit to.

Eight structural properties. Each is enforced by how the system is built, not by a promise.

Race-safe firing

The firing path runs inside a single-writer critical section on a Durable Object. Twelve concurrent triggers produce one send per recipient, never two, by structural guarantee of the runtime.

Structural billing isolation

Our billing service holds no handle to any switch. A lapsed or cancelled subscription writes one row in our database and can do nothing else. The switch runs on the customer's own infrastructure.

Read-only monitoring

Monitoring subscribers give us a token that authorizes reading /status only. The token cannot reset, fire, or reconfigure the switch. We see liveness, never internals.

Partial-delivery alerting

If a trigger fails to reach a recipient after the retry window, the owner gets a separate alert naming the unreachable recipient. Silent failure on inheritance delivery is structurally prevented.

Zero retention after fulfillment

Customer emails are removed from our records and from Stripe once the purchase is fulfilled. Immediately for Kit, after the 30-day support window for Managed, on cancellation for Monitoring.

Signed releases

Every release is signed with minisign. The public key is in the repository and on this page. A verify command and the expected output are provided below.

Open-source code

Every line of the switch is on GitHub under MIT. Cloneable, auditable, runnable on your own Cloudflare. The same code that ships in the paid kit ships free in the open repo.

Self-hosted by design

The switch runs on your own Cloudflare Workers free tier. If we vanish tomorrow, every deployed switch keeps running and firing on schedule. We are not a custodian. We are a code source.

iii · Mechanics

How the switch fires.

A four-stage machine driven by a Durable Object alarm. A check-in resets it. No state-changing path is reachable from outside the owner.

Armed
The clock is running. All quiet.
Advances when now > deadline minus warning lead.
Warning
Emails you a reminder that the deadline is near.
Advances when now > deadline.
Grace
Emails you a final notice and waits.
Advances when now > deadline + grace.
Triggered
Sends your message to your recipients, once.
Terminal. A check-in re-arms it.
# single-writer critical section on the Durable Object on alarm():   state = load()   # concurrent alarms serialize here; one runs at a time   if now > deadline + grace and not state.fired:     state.fired = true # set BEFORE send     save(state) # commit the flag     send_to_recipients() # exactly once   on checkin(token):   require valid token # owner only   state.deadline = now + interval   state.fired = false

The Durable Object's single-writer guarantee makes concurrent fires structurally impossible. Twelve concurrent alarm invocations produce one send per recipient, never more.

iv · Threat model

What we protect, what we don't.

The switch solves one problem: delivering instructions when you cannot. It is not general device security. We are explicit about both sides.

Protected against

Failures the switch design absorbs.
  • Forgetting or being unable to check in for any reason.
  • Losing the device used to check in.
  • A lapsed Monitoring subscription (the switch is unaffected).
  • A compromised Monitor service (the token is read-only).
  • Our domain disappearing.
  • A single recipient's email bouncing.

Not protected against

Risks outside the switch's guarantee.
  • Malware on the device used to check in.
  • A compromised Cloudflare account on your side.
  • An attacker holding both the check-in token and the means to use it.
  • The recipient's email account being compromised after delivery.
  • Your own intentional or accidental check-in from anywhere.
  • DNS misconfiguration on your sending domain.
v · Best practices

Eight rules for real deployments.

The runtime protects what the procedure preserves. These rules close the gaps the code cannot.

  • Test the full fire path with a dummy message before going live.
  • Use a sending domain with DKIM, SPF, and DMARC configured.
  • Use recipient aliases (SimpleLogin or addy.io) if you want recipient identities hidden from us even during send.
  • Rotate the check-in token every 6 to 12 months, or sooner if a device used for check-in is lost or compromised.
  • Subscribe to Monitoring if you want a second opinion on whether your switch is alive.
  • Keep a written record of switch URL, check-in token location, and recipient list separate from your daily devices.
  • Tell at least one trusted person that the switch exists, what it does, and how to contact us if something looks wrong.
  • Verify the signed release before deploying.
vi · Open source

Trust the code, not the company.

The product is the source. This domain, our copy, our brand are auxiliary to the runtime. If we vanish tomorrow, every deployed switch keeps firing.

The repository & its guarantees.

Five artifacts published alongside the code. Each is independently verifiable.

Repositorygithub.com/threshold-vault/dm-switchPublic · MIT
LicenseMITPermissive · forkable
Security policySECURITY.mdDisclosure · 90 days
Build instructionsReproducibleSHA-256 verified
Signed releasesminisignPublic key below

Run it yourself · 7 steps

~ 5 minutes
  • 01$ git clone github.com/threshold-vault/dm-switch
  • 02$ cd dm-switch
  • 03$ minisign -Vm shards-switch.zip -P <key below>
  • 04$ unzip shards-switch.zip
  • 05$ cd shards-switch && npm install
  • 06$ wrangler login
  • 07$ wrangler deploy
minisign public keyRWSNAOOg1ay6fnyrKrzxbHW7Dwc4/PKdP60ULOJAFsVIzFXDiZNSiEPyVerify every release against this key
vii · FAQ

Questions we get.

No. The switch runs on your own Cloudflare account. We hold no token that can reset, reconfigure, or fire it, and no path from our billing system reaches it. We could not stop it if we tried.
Nothing changes. The switch is MIT-licensed code on your infrastructure. Every deployed switch keeps counting down and firing on schedule. You can re-read, rebuild, and redeploy from the open repository at any time.
No. The message body and recipient list live in your Worker configuration on your account. They are never transmitted to us. Use recipient aliases if you want even the addresses hidden from us during send.
No. Monitoring is a read-only liveness check layered on top. A lapse writes one row in our database and stops the checking. The switch is untouched and keeps running.
Liveness only. The monitor token authorizes reading /status, which returns the current stage and deadline. It cannot check in, change settings, or fire the switch.
Yes. The full source is on GitHub under MIT. Clone it, verify the signature, and deploy to your own Cloudflare free tier. The paid Kit adds a guided, illustrated setup; the code is identical.
Cancel from your account or by replying to any monitoring email. Cancelling stops the liveness checks and nothing else. Your switch keeps running exactly as before.
If a trigger fails to reach a recipient after the retry window, you get a separate alert naming the unreachable recipient. Configure DKIM, SPF, and DMARC on your sending domain to keep deliverability high.
Yes. Update the token secret on your Worker. We recommend rotating it every 6 to 12 months, or sooner if a check-in device is lost.
No. The switch delivers a message you wrote. It holds no funds, no keys, and no assets. It is a notification mechanism, not a custodian or a financial service.
Begin

Ready to leave instructions that act on their own?