Basin

Demo

About

Basin is a safer way for companies to pay known people and organizations onchain. Today, approving a payee usually means storing a wallet address. That creates a fragile link between identity and infrastructure. If the recipient changes wallets, rotates keys, or moves funds elsewhere, the payer must update its records. Worse, a substituted address in an invoice or payment workflow can redirect money while still looking like a normal crypto transfer. Basin separates **who is approved** from **where they currently receive money**. A company creates an approved payment relationship with a recipient through a Basin identity such as `maya.basin.eth`. The payer approves Maya once. Maya controls her current receiving account underneath that identity. She can later change that account without asking every payer to update a wallet address. Payments do not simply resolve an ENS name and transfer funds. Basin checks the approved payer–recipient relationship, the current authorized receiving state, and the permissions required to execute the payment. A normal operator cannot silently replace the recipient or bypass the relationship with a different destination. This creates a simple rule: **The company approves who. The recipient controls where.** Basin is designed for real payment operations where the same counterparties are paid repeatedly: contractors, auditors, suppliers, contributors, and other trusted recipients. The result is a payment relationship that can survive wallet changes while still giving the payer control over who is authorized. If trust ends, the payer can revoke the relationship and future Basin payments are rejected. Basin turns an onchain address book into something stronger: a durable, enforceable payment relationship between two parties.

How it's made

Basin is built as a small end-to-end payment system around **ENSv2** and **Privy**. ENSv2 provides the onchain identity and authorization layer. Basin creates names under `.basin.eth` and uses ENSv2 permissioned registry, permissioned resolver, and enhanced access-control primitives to separate control between the payer and recipient. The payer controls whether a payment relationship is trusted. The recipient controls the receiving information attached to their Basin identity. The permission model is designed so the payer cannot silently redirect the recipient, while the recipient can legitimately rotate receiving infrastructure without requiring payer-side updates. This is different from using ENS as a simple readable alias for one wallet. Basin treats the ENS state as part of an ongoing payment relationship with explicit authority boundaries and lifecycle rules. Privy provides the execution and wallet-control layer. Basin uses Privy-managed infrastructure and delegated authorization so routine payment operators can perform the actions they are allowed to perform without receiving unrestricted control of company funds. A payment must pass Basin's relationship checks before the authorized execution path can proceed. This lets us demonstrate an important failure case: an external payment attempt using substituted wallet details can be denied even when it comes from the normal operational environment. The application is built with **Next.js and TypeScript** in a **pnpm workspace**, with the frontend and backend kept in the same application through Next.js App Router and API routes. Basin also includes a small SDK so another application can create and submit Basin payments without depending on the Basin UI. For the ETHOnline build, settlement runs on **Ethereum Sepolia**, while the protocol design keeps the payment relationship separate from any single chain. One of the more unusual parts of the implementation is that changing a recipient's wallet is treated as a normal lifecycle event rather than a new contact. We can pay the same approved identity, change the receiving account, pay it again successfully, revoke that relationship, and then show a previously prepared payment fail. That sequence is the core technical idea behind Basin: **identity remains stable while the infrastructure underneath it can change safely.**