SigmaUSD DAO bank is a complex beast

There are some popular misconception about SigmaUSD bank already, e.g. that you will get more ERG if the price is going up.

Actually, bank reserves could become more dry when SHORT or LONG traders are fixing profit before you’re out, then you can get less ERG.

So please consider different strategies you and others can run, to play with the bank, or bank and CEXes also (as oracles are getting prices from CEXes, and liquidity is not good there still, so we can expect pump&dump schemes to be run there in order to profit from the SigmaUSD bank).

Things will be even more complex with DeFi to be build on top of SigUSD, e.g. if you can get APY from putting SigUSD (or even SigRSV) into ErgoSwap.

So let’s discuss different aspects of SigUSD Bank properties here. I also guess some dedicated groups for SigUSD community are needed, to push its adoption not for speculation just.


I’ve spent a couple of days trying to figure all of this out. I’ve considered programming a bot for Hotbit because the spread is often 1%.

Is there any platform, exchange, etc planning to adopt SigmaUSD? Any guesses for how long it will take before people start using the stablecoin?

My random thought.

SigmaUSD is currently the only mixable stablecoin I am aware of.

Most mixers have some time element involved. SigmaUSD offers the ability to prevent loss of market value in the underlying asset during mixing.

I think there is value/utility, in the ability to mix stable value. Not to mention the value is backed 4/8 by a reserve currency.

If this was put in place it would be interesting to see if there is a market for existing stablecoins/SigmaUSD swaps.

Many stablecoins already offer a yield mechanism beyond the Ergo mixer fee, but offer no privacy.

There still would be profit after using SigmaUSD to add a layer of privacy at a discount to the existing yield from pre-existing liquidity pools of other assets.

SigmaUSD would be more of a privacy tool in this scenario initially.

If the mixer is tokenized, it may be beneficial to create a secondary reserve associated with the AgeUSD protocol that holds a significant % of the Mixer Tokens.

If the reserves P/B ratio could be tied to this secondary mixer token reserve, it would allow holders of SigmaRSV to have a secondary claim upon redemption in SigmaUSD.

The SigmaRSV holders would be providing collateral for the reserve, but also would benefit from the service this reserve provides. The creation of SigmaUSD and utility of mixing it.

This fee from mixing tokens would accumulate in SigmaUSD, theoretically it could be redeemable upon redemption of SigmaRSV. If popular this may be the pathway to liquidity pools and APY based on demand.

This is not something that the AgeUSD Protocol on Cardano would have the ability to replicate. Which kind of makes it uniquely Ergo’s. Hosting the mixer would serve the interests of miners and interact with the stablecoin contract.

It seems it would be something to build branding around SigmaUSD and Sigma Protocols, and offer a unique service the market does not currently have, the ability to mix stable value.


It is Ergo’s first very big beast. And i am amazed. Its beauty is obvious! It seems the value of my SigmaRSV compared to ERG is falling day by day BUT at the same time i refuse to swap it back even more each day. Beautiful.

I am not angry about it because we can just not see the value right now. But could you, the engineers behind, give the users more visibility of the actual value we are holding while owning SigRSV?!

I want to see how much i approximately get while swapping back right now. After linking my wallet to i only see the amount of ERG but zero SigRSV. I got several failed transactions but Yoroi displays the amount. Also, it seems to be the same, if i type in Redeem SigmaRSV → ERG without linking my wallet. But it should calculate the PB/ratio and tell me how much i should get out approximately.

It is pure beauty and i will hold strong, but we need to see what we have. Yoroi also graphs please!


What’s the benefit of holding RSV, there’s obviously a risk involved in giving up your ERG to mint reserve tokens. So when RSV holder don’t get more ERG when converting back (after ERG went up in $), what’s the point? Risk but no reward is not an incentive. Maybe I’m understanding it wrong, would love a deep explanation.

Conversion fees go into the reserve and your % of the total SigRSV is the amount of the total ERG in the reserve that you get to take out when redeeming your SigRSV.

