SetloDocs

Architecture

Events and verification

How Setlo knows something actually happened.

Two paths for events

When the relayer submits a transaction, it reads the receipt and handles the events itself: Credited triggers claimFor for that recipient, Claimed triggers the payout email.

QuickNode Webhooks also deliver every SetloPackages event on both networks to /api/webhooks/quicknode. The route checks QuickNode's HMAC signature, stores the transaction, and runs the same handler. A processed_logs table makes each event run once, whichever path sees it first.

What the screens read

Booking pages read package state, slots, claimable amounts and event history from the contract on every load. Supabase only supplies names, emails and terms text, and the server checks that stored terms text matches the onchain terms hash.