Shortly
In short
Neti designed and built the stablecoin infrastructure behind a payments company's own token. The issuance platform decides who is allowed to create tokens, how much, against what reserves, and who has to agree before any of it happens. At its centre is a proof of reserve model that constrains minting to the fiat actually held in backing, and a multisig gate on every change in supply.
- CASP onboarding with KYC: only licensed entities are registered as counterparties allowed to mint, buy and burn.
- 1:1 proof of reserve: the platform cannot issue more tokens than the fiat held in the backing account, and no oracle was needed to enforce it.
- Multisig-governed issuance: minting and burning require N independent signatures, with platform administrators among the signers.
- Treasury dashboards: how much was minted, how much burned, who bought what, and what the reserve position is.
- Supervisory reconciliation: the reserve position and the full issuance history are recorded, so a supervisor can check issued supply against fiat held in backing
Client: white-label. a company that operates its own payment systems. Neti built three things for it: a self-custody mobile wallet, this issuance platform for the client's own stablecoin, and a research track on private transfers of that token.
Why a payments company builds its own stablecoin
Most products that move digital dollars use a stablecoin somebody else issues. That is the cheap answer and usually the right one. This client wanted the other thing, for two reasons.
Control of circulation. Their wallet product settles payments between merchants and end users. When the unit of account is a token somebody else controls, the issuer's decisions become your product roadmap: supported chains, freezes, redemption terms and fee changes.
A private settlement path. The same client wanted shielded transfers of that token, with sender balance and identity not visible on-chain. Controlling the token made that easier to pursue. It became a separate research track and is a story of its own.
Neither reason is about technology. Both are about who decides.
Why the hard part of issuing a stablecoin is not the token contract
Minting a token is four lines of Solidity. That part is not the project.
The project is everything that has to be true before those four lines are allowed to execute, because a stablecoin issuance platform is a money-creation machine. One that gets it wrong does not produce a bug. It produces unbacked currency.
Three problems sit underneath.
The reserve has to constrain issuance, not merely accompany it. The reserve position cannot be a number on a dashboard somebody updates later. It has to be what the platform's issuance flow checks, and refuses to exceed.
Issuance cannot be a single decision. On a blockchain, one wallet signing one transaction is enough to create tokens. One compromised key, one careless administrator, one insider, and the reserve ratio is fiction.
Someone outside the company has to be able to check. A supervisor's question is not "does your architecture look sound". It is "you reported this much in reserve and issued this much in tokens; show me". A platform that cannot answer that on demand is not really a regulated issuance platform, whatever the documentation says.
The difficulty here belongs to the problem, not to any company facing it. It is the reason most teams sensibly decide not to issue their own token, and the reason the ones who do need the governance layer designed before the contract is written.
The stablecoin infrastructure Neti built: permissions, proof of reserve and multisig governance
Who is allowed to hold and move the token
The platform does not deal with retail users. Its counterparties are licensed crypto-asset service providers, registered in the system through an onboarding flow that includes KYC.
That constraint shapes everything downstream. A registered CASP can mint, purchase and burn. Nobody else can do anything. The permission model is not a feature bolted onto the product. It is the product's outer boundary, and it is drawn by who is licensed to handle the money rather than by who wants access.
Minting is the way in. A CASP places fiat in the dedicated reserve account and receives the equivalent in tokens. Burning is the way out. Tokens are sent to the zero address, where nobody can ever retrieve them, and the equivalent fiat is released from the reserve.
Proof of reserve: the finding that removed an oracle from the design
Proof of reserve works on a spectrum, and picking the right point on it was one of the most consequential decisions in the project.
At one end sits the declarative model: the platform records the fiat balance held in the dedicated reserve account, and issuance is checked against that recorded figure. At the other end sit oracle-based designs: a Chainlink-style bridge that reads the vault and publishes the balance on-chain, so the smart contract itself enforces the ceiling without anyone asserting anything. In between sits periodic attestation, where the reserve position is uploaded as JSON files stating what the account holds.
The engineering instinct is to reach for the oracle. It is the most rigorous option and the most impressive to describe.
Neti's finding, after working through the regulatory requirement rather than the technical one, was that a declarative model could meet it, provided the reserve position and the full issuance history are recorded so that the reconciliation can be performed: this much reserve, this much issued, do they agree. The client did not need to take on an oracle dependency, its failure modes and its operating cost.
That is the kind of decision that only comes from understanding both sides. Getting it wrong in the cautious direction is not free. It buys a permanent integration, a new trust assumption and a new thing that can break at three in the morning, in exchange for a property the regulation did not ask for.
Deciding how your stablecoin's reserve should be proven? Talk to Neti about the architecture before you commit to an oracle.
Multisig as a control on money creation
Issuance and burning are protected by multisig: a set of wallets defined in the platform, of which N must sign before a mint or burn transaction reaches the chain. Platform administrators are among the signers.
The mechanism is old. The design decision is where it is placed: not on the treasury account as an afterthought, but on the act of creating supply, so that the reserve check and the human approval are the same gate. A single wallet can no longer expand the money supply, and every expansion carries a record of which parties consented to it.
This came with a real cost, and it is worth naming: multisig has poor ergonomics. Each signer has to know a signature is pending and act on it, and a control that people find painful is a control people look for ways around. Neti's smart-contract developer proposed an alternative signing flow to cut that friction.
Where the tokens go after they are created
Minted tokens do not go straight to the buyer. They land first on the client's technical wallet, and are distributed from there to the CASPs that purchased them.
That indirection is deliberate. It separates the act of creating supply from the act of allocating it, which means the two can be authorised, recorded and audited independently. It also gives operations a single place to hold, verify and, if necessary, stop a distribution before it reaches a counterparty.
The operational view
Treasury operators work from dashboards covering:
- the current reserve position against the fiat account
- total minted and total burned
- per-CASP figures: how much each entity minted, purchased and burned
- the issuance and redemption history behind each of those numbers
This is treasury management, not FinOps. The distinction matters. The platform does not process payments or move customer funds through payment flows. It governs supply: what exists, against what backing, held by whom.
How it was built
The engagement ran in three phases, and the shape of it is as much a part of the work as the architecture.
Phase 1: requirements, built rather than received. The client arrived with a business goal, not a specification. Neti ran a business analysis of how stablecoin issuance platforms actually work, using Circle Mint as the reference system the client had pointed to. Circle Mint is the issuance platform of one of the largest stablecoin issuers in the world.
The point of that study was not to copy it. It was to map the full range of features such a system can have, so the conversation with the client could be about deliberate inclusion and exclusion rather than about what nobody had thought of yet. Neti then combined that map with a series of micro-workshops with the client and its own security requirements, multisig among them, into a requirements list, and put that list back in front of the client for validation.
Phase 2: prototype before code. Mockups of the platform were built and walked through with the client feature by feature. Nothing moved to implementation until the shape had been accepted.
Phase 3: development with a weekly demo. Implementation ran with a demo to the client every week: validate, correct, continue. The client's role throughout was to confirm direction against its own business needs. Neti owned the full delivery cycle: technical requirements, implementation, DevOps, testing and handover.
One build decision is worth recording. Blockchain transactions cost gas, and someone has to pay it. The platform uses a relayer that submits transactions and covers the fee on the signer's behalf, so a treasury operator never has to hold a native token in order to approve a mint. Neti evaluated writing one and instead used the relayer already running in the mobile wallet Neti had built for the same client. That left one piece of infrastructure for the client's team to run rather than two.
Delivery stopped at around 80% of the defined scope. Neti's parallel project for the same client wrapped at the same time, and both were handed over together rather than continued.
What this work required
The lessons from this project are specific, and they are the reason it is worth reading if you are considering the same build.
Requirements were the hard part, not the chain. The largest single challenge was not cryptographic or architectural. It was extracting from the client what the platform actually needed to do. That required frequent conversations and, more importantly, asking the questions that surface knowledge the client holds tacitly and has never had to write down.
Two specialisms had to be in the room. One analytical: discovering and structuring functional requirements, and studying how comparable systems solve the same problem. One security-focused: knowing how transactions of this class are protected, which existing mechanisms improve blockchain UX rather than degrading it, and where multisig can be replaced with something less punishing.
The regulatory answer and the technical answer were not the same answer. The proof of reserve finding is the clearest example. Teams that only ask the technical question over-engineer this layer.
Facing a similar decision?
This case is relevant if you are:
- Evaluating whether to issue your own stablecoin rather than use a public one
- Working out what proof of reserve has to mean for your regulator, not just for your architecture
- Designing governance for an operation that creates or destroys supply
- Building for licensed counterparties rather than retail users
- Trying to keep a token's control surface inside your own company
Related case studies: Damisa: who owns the funds at every hop of a cross-border transfer · How Neti helped BOHM design asset tokenization platform architecture
About Neti
Neti is a stablecoin development company building financial infrastructure for fintechs, payment institutions and digital-asset teams: stablecoin issuance and treasury systems, proof of reserve and governance design, self-custody architecture, payment orchestration, ledger and reconciliation design, and multi-chain operations. We work architecture-first. Before features, we define who is allowed to do what, against what backing, and who has to agree.
Book a 45-minute architecture review. We'll map your issuance model, reserve requirements, governance surface and supervisory obligations, and tell you what needs deciding before any contract is written.