So if the fees go into the reserve, the total amount of RSV should go up, but because I’m not converting more ERG into RSV my total % of the RSV should go down (in percent). So if I convert my RSV back into ERG therefore I would get even less ERG back than I put in?

The ERG added to the reserve does not change the number of SigRSV in circulation, your percentage of SigRSV is your claim to the amount of ERG held in the reserve.

I see, so the additional ERG come from fees and from people who send their ERG to mint SigmaUSD right? So holding RSV makes only sense if the use of SigmaUSD increases substantially right? I heard Cardano will possibly look into implementing SigmaUSD?

What determines the exchange rate between ERG and RSV? Currently it’s 1 ERG = 832 RSV. What mechanic makes this ratio go up or down?

so how does the collateral ratio will work? eg. in DAI, price security is relying on bidders so the actual demand on eth would provide stability. How will this work in ERG and its design?

For example: $50m rsv locked when ERG=$10, 1m ERg used to mint $10m sigusd. then if market price drops to $1.5 per ERG it would be equal to $8m worth erg for $10m Sigusd wouldn’t it break the stable value of SigUSD? Or system relies on arbitrage bots etc.?
march2020 kind of scenario would be a very strong stress test for this case

1 Like

When the reserve ratio falls below 100%, the stable coin breaks. When the reserve is at 100%, SigRSV holders have no claim on ERG in the Reserve. At current SigUSD/SigRSV levels, the price of ERG would need to drop below $1.13 to break the stable coin. That kind of volatility is only a problem in the short term, and will be less volatile with more use.
Anyone please correct me if I’m wrong.

yes thank you that’s what I was wondering, falling below %100 - I do wonder is there a solution for this extreme

Dear Community,

There has been discussions about the contract locking mechanism, and wheter it could be improved. Here is my review of the proposals that I have come across so far.

The current use of the sigmaUSD v1 and v2 contracts have been useful for ironing out bugs, and understanding the dynamics of the protocol. I will focus on the next phase by assessing how the protocol behaves, when the secondary markets are added. For this review, I assume that there will be sigUSD/ERG and sigRSV/ERG pairs in Ergodex, further use cases for sigUSD and possibly some yield generating mechanisms.

#1 Keep the protocol as it is.

Lets first consider what happens in case of a high demand for sigUSD. It might be used for example in multiple pairs in Ergodex, external exchanges, or means of payment in shops. High demand would drive the reserve ratio (RR) to 400%, which in turn would prevent purchasing more sigUSD in the contract. The pressure is alleviated if people purchase more sigRSV. However, they will do that only if the financial incentives are higher than in other market alternatives. If investors expect the future value of sigRSV to be low, then there might be shortage of sigUSD. That would drive sigUSD/USD and sigUSD/ERG exchange rates out of balance. After 1 sigUSD is worth >1.02 dollars on external markets, then an opportunity for arbitrage opens in the contract. At RR 400%, purchasing sigRSV before sigUSD would be the only option to carry out the arbitrage. This might not be lucrative for small arbitrage of 1.025 dollars, but most likely soon thereafter. The only problem would be a situation where RR is below 400% due to reduction in ERG price. For example at 350% it would take large amount of money to bring RR above 400% and benefit from the arbitrage. This is inefficient, and may be improved.

The second consideration is an event where ERG price drops significantly. AgeUSD is marketed as “no liquidations” protocol, but that is misleading, because someone always carries a risk. The question is how well such events are dealt with. In the worst case, the price drop would be large enough (e.g. 90%) to drop RR under 100%. The oracle price smoothing mechanism gives time for people to react, but if they would not be fast enough, then sigUSD would be redeemed for less than 1$ each. SigRSV holders would lose everything. In reality, sigUSD would probably start exiting the contract when RR approaches 100%, because of that risk. It would be a more controlled deflation of the contract than a forced collateral liquidation. This is the advantage that ageUSD has in the bad scenarios.

