Event Sync
A hosted Hiro Chainhook watches the thesislock contract and posts every anchor event to ThesisLock, which mirrors it into a Supabase table in real time, instead of polling the Hiro API for fresh anchors. The chain stays the source of truth; the table is a fast, queryable index.
How it works
- The contract emits one print event,
anchor-created, on everyanchor-documentcall. - A Chainhook predicate (
print_eventscope,contains: "anchor-created") matches those events from the deploy block onward and POSTs them to/api/chainhooks. - The endpoint checks a bearer token, then processes the reorg-aware payload: rollbacks first, then applies.
- Applies upsert each event keyed on its transaction id, so redelivery is idempotent. Rollbacks mark the matching rows
reverted.
What gets stored
The thesis_locks table mirrors the event tuple. Columns are named from the actual contract fields:
| Column | Source |
|---|---|
tx_id | Transaction id (primary key) |
block_height | Stacks block of the event |
sender | Transaction sender |
hash | Document hash |
anchored_by | Anchoring principal |
stacks_block | stacks-block from the event |
burn_block | burn-block from the event |
label | Optional ASCII label |
event | Full decoded tuple (jsonb) |
reverted | True after a rollback |
Row-level security allows public reads; only the server-side service role writes.
Configuration
Three server-only environment variables (never NEXT_PUBLIC):
CHAINHOOK_AUTH_TOKENis the shared secret the chainhook presents, as a bearer token or a?token=query parameter.SUPABASE_URLis the Supabase project URL.SUPABASE_SERVICE_ROLE_KEYis the service-role key used for server writes.
Full setup, the table SQL, and the Hiro Platform registration steps live in chainhooks/README.md in the repository.
Reads
The app's feed, stats, profile, search, and verify reads query this index through a browser-safe anon key (the public-read RLS policy) instead of polling the Hiro API on every request. If the index is unreachable, or a just-anchored hash has not been indexed yet, those reads fall back to the Hiro API, so verification never returns a false negative. Batch, registry, group, and proof anchors still come from Hiro. These reads use NEXT_PUBLIC_SUPABASE_URL and NEXT_PUBLIC_SUPABASE_ANON_KEY, distinct from the server-only write vars above.