The problem OpenTrigger solves

OpenTrigger: rules on Arkiv, actions on time.* Open infrastructure that acts the moment Arkiv data expires, or at any time you set, and proves it on-chain.

The problem

• Arkiv data expires on its own, but Arkiv sends no event when it does. Its docs: "An entity that reaches its expiration date fires no event."
• An expired entity and a deleted one look identical, so apps can't even tell what happened.
• So every app writes its own private watcher on one server; if it dies, actions silently never happen and nobody can prove it.

Who needs it

• A builder in the Arkiv Discord asked for a native expiry event to build on instead of working around it.
• Arkiv's own Hub lists it under Nobody built this yet (Hub).
• Lapse had to build its own expiry watcher (friction §3).
• Door Ledger logged the same gap (friction #12).

How it works

• Write a rule (eg . when this expires, Telegram me; at 9 am, call my webhook; before it expires, renew it) from the dashboard or one line of SDK.
• Any worker in an open network claims it with a 60 second lease on Arkiv and fires it exactly once.
• The worker writes a receipt to Arkiv; Arkiv records the worker as its creator, so anyone can verify who fired it.

Why it's infrastructure, not one more watcher

• Open network: any number of workers, coordinated only through Arkiv, no fixed primary or backup delay.
• Measured: 100 rules on 2 workers, 0 duplicates, all within 3 blocks (median 1).
• Built to build on: documented schema, SDK on npm, one command, Docker or one click Railway worker.
• Actions: Telegram, signed webhooks, auto renewal, receipts; plus time based rules that replace cron.
• Private: Telegram chat IDs stored encrypted to one worker; no keys or tokens on Arkiv.
• Provable: PROOF.md links real on-chain receipts, and npm run evidence rebuilds it live.

Already in use

• Builders have shipped projects on OpenTrigger and posted them on X
• i have interviewed builders for openn trigger and put the projects in the hub section of our doc

Links

• Dashboard: https://arkiv-triggers-dashboard.vercel.app
• Docs and architecture: https://arkiv-triggers-docs.vercel.app/docs
• Repo: https://github.com/soumyacodes007/arkiv-triggers
• npm: https://www.npmjs.com/package/arkiv-triggers
• Proof: https://github.com/soumyacodes007/arkiv-triggers/blob/main/PROOF.md
• Run a worker: https://railway.com/deploy/ocVIqZ

Challenges I ran into

1. Bare numbers silently match nothing. A number in a range query is read as i32, so it never matches a u64 attribute, and no error is raised. Every number we compare is now wrapped as u64. Details

2. Expiry makes no sound. Arkiv sends no event when data expires, and an expired entity looks the same as a deleted one. Workers schedule deadlines themselves and check the deletion logs, so a deleted target is marked skipped, not fired. Details

3. Same-block claims tie. Queries return no transaction index, so two workers claiming in one block can't tell who was first. The lowest entity key breaks the tie, and the result: 0 duplicates across 100 rules. Details

4. Browsers can't hold an access key. The RPC accepts browser calls, but a key in a web page is public, so the dashboard shares the anonymous budget. It reads a snapshot once, then follows the WebSocket. Details

5. Reads lag writes. A query right after a write can still show the old state, such as a deleted rule still listed or a new target not found. A worker decides only once its own claim is visible, and new targets get a short wait. Details

6. The event feed can't be filtered. Every worker receives every event on the chain, with no attributes. Events are used only as a signal that something changed, followed by targeted queries. Details

7. patchEntity ignored our update. Passing attributes instead of set is silently dropped, then reported as nothing to apply. Our heartbeat was recreated every minute until we found it. Details

8. The events contract address isn't exported. Telling an expiry from a deletion needs the deletion logs, but the SDK doesn't export where they come from. We found the address in a raw log. Details

9. Batch order is undocumented. We send every write in one batch and match new keys by position, but nothing says the order is kept. We tested it and kept a script that checks it. Details

10. Rate limits look like a hang. An exhausted budget returns a 429, but through the SDK the query just hangs. Every query now has a 30 second timeout and a clear error. Details

11. The WebSocket drops every minute or so. Reconnecting the obvious way snowballed into hundreds of connections. The feed now reconnects once per outage, with backoff. Details

12. An exhausted key gives no reset time. Queries fail with no hint of when they will work again. The logs now name the cause, and each production worker gets its own key. Details

13. No way to ask for new rules only. Created since block N can't be filtered, so reloading on every event burned a key's quota fast. Reloads are capped at one per 30 seconds. Details

14. Our public worker froze for hours. A 429 told viem to wait 3,217 seconds, and it obeyed. Clients now fail fast on a 429, and a watchdog restarts a stuck loop. Details

15. Query latency swung from 1 to 30 seconds. On 18 October some reads ended in 504 errors from the gateway. Reads now allow 30 seconds and retry gateway errors. Details

16. A live heartbeat hid a dead loop. The worker kept showing as online while its firing loop was stalled. Health now measures real block progress, not just the heartbeat. Details

Full report with versions and repro scripts: friction.md

Link to a twitter post explaining your project (or post with the video)

https://x.com/Open_Trigger_/status/2111932510422872119?s=20