Even though cryptos tend to be volatile, the likelihood of these scenarios can be reduced by the ageUSD protocol. Money tied in the contract and secondary market liquidity pools increase the usage of the contract, and consequently the price of ERG. As the usage increases, people can be more confident that there is no sudden price drop. All monetary systems are based on trust after all. That trust is fostered by security, transparency and stability through usage in ageUSD.

#2 Varying fees

Increasing fees close to 400% and 800% RR could be an alternative to locking the redeem/purchase options. This could be done for example with an exponentially increasing function or threshold steps. For example, fee could be usual 2% at RR 450%, 10% at RR 425% and 99% at RR 401%.

The advantage would be that people are never locked out of the contract. The downside would be that sigUSD would lose the peg of 1$ within the contract. Therefore, it is a trade-off between locking options and fixed peg. It is not clear which option is preferable, and alternative protocol implementations might also find different sets of demand in markets.

The excess demand and ERG price drop events would run smoother with the varying fees, because everyone could exit at all times. However, they would complicate the contract, and reduce the trust of getting out 1$ worth of ERG for each sigUSD. Therefore, it might be better to keep the contract as simple as possible, and rely on the external market mechanism to value the ageUSD assets in bad scenarios.

#3 Option of purchasing and redeeming assets simultaneously

This solution addresses the problem in #1, where arbitrage is inefficient at RR < 400%. In such situation, it would be good to allow purchasing sigUSD and sigRSV simultaneously in such ratio, that it does not impact the RR. Also, those looking to exit their sigRSV position could buy a matching amount of sigUSD on secondary markets and combine them in one redeem transaction in the protocol. This possibility would also make it smoother for all to find the way out in case of a ERG price drop scenario.


Altogether, I believe that the simple, transparent and secure ageUSD design is the best foundation for a stable coin. Too complicated design as the base layer of a decentralized finance platform might lead to further unpredictable dynamics. The market mechanism provided by the external markets will be more efficient in setting the incentives than an arbitrary fee mechanism within the contract. The only change that I would recommend, is to add the option for redeeming and purchasing assets simultaneously. It allows the market mechanism to function even when the RR is not within the 400% – 800% range.

Everything above is highly speculative, and there may be many factors that I have missed. Therefore, I welcome all criticism and feedback.


Vesi, thank you for the write up. The current volatility and low liquidity of ERG and the SigUSD/RSV is the root of the problem as of this moment, I am of the belief that as SigUSD finds its usecase, and ERG grows organically, the current model will work well. That said, I do like the idea of a USD/RSV pair that would be subject to impermanent loss, a risk that the purchaser will be aware of. I am currently in complete disfavor of option #2, and would like to see SigUSD remain a simple protocol. Giving the crypto community an option to hold a true decentralized stablecoin that maintains the 1-1 peg with USD is key, as there is nothing similar to it. A reserve ratio going under 100% and thereby lowering the value of SigUSD is an inherent risk, but there will always be risk and it is just a matter of who bears that risk, and I would like to see the current model continue until there is a clear reason that it should not.

1 Like

Dear Community,

In this post I will discuss and review proposals regarding the oracle price smoothing. I am presenting other people’s ideas, and I am sorry if I have made any mistakes. Please contact me for edits if you find some.

Before starting I note that I am conservative about any changes to the protocol. I would like to keep it as simple as possible. I think the simplicity is a strength in a world full of financial instruments that are too complex for normal people to use.

All monetary systems are based on trust. Simplicity, security and transparency are the elements that build that trust for the sigmausd protocol. If there is trust, then there will be demand for sigUSD on the external markets. That demand will in turn create the incentives for people to put their ERG into the sigmabank.

#1 keep protocol as it is.

