Stablecoin Studio
Connect issuance to the reserve and redemption process.
Stablecoin Studio is Hedera's open-source toolkit for issuing and running fiat-referenced tokens. Each stablecoin is a Hedera Token Service token governed by smart contracts that hold its supply, compliance and role permissions, operated through an SDK, a command-line tool, a web application and a back end for multi-signature approvals. ColdAI designs the treasury, signing and reconciliation workflows around it, so every change in supply matches a controlled movement of reserve money.
The opportunity
Start with a decision
worth improving.
A proposed token needs issuance and redemption to correspond to controlled treasury events. A token balance alone cannot show whether reserves exist or a holder can redeem.
From possibility to a working system
Follow the flow.
Three connected decisions. One considered architecture.
Conceptual flow, not a live system or measured result.
Define the operating model
Map issuer, reserve, custody and redemption responsibilities. Specify which records authorize a supply change and which actions require multiple approvals or independent review.
Control supply actions
Integrate the selected tooling with approved treasury workflows. Test mint, transfer and redemption-related actions with clear signing authority and exception handling.
Reconcile and report
Compare supply with the appropriate authoritative records and preserve an audit trail. Design reporting and incident procedures around the actual reserve and redemption arrangements.
The work, made concrete
What we can build
with your team.
We agree scope, dependencies and acceptance criteria before delivery. Your project can start with an assessment, a pilot or an integration into an existing system.
Technical issuance and treasury workflow design
Clarify the system boundary, the responsible owners and the decisions the architecture needs to support.
Supply-control and integration implementation
Turn the agreed design into reviewable work, evaluated against representative inputs and explicit success criteria.
Reconciliation and operational checks
Make the next step operable: document responsibilities, known limitations and the path from pilot to ongoing use.
Explore the practice
Further capabilities
and implementation detail.
What Stablecoin Studio is
Stablecoin Studio is Hedera's open-source SDK and administrative platform for issuing and operating fiat-backed stablecoins on HTS. It packages the operational primitives a regulated issuer needs: KYC, freeze, mint, burn, supply controls, multi-signature treasury operations, role-based access, and proof-of-reserve hooks — all on top of Hedera's predictable fees and aBFT finality.
ColdAI's Stablecoin Studio service
Stablecoin design
Reserve model, redemption mechanics, fee policy, and regulatory positioning — designed in collaboration with your legal counsel and reserve banking partner.
Treasury & key management
Multi-sig treasury operations, HSM-backed key custody, role-based admin controls, and disaster-recovery procedures.
Proof-of-reserve & reporting
Integration with reserve attestation providers and on-chain attestation publishing via HCS for transparent reporting.
Distribution & integrations
Wallet, exchange, custodian, and core-banking integrations to make the stablecoin usable from day one.
Who we deliver Stablecoin Studio for
- Banks and licensed e-money institutions
- Payments providers and PSPs
- Tokenised-deposit programmes
- Public-sector and central-bank pilots
- Cross-border settlement consortia
Launch a regulated stablecoin on Hedera
Engage ColdAI to design, build, and operate a branded fiat-backed stablecoin on Hedera using Stablecoin Studio.
Contact our Hedera teamIn depth
Go deeper: regulation and instrument choice
Two guides for the decisions that come before any build: which rules apply to your token, and whether a bank should issue a stablecoin or tokenise its deposits.
- 01Regulation explainerStablecoin rules: MiCA, the GENIUS Act and other regimesWhich licence a fiat-backed stablecoin issuer needs under MiCA, the US GENIUS Act and regimes in the UK, Hong Kong and Singapore, and what software can cover.
- 02Buyer's guideTokenised deposits vs stablecoins: a guide for banksA bank's guide to choosing between tokenised deposits and a fully reserved stablecoin: legal claim, holder protection, balance sheet and transferability.
What a Stablecoin Studio deployment is made of
Holders see an ordinary HTS token. Behind it, contracts decide who may change supply or restrict an account12.
- Web app, CLI and SDK
Operators issue and administer the token from a React web application, a command-line tool or a TypeScript SDK, signing with wallets such as HashPack or MetaMask or through a custodial option.
- Multi-signature back end
Holds a pending transaction while the signatures required by a Hedera key list or threshold key are collected.
- Factory and resolver
The factory deploys each stablecoin's management contracts; a business logic resolver and diamond-style proxy route calls to versioned logic.
- Control facets
Cash-in, burn, wipe, freeze, KYC, pause, rescue, reserve, roles and hold logic, each guarded by a role.
- HTS token
Balances and transfers live in Hedera Token Service, so holders transact without calling the contracts.
- Reserve data feed
A contract exposing a Chainlink-style aggregator interface reports the reserve figure that minting is checked against.
Stablecoin Studio roles and the treasury control each one needs
The Studio separates powers into roles1. The right-hand column is the operating control we would design around each, not a feature of the software.
| Role | What it allows | Control to build around it |
|---|---|---|
| Admin | Grants and revokes the other roles | Held by a threshold key across separate people; every grant logged with its approval |
| Cash-in | Mints new tokens, optionally within a supply allowance | Minting only against a confirmed, reconciled credit to the reserve account; allowance sized to expected daily flow |
| Burn | Destroys tokens held by the treasury | Burn tied to a redemption request, with fiat payout released only after the burn is final |
| Freeze and KYC | Stops an account from transacting, or grants and revokes its KYC flag | Driven by the compliance system of record, with a reason code for each change |
| Wipe | Removes tokens from a specific account | Used only under a legal order or confirmed fraud decision, approved by two people |
| Pause | Halts all token transfers | Incident playbook defining who may pause, how holders are told and how service resumes |
| Rescue and delete | Recovers assets held by the token's contracts, or retires the token | Board-level approval for deletion; rescue limited to documented operational errors |
One unit's journey from cash-in to redemption
The technical lifecycle we build, with the reconciliation point at each step.
Receive and confirm fiat
A customer's payment lands in the segregated reserve account. Treasury confirms it in the banking system and records the request against the customer's verified identity.
Authorise the mint
The cash-in request goes to the signers required by the treasury policy. The contract checks the request against the cash-in allowance and the reserve feed before supply can increase.
Deliver to a KYC-granted account
Tokens move to the customer's Hedera account, which must already carry the KYC flag and must not be frozen.
Circulate under compliance controls
Holders transfer between accounts that pass the token's KYC and freeze checks. Compliance monitors transfers through mirror node data and acts through the freeze, KYC or wipe roles when required.
Accept a redemption
The holder returns tokens to the treasury account and submits a redemption request with payment details matching their verified identity.
Burn, then pay out
Burn signers destroy the returned tokens. Once the burn has reached consensus, treasury releases fiat from the reserve account.
Reconcile supply, reserve and ledger
At least daily, compare token supply on the network, the reserve balance at the bank and the issuer's internal ledger. Any difference is a break to investigate before the next mint.
What the on-chain reserve check proves, and what it cannot
Stablecoin Studio can link a token to a reserve contract and refuse to mint beyond the reserve it reports2. That is a useful guard: an operator with the cash-in role cannot push supply above the published reserve figure, even by mistake.
The guard is only as good as the figure. A reserve feed reports what its updater writes to it, whether that is a person, a bank integration or an oracle network. It does not show that the money is held in segregated accounts, that the assets are of the required quality, or that they are free of other claims. Those questions are answered by the issuer's reserve bank, its custodians and an independent attestation firm.
We design the feed's update process as carefully as the token: who may write to it, how the written figure is reconciled to bank statements, and what happens if it stops updating. Publishing attestation results or their hashes to the Hedera Consensus Service adds a timestamped, tamper-evident record of what was reported and when, but it remains a record of the attestation, not a substitute for it.
Choosing how treasury actions are signed
- If
A small team operates the token and every supply change is reviewed by hand.
ThenUse a Hedera threshold key across named individuals, with the Studio's multi-signature back end collecting approvals.
It enforces separation of duties at the network level without extra infrastructure.
- If
The issuer is a bank with existing hardware security modules and signing policies.
ThenIntegrate signing with the bank's key management and keep threshold rules for the most sensitive roles.
Key custody then follows the controls auditors and supervisors already review.
- If
Mints and burns follow from automated payment events at high volume.
ThenAutomate cash-in within a tight allowance and reserve check, and keep allowance increases and role changes under manual multi-party approval.
Automation handles routine flow while a compromised service cannot exceed the limit set by people.
Where stablecoin operations tend to break
Minting against unconfirmed money
Early signalCash-in requests are approved on a payment notice rather than a settled credit.
MitigationTie each mint to a settled bank credit reference and reject requests without one.
A stale reserve figure
Early signalThe reserve feed's last update is older than the reconciliation cycle.
MitigationAlert on feed age and treat a stale feed as a reason to stop minting until it is reconciled.
Redemptions queue behind manual steps
Early signalBurned tokens wait days for fiat payout approval.
MitigationPublish a redemption service level, staff it, and track ageing of open redemptions every day.
One person can change supply
Early signalA single key holds cash-in and admin roles together.
MitigationSplit roles across people and keys, and require threshold approval for role changes.
Frequently asked questions
Is Stablecoin Studio a licensed stablecoin service?
No. It is open-source software for issuing and administering a token. The licence to issue, the reserves, the custody of those reserves, redemption operations and independent attestations all belong to the issuer and its banking and audit providers. Our guide to MiCA, the GENIUS Act and other regimes sets out what regulators expect.
Do holders need special wallets to use a Stablecoin Studio token?
No. Holders use the token like any other Hedera Token Service token, so wallets and custodians that support HTS can hold it. Each account must be associated with the token and, if the issuer enables KYC, granted the KYC flag before it can receive funds. The contracts are used by the issuer's operators, not by holders.
Can Stablecoin Studio be used for a tokenised deposit?
Technically yes, because the controls it provides, such as KYC, freeze, cash-in and burn, are the same ones a bank needs to mirror customer deposits on a ledger. The legal model differs: a tokenised deposit is a bank liability under banking law, not a separately reserved stablecoin. Our comparison of tokenised deposits and stablecoins covers the choice.
Have the Stablecoin Studio contracts been audited?
Hedera's documentation states that the factory contracts were audited by CertiK2. An audit covers the code version reviewed at the time; it does not cover your configuration, your integrations, your key management or later upgrades. Plan a security review of the deployed configuration and the surrounding services before a production launch.
Can the stablecoin run on a permissioned network instead of public mainnet?
Where participants must be restricted or transaction data kept within a group of institutions, a permissioned Hedera-based network such as HashSphere can be assessed. Confirm that the network supports the token service and smart contract features the Studio depends on, and decide how the token would interoperate with institutions outside the network.
What does ColdAI build around Stablecoin Studio?
Stablecoin design with your counsel and reserve bank, covering reserve model, redemption mechanics and fee policy; treasury and key management, including multi-signature operations, HSM-backed custody, role-based administration and disaster recovery; proof-of-reserve integration and attestation publishing; and wallet, exchange, custodian and core-banking integrations so the token is usable from launch.
Sources
- Stablecoin Studio repository (README and architecture) — Hashgraph on GitHub
- Stablecoin Studio documentation — Hedera
Connect the architecture
The next connection.
Explore the complementary capabilities that can turn an individual technology into a complete workflow.
Your next move
Bring us the
real problem.
A workflow that takes too long. A system that cannot connect. An idea that needs a technical path. Start there, and we can define what to investigate, build and measure.
- A legally defined issuer and operating model
- Reserve and custody arrangements
- Treasury and qualified compliance owners