kinlock-app
The Next.js web app: payee requests, the sender flow, claim and decline, and receipt verification. Everywhere money moves, it reads straight from the chain, never from the indexer's cache.
Pages
/- Landing page and plain-language explainer
/send- Sender flow: pick a verified payee, set a schedule, review preflight checks, create a lock
/request- A payee builds a link that pre-fills the sender's form. The link carries no authority of its own
/claim/[id]- The payee's claim page: checks the reference against
ref_hash, then releases /locks/[id]- Sender's view of a lock, with refund shown only when the contract actually allows it
/payee,/attester- Dashboard and onboarding-checklist tooling
/r/[txHash]/[eventIndex],/verify- Receipt page and verifier: "Payment to verified payee," nothing stronger
Rules that don't bend
- Claim, release, refund, decline, and approve pages read chain state, not the indexer.
- The claim-link fragment (
#r=…&s=…) never reaches a server, log, analytics tool, or third party./claim/*loads no third-party scripts at all. - Every asset is shown as code and issuer. Never by code alone.
- Local-currency amounts are always labeled indicative, with a USD-only fallback when there's no reliable rate. Never invented, never guaranteed.
- Every user-visible string lives in a message file; formatting goes through
Intl.
Stack
Next.js (App Router), TypeScript, Tailwind. Wallet access goes through a wallet-kit abstraction so wallets stay swappable. The app talks to the contract only through kinlock-sdk, never with ad hoc contract calls.