Currently ERG price has increased 4$ to 12$ in one week. The change in oracle price is intentionally smoothed to avoid quick market manipulations. It changes maximum 0.5% every 30 min (Please correct if this is not accurate). This creates incentive for people to purchase/redeem sigUSD/RSV, when the oracle price is significantly lagging behind the market price. For example in the current situation, when price increased significantly, it was financially beneficial to purchase rsv and redeem sigUSD.

As a result, we can expect the reserve ratio to swing between 400% and >800% every time when there is a large ERG price change. If other usage of sigUSD and RSV become significantly higher (e.g. shopping and liquidity pools), then those swings might be smaller. However, I don’t really see it going away with the current settings.

This causes unnecessary unstability in the reserve ratio and locked purchase/redeem options, which in my view is not optimal. I do think that the oracle price smoothing is necessary. It creates price stability and levels the playing field between normal users and high speed front running traders. However, such less-than-real-time solution should be countered with some stabilising mechanism.

#2 use future price

My preferred solution would be to delay the purchase/redeem transaction for some time, and use the future price for the transaction. For example, if ERG price doubles and a speculative shorter redeems his sigUSD, then there would be a waiting time before the price is locked and transaction goes through. The waiting time could be adjusted depending on how long it takes the oracle price to catch up.

This solution could actually remove the need for oracle price smoothing altogether. If a speculator knows that he will get the purchase/redeem price of one hour into the future, then he could not frontrun the oracle price based on market price movements.

The downside of this solution is making the contract more complicated and introducing wait times. However, I believe some solution is required, and this is simple enough. Furthermore, it would encourage real use of sigUSD, and discourage speculative use.

This idea was brought up by Tabby (telegram group SigmaUSD message 7744) and Snaxolax (Discord 15.5.2021). Please see Telegram and Discord for the discussion details.

#3, #4 and #5

There have been many other ideas of improvement too. I won’t go into detail because I prefer option #2. However, I wanted to bring them up here so that people are aware of them. Maybe I have missed some important dynamics that make these ideas viable.

#3 Glasgow (telegram group SigmaUSD message 6081) proposes having different reserve ratio thresholds for purchasing/redeeming sigUSD and RSV. E.g. 450% for purchasing sigUSD and 400% for RSV.

#4 Kushti (telegram group SigmaUSD message 6776) proposes limits to the amount of sigUSD that can be redeemed at once. E.g. only 1000 sigUSD per transaction, which would make it difficult to swing large amounts.

#5 J T (telegram group SigmaUSD message 7939) proposes a separate treasury for buffering against a situation, where reserve ratio reaches 100%. The treasury would collect a share of the fees and use them to cover sigUSD positions in case of <100% reserve ratio.

Everything above is highly speculative, and there may be many factors that I have missed. I am also only speculating on the dynamics, and I don’t know how feasible these solutions are technically. Therefore, I welcome all criticism and feedback.

(sorry for not linking the references. The forum does not allow multiple linking for new users)


I agree with you that simplicity and functionality are best when it comes to SigUSD. I think adding a timer to SigUSD redeeming is counter to functionality and makes the process of switching tokens artificially slow, making SigUSD unattractive to people who are accustomed to quick stablecoin purchases/redeeming.

Re#3: I like this idea, as it would prevent a total SigRSV lockout scenario like what has been happening.

Re#4: Again I think this moves counter to functionality - in the future people will be moving large quantities of SigUSD and will not like making individual transactions. I would support something like an incremental withdrawal, e.g. I want to withdraw $10,000 in ERG, and the contract will pay out $1000 per block or something. This would spread the withdrawal of large sums over multiple oracle updates.

Adding to contract complexity - going with scenario #4, a user could chose to either 1) pay 2% fee and have incremental withdrawal, OR 2) pay larger fee (e.g. 4%) for instant withdrawal

Re#5: I support this idea

1 Like

When I try to mint SigRSV or redeem them for ERG my transactions OFTEN fail and I get refunded. After like 3-4 times it works at some point. Anyone knows what’s going wrong? I’m sending the correct amount to the correct address… @kushti