Skip to content
ren
back to the quest log
epic◆ productshipped

Renate

Self-hosted donations across nine rails

A crypto-first donation platform with accountless donors, nine payment rails, live status, encrypted backups, and receive-only defaults.

role
Creator and full-stack engineer
org
Independent
when
2026

What it is

Renate is a self-hosted alternative to hosted creator donation pages. Donors pick an amount, pay on-chain or through Midtrans QRIS, and receive live payment status without creating an account.

Nine adapters share one payment-intent contract across UTXO, EVM, account-based, tagged-address, Solana, TRON, Monero, and QRIS flows. Quotes are frozen per intent and the worker reconciles underpayments, overpayments, late transfers, and chain reorganizations.

The default mode only watches incoming funds. Spending is a separate opt-in with encrypted credentials, reauthentication, atomic daily limits, and an audit trail.

where the effort went

  • Security96
  • Correctness94
  • Integrations92
  • Operations84

the numbers

Payment rails
9
Themes
46
Test files
45
Data services
Postgres only

no queue or Redis

built with

  • Next.js
  • TypeScript
  • PostgreSQL
  • Drizzle
  • Vitest
  • Playwright
  • XChaCha20-Poly1305
  • Docker

delivery record

What I made

I wanted creators to accept direct support without giving a platform custody of funds, donor accounts, or the operational data around each payment.

  • 01

    Accountless public donation flow with receipts and live SSE status

  • 02

    Adapters for eight crypto networks plus Midtrans QRIS

  • 03

    Frozen quotes and an explicit payment-intent state machine

  • 04

    Reorg-aware reconciliation with sticky paid status and review flags

  • 05

    Receive-only wallets by default with separately gated managed mode

  • 06

    Encrypted backup, restore, diagnostics, audit, and HMAC webhook tooling

  • 07

    English and Indonesian interfaces with forty-six themes

Hard problems

The constraints mattered as much as the finished interface.

01field note

One contract for incompatible payment networks

problem
UTXO addresses, EVM transfers, XRP destination tags, Monero subaddresses, and QRIS callbacks expose different notions of finality and identity.
response
I isolated each rail behind a shared adapter and normalized detection into payment intents with explicit confirmation and reconciliation states.
02field note

Safe defaults around spending keys

problem
A donation monitor does not need the authority to move funds, but convenient management features can accidentally widen that boundary.
response
Receive-only is the default. Managed mode requires encrypted spend credentials, fresh reauthentication, atomic daily limits, and complete audit events.

Result: An ordinary installation can verify donations without holding credentials that can spend them.

03field note

Real-money testing without real-money surprises

problem
Mocking blockchain behavior misses confirmations, delayed indexers, and provider-specific response shapes.
response
Every rail has a testnet configuration and an opt-in live matrix that verifies payments against public test networks.

after shipping

What stayed with me

  • Payment state is a reconciliation problem, not a success callback.

  • The safest secret is the one a feature does not require in the first place.