The Creative Approach for Adding USDC to the Stellar Network

When talking about issuing a digital asset on a blockchain, each network comes with its own features and can be considered unique in a way. These aspects must be taken into account when architecting the representation of an asset in any new network, which can quickly become a challenge when issuing the same asset in multiple different networks.

Recently I came across this article by Mike Grant, explaining how Circle implemented USDC on the Stellar network and how they made use of the network’s native functionalities to ensure their requirements were met.

Here, I would like to dive deeper into this use case as the approach taken might seem unintuitive at first glance and still, turn out to be a clever solution.

The Use Case

Issued and managed by the Centre Consortium, the USDC is a stablecoin pegged to U.S. Dollar on a 1:1 ratio. Available in several consolidated networks such as Ethereum, Solana, and Polygon, the USDC has a well-structured standard for governance and implementation that was not created with just one network in mind.

Each member of the Centre Consortium has the ability to mint new reserves of USDC and should be able to do it with autonomy. Therefore, you have a set of multiple trusted entities managing one single asset.

When planning the addition of USDC to the Stellar network, there was a set of requirements that needed to be met, in order to ensure the implementation securely followed their standards.

By looking into the key points mentioned in their article, we can infer some of these requirements to be:

• Only trusted members of Centre should be able to mint USDC;
• It should be possible to add new minters or remove existing ones that might’ve been compromised;
• Each minter should be fully autonomous within a threshold of how much USDC it is allowed to mint;
• All reserves must be fully backed by USD in a 1:1 ratio with their reserves.

The challenge

The Stellar network provides token issuance and several other functionalities as native operations that can easily be performed through a transaction.

These operations are readily available and greatly speed up the development efforts. Still, each use case must be well planned before implementation and for the USDC, the main challenge was to ensure all of their requirements were met while still maintaining the autonomy of the minters.

On the Stellar network, an asset’s unique identity is based on its asset code (e.g. ‘USDC’)  plus the issuer account (the issuer wallet public key). There might exist several accounts issuing an asset named ‘USDC’, although they would be treated as different assets since their issuer accounts are different.

In order to maintain its fungibility and have one unique USDC representation in the Stellar network, the asset needed to be issued by one central account.

Typically, this shouldn’t be an issue since the Stellar network also offers native multi-signature capabilities, allowing one account to be managed by multiple signing keys with different signing power.

A personalized signing schema could be used to restrain access from specific entities to certain operations as well as require a combination of signatures to perform sensitive, riskier actions.

When thinking of a representation of the Centre’s structure, a multi-signature schema would not cover all the requirements. A minter could have its own medium-security signing key, allowing them to perform a mint operation on their own but, this would manage their access to a minting operation, without any limits on how much they would be able to mint.

On the other hand, the security threshold could have been configured to require combined signatures to perform a minting operation, so that it would only be executed if reviewed and signed by another peer minter.

This would add a layer of security so that no individual entity could jeopardize the asset supply in case their key was compromised. The problem with this approach is that per the Centre’s standard, the minter would lose their autonomy to manage the supply.

Other strategies could have been used with multi-signature and pre-signed transactions which would either not meet the requirements or increase the development efforts to extend the off-chain portion of the solution.

The Solution

To work around the native functionalities and keep most of these control mechanisms within the blockchain, the USDC implementation made use of an additional asset to manage the minter allowance combined with Stellar’s native decentralized exchange to serve the role of something akin to a dynamic issuing controller.

As part of the anatomy of tokens issued in the Stellar network, an issuer account does not hold a balance of its own asset. Any time the issuer account sends some of its own assets to another account, this amount is minted and considered an increase in supply added to the network.

On the opposite, whenever some amount of its asset is returned to the original issuer account, this amount is burned and removed from the total existing supply.

When combining this behavior with the DEX, an issuer account may open orders to exchange its own tokens for other assets.

Whenever an order is met and the amounts as transferred, any outgoing amount of the issuer’s token is then freshly minted. Similarly, any incoming amount of the token returning to the issuer’s account would be burned.

This is an interesting alternative way of managing a token supply that on its own, wouldn’t be a great approach for USDC. Since the asset must be accessible by any end-users, this means that anyone would be able to interact through the DEX and affect the token supply directly.

To improve upon this scenario, they’ve used a clever approach by introducing an intermediary token named ‘USDCAllow’.

This new asset would be issued by a separate account controlled through a multi-signature schema in the same way as the USDC issuer account, so no individual entity can perform operations on these wallets alone.A combination of signatures is required to ensure multiple members of the consortium have reviewed and approved the transactions.

The minters then use this new token to represent their maximum allowed quantity of USDC to mint on their own.  Each 1 ‘USDCAllow’ unit represents the ability to mint 1 ‘USDC’ unit and is distributed to each new minter.

Paired with this new token, the issuer makes use of the DEX to exchange USDC for USDCAllow, directly connecting the USDC supply governance to the minters’ accounts in a transparent manner, ensuring each entity may operate with full autonomy up to the defined limit.

The Workflow

It all starts with the USDC issuer account creating a ‘Buy’ order in the Stellar DEX, offering USDC tokens for USDCAllow tokens in a 1:1 ratio. This order is currently set to exchange up to the maximum amount possible of USDC to be minted since now the supply will be directly managed by the USDCAllow tokens.

Then, USDCAllow tokens are issued and distributed directly to each minter’s account. This amount represents how much USDC can be minted by the individual account.

Whenever a new minter is added, a new supply of USDCAllow is created and sent to this minter in relation to their limits.

Each minter can exchange USDCAllow tokens for USDC tokens through the Stellar DEX. Each new USDC is a freshly minted token that can be returned to the issuer account whenever the minter wishes to remove it from the live supply.

This way, a minter can now operate autonomously up to their amount of USDCAllow. By reaching their limit, it would be required that multiple members of the consortium agreed in sending more USDCAllow to this minter.

Additionally, the regular user would be able to see these orders in the blockchain but wouldn’t be able to interact with it as they wouldn’t have any USDCAllow tokens.

Once the minter has received the freshly minted USDC tokens, they can now distribute them to their users as they would like.

Conclusion

Centre succeeded in making the whole operation decentralized so that each individual entity of the consortium operates on its own, and also secure so that the central accounts can only be managed by a combination of entities.

No entity alone has control over the entirety of the USDC ecosystem and any risks of an entity being compromised would be contained within their limits for operating.

Another great outcome is that by keeping this minting control system inside the network, it became very reliable and transparent so that all users can monitor the operation through the blockchain.

Use cases like this could be also implemented through smart contracts which will be added to the Stellar network through the Jump Cannon project in the future.

Still, this approach to including USDC in the Stellar network is a great example of how different use cases must be adapted to each specific network, and that by creative usage of its functionalities, it is possible to build resilient, secure, and transparent ecosystems.