Who holds the keys?
A technical guide to stablecoin infrastructure
Stablecoins are past the experimental phase. They now sit at the heart of digital asset markets, powering trading, DeFi, cross‑border payments, and increasingly, day‑to‑day financial operations.
Stablecoins account for a significant share of on‑chain activity across leading networks, with some studies putting their share of DeFi volume at well over 60–70 percent on popular chains.
Against that backdrop, “who holds the keys?” is not a niche crypto meme; it is a core question of control, risk, and resilience. Stablecoins operate on the same cryptographic foundations. The difference is that they now sit closer to critical financial flows, which makes understanding key ownership not just important, but essential.
Mapping control across stablecoin infrastructure
To understand who really controls a stablecoin balance, you first have to understand the structure it sits on. A stablecoin position is never just “USDC in my wallet” or “USDT on an exchange”. It is the product of several layers working together, and each of those layers influences who ultimately has a say over your funds.
The asset layer
The first layer is the asset layer. This is the stablecoin smart contract itself, plus the rules and permissions built around it. Most mainstream fiat‑backed stablecoins are designed as upgradeable contracts with one or more admin roles. Those roles can allow the issuer to do things like create or destroy tokens, update contract logic, or freeze activity at specific addresses if required. Even if you never interact with these functions directly, they form part of the overall control model for the asset you are holding.
The settlement layer
The second layer is the settlement layer: the blockchain (or rollup) where your stablecoin actually exists. This might be Ethereum, Tron, Solana, a Layer‑2 such as an optimistic or zk‑rollup, or a sidechain. This layer determines how transactions are processed and confirmed, how fees behave when demand spikes, and how the network handles congestion or temporary failures.
Most of the time, these details are invisible. You send a transaction and it just works. Under pressure, though – for example, during market volatility or network spikes – they become critical. They determine how quickly you can move funds out of harm’s way, how much it costs to react, and how reliable your recovery processes really are.
The access layer
The third layer is the access layer: how keys are created, stored, and used. This is where wallets, multi‑party computation (MPC) systems, hardware security modules (HSMs), and smart‑contract wallet frameworks come into play. It is also where the idea of “holding the keys” becomes concrete.
In some setups, this might be a single externally owned account (EOA) with one key. In others, it might be a smart‑contract wallet with several owners and a separate “guardian”, or an MPC scheme where multiple devices or systems have to co‑operate to sign. Each approach balances ease of use, protection against compromise, and the ability to recover if something goes wrong.
The service layer
The final layer is the service layer: exchanges, custodians, fintech apps, and DeFi protocols. This is the layer most users actually see. In practice, many people never deal directly with the blockchain; they log into a platform, see a balance, and click buttons.
That platform may pool user funds together, keep its own internal ledger of who owns what, and control a relatively small number of wallets on‑chain. From a control point of view, this means the service layer can effectively decide when and how users access their stablecoins, regardless of the underlying asset or chain. If a platform pauses withdrawals or restricts activity, that decision can matter more than any technical property of the blockchain itself.
When you put these layers together, “who holds the keys?” becomes a question of where control is concentrated: at the asset level, the network level, the access layer, or the platform you use – and how all of those interact when things are not going to plan.
What does ‘holding the keys’ actually mean?
Keys, signatures, and control
At the most basic level, blockchains don’t know anything about people or accounts in the traditional sense. They only know about keys and signatures. A public key is used to derive an address. A private key is used to sign a transaction from that address. If a transaction carries a valid signature from the right key, the network will accept it. If it does not, the network will ignore it. There is no built‑in appeals process or reset button.
The single‑key era
For a long time, this boiled down to a simple model. You had a wallet, an address, and a private key (usually represented as a 12‑ or 24‑word recovery phrase). You might write that phrase on paper, store it on a device, or keep it in a password manager. As long as you kept it safe and had a backup, you stayed in control. Lose it, and the funds were effectively gone. Share it, and whoever has it can move your assets as easily as you can.
Many of the classic crypto loss stories come from this era: hard drives thrown away, hardware wallets misplaced, recovery phrases forgotten. The technology worked exactly as designed, but the human processes around it were fragile.
Smarter wallets and shared control
As more value moved on‑chain and more organisations started using digital assets, that single‑key model started to look risky. In response, the industry developed smarter ways of managing keys.
Smart‑contract wallets use code to define rules: multiple owners, spending limits, “guardian” accounts that can help recover access, or time‑based protections. MPC wallets split control across several machines or people, so no single device ever holds the full key and a signature can only be produced when enough parties agree. Institutional setups often put key material behind HSMs and policy engines that enforce approvals and logging for every sensitive action.
The signing path
In this environment, “holding the keys” is less about a single secret and more about the path a transaction takes from decision to signature. That path includes who is allowed to start a transaction, who has to approve it, which system actually creates the signature, and how those pieces can be changed or shut down.
It also includes what happens when something breaks. If a key holder leaves the company, if a device is lost, or if a data centre goes down, you need to know how the system continues to function or how you bring it back to a safe state. If you can’t trace that end‑to‑end, you don’t really know who holds the keys – or how solid your control is when under pressure.
What is stablecoin infrastructure and how does it work?
Issuer‑level powers and limits
Stablecoin infrastructure bakes specific powers and limits into the system. One of the most important things is at the issuer level. Many leading stablecoins include admin roles that can freeze balances at addresses, pause parts of the system, or make other changes when needed. These roles are usually held by a core team, an operations or compliance function, or a controlled group of signers.
In practice, these controls have been used to respond to exploits, fraud, and legal orders, and to prevent stolen funds from being moved further. For everyday users, this may feel distant. For businesses and institutions, it is part of the risk picture: even with perfect key management, there are still defined circumstances where the issuer can affect how your stablecoins behave.
Chain and infrastructure choices
At the infrastructure level, the choice of chain, rollup, and bridging paths shapes how your stablecoins behave day to day. Cheaper fees and higher throughput can be attractive, but they often come with different trust and failure assumptions – for example, a rollup whose sequencer can pause or delay final settlement, or a bridge that becomes a single point of failure for moving assets between networks.
If your operations assume that you can always move stablecoins quickly and cheaply across chains – for example, to rebalance liquidity or respond to market changes – then you are implicitly relying on that infrastructure working under stress. A good recovery plan needs to take those assumptions into account, not just assume ideal conditions.
Access‑layer design
At the access layer, moving from simple EOAs to smart‑contract wallets and MPC brings real benefits, but it also introduces more moving parts. You may have different roles for different team members, time‑based controls, separate key shares for different environments, and a mix of hot, warm, and cold storage.
This is often necessary for serious operations, but it does mean there are more places where a misunderstanding or a missing step can cause a problem. To make this work, each of these components needs a clearly defined role in both day‑to‑day operations and in any recovery process.
Service‑layer concentration
At the service layer, exchanges and fintech platforms have become the main way many people access stablecoins. A significant portion of the global stablecoin supply is held this way. Users see balances in their accounts but never see a key, a seed phrase, or even a transaction hash.
These platforms often have strong security and compliance practices, but they are also concentration points. If a platform has an outage, changes its policies, or runs into serious problems, large numbers of users can suddenly find themselves unable to move funds. Past examples of platforms halting withdrawals or entering restructuring have shown how quickly “my stablecoins” can become “my claim against a platform” instead.
Seeing these layers clearly is the first step towards understanding who really holds the keys at each point, and what that means for your ability to act when you need to.
Custodial vs non‑custodial explained
The usual way people talk about this is “custodial versus non‑custodial”. That framing is useful, as long as you treat it as a question of where control is delegated – and how that delegation is managed.
Custodial model
In a custodial model, you hand over key management to a third party. You or your users log into an account on an exchange, custodian, or app. Behind the scenes, that platform holds the keys, signs transactions, and keeps track of who owns what.
This has clear benefits. It makes onboarding simple, supports familiar account recovery and customer support, and often integrates directly with bank transfers and cards. It is one reason so many people use stablecoins through exchanges and fintech platforms rather than self‑managed wallets.
The trade‑off is that you have no direct cryptographic route to your funds. If the platform pauses withdrawals, changes its rules, suffers a breach, or becomes insolvent, you are reliant on its processes and on the legal system. Past failures have shown that users in this position often end up as unsecured creditors, even if they believed they “owned” the assets in question.
Non‑custodial model
In a non‑custodial model, you or your organisation control the keys yourselves. That might mean simple hardware wallets and seed phrases, or more advanced smart‑contract wallets and MPC‑based systems with built‑in approvals and protections.
This gives you a direct relationship with the blockchain. No single third‑party platform can unilaterally block you from moving your stablecoins. However, it also means you take on much more responsibility. You now must think about how keys are generated and stored, who has access to them, how you back them up, and how you rotate or revoke them when something changes.
You also must accept that mistakes here can be final. The same patterns that have led to a large share of bitcoin being lost – misplaced seed phrases, lost devices, untested backups – apply just as much to stablecoins. The difference is that the stablecoins you lose might be part of your operational budget, not just a long‑term investment.
Hybrid operating models
In practice, many more advanced users end up somewhere in the middle. They might hold day‑to‑day operating balances with a custodian or an exchange to benefit from liquidity and integrations, while keeping longer‑term reserves or higher‑value positions in more controlled non‑custodial setups. The key is that this mix should be intentional and well‑documented. You should know which assets are held where, who controls the keys in each case, and how you would regain access if any one piece of that setup failed.
Why key ownership and recovery design matter
Stablecoins are increasingly being used as working infrastructure rather than speculative assets. They are used as collateral in DeFi, as quote assets on trading venues, as a tool for treasury and cash management, and as a way for individuals and businesses to protect themselves from local currency instability.
In all these cases, the expectation is the same: the asset should not just keep its value but remain accessible when needed. Losing access at the wrong moment can mean missed trades, payment failures, or serious balance sheet issues.
Stablecoins promise the comfort of a stable value, but that promise only really holds if you can access, move, and, crucially, recover those assets when it counts. Beneath every balance is a network of contracts, chains, wallets, and platforms where a relatively small number of signing paths ultimately decide what can and cannot happen with your funds.
Final thoughts
If your honest answer to “who holds the keys?” still involves a lot of “it depends”, now is the time to tighten that story. Map your layers. Clarify ownership and responsibility. Test your recovery plans in conditions that feel uncomfortable, not ideal. The cost of finding gaps in a controlled drill is always lower than discovering them mid‑incident.
This is exactly the problem space CoinCover focuses on. Coincover Stablecoin Recover is designed to give organisations a safety net around their stablecoin holdings by combining specialist key protection with engineered recovery paths that work in the real world To learn more about how Coincover Stablecoin Recover can fit into your stack, you can explore the product in detail here.