Use case
Stablecoin treasury and B2B settlement
An approval, a rail, and a reconciliation. A stablecoin can be the rail. It is not, by itself, the treasury policy or the accounting system.
A business wants to pay suppliers in a unit that aims to track a currency, with limits, an audit trail, and a way for finance to close the day.
When shared machinery earns a place
More than one rail, more than one legal entity, or a need to settle outside a single bank's cut-off can justify an orchestration layer. Sometimes one of the rails is a stablecoin.
When it does not
A single company paying from its own bank account does not need a chain. An algorithmic peg that depends on a sister token is not a template. Terra, in this library, is a failure case.
Conventional-first
ERP approval, bank payment, statement import.
Cut-offs and correspondent banks. No new key-management risk.
Hybrid
Approval policy, wallet limits, Interledger-style orchestration where ledgers differ, reconciliation into the ledger.
You now have issuer risk, wallet risk, and a finance mapping.
On-chain-native
Wallet policy, event indexer, issuer or vault design you can name. Not an uncollateralised sister-token peg.
Reserve, redemption, and key compromise are existential.
Patterns
Components
- RafikiGreen — compatible use if you keep the notices
- viemGreen — compatible use if you keep the notices
- wagmiGreen — compatible use if you keep the notices
- PonderGreen — compatible use if you keep the notices
- Safe Smart AccountAmber — conditions, and a legal review before you copy it in
Read before you build
Questions a person still has to answer
- Who issues the unit, and what is the reserve?
- Who can add a payee?
- What is the reconciliation key into the ERP?
- What is the legal moment of settlement?