Protocols integrated
A monetization layer that sits between protocols and their users.
The brief was to design and prototype a monetization layer that protocols could install in a single afternoon and operate without writing custom integration code.

Context, constraint, and the part that mattered.
We treated it as a product question first and an engineering question second: what is the smallest decision a protocol team has to make to monetize their existing audience, and how do we make that decision the only one they encounter on the way in? The result is a thin admin surface, a single SDK call, and a payouts pipeline that the protocols themselves never have to look at. The platform now powers monetization for nine production protocols and onboards new ones in a single business day.
What we did, in the order we did it.
- 01
A single decision on the way in
Onboarding asks one question — what are you monetizing — and infers everything else from the protocol's existing event stream. The admin surface is intentionally narrow, with no exposed dials that a partner team would have to make sense of in their first session.
- 02
A payouts pipeline that hides itself
Partners never see the payouts pipeline. They see a balance, a payout date, and a destination. The reconciliation, the on-chain settlement, and the tax reporting are pushed behind a stable interface that the partner team is never asked to operate.
- 03
An SDK that is a single call
The integration is one SDK call placed inside the protocol's existing event stream. No data model changes, no schema migrations, no new infrastructure. Partners ship the integration in an afternoon and never touch it again.
A small spread from the engagement.









The numbers we agreed to ship against.
Median onboarding time
Self-serve activations
Have a project that looks like this?
Send a short brief — we'll reply with concrete next steps. New engagements are limited each quarter.
