As described in the first deep dive post on May 15, Haven’s team spent the last several months redesigning Haven’s codebase. As a result, we have modified Monero’s commitment structure to implement the use of “colored coins” and enable a more secure and reliable xUSD exchange process.
The team began testing this new structure in private several weeks ago. During testing, we identified one key bug resulting from the modifications to Monero commitments: some onshore transactions failed due to the new “proof of value” verification process.
There are a maximum of 13 significant figures (digits) available for values smaller than 1 used on the Haven network. The problem is that XHV has a variable exchange rate and a variable number of coins being exchanged, including decimal parts. When multiplying (XHV coins) x (exchange rate) or dividing (XHV coins) / (exchange rate) for xUSD transactions, the resulting number may have too many significant digits to fit within the available 13, and the transaction would fail.
You can think of the problem this way: when exchanging XHV for xUSD, we used to say “offshore 100 XHV and turn it into xUSD.” To do this, we calculated how many xUSD we would get for 100 XHV. Let’s say the current exchange rate is 1 XHV = $0.33. In this example, we would get 33.3333333333333 xUSD (the fraction is recurring) for 100 XHV.
The problem arises when we go to verify the transaction’s value. On receipt of the 33.3333333333333 xUSD, we would say “convert that back to XHV to check the transaction used the correct amount of XHV to send.” But here’s the rub: 33.3333333333333 x 3 = 99.9999999999999. That does not equal the 100 XHV we sent. And the transaction would be rejected.
To resolve this problem, we have made two key changes to the xUSD code.
First, we are limiting all XHV and xUSD transactions generated in the Haven wallet to 4 decimal places to avoid the rounding errors which resulted in rejected transactions. Amounts generated automatically by the daemon (specifically block rewards for mining) are unchanged.
Second, we are reversing the “onshore” command in the code (xUSD to XHV) to require the amount being exchanged always be expressed in XHV. This will ensure xUSD exchange calculations are always multiplying (not dividing) a value, which will ensure values do not exceed 13 digits.
Both of these solutions were needed to resolve the bug that rejected some “onshore” xUSD transactions. We cannot allow transaction values to overflow 13 digits at any time, so we can never divide a decimal by another decimal to begin with — hence the need to reverse onshore commands in the code. When multiplying decimals, you end up with the sum of the number of decimal places of the two values. For example: (4.1234) x (4.123) = 17.0007782. So even though reversing onshore commands fixed the primary issue, we still need a limit to the number of decimals we can hold safely.
These two solutions have now been implemented and are being tested by the team in private. Once we are satisfied they work, and there are no additional bugs, we will provide the mainnet release candidate to the public for testing. We will also release an updated Haven Vault (GUI) for public testing in preparation for mainnet launch.
At that time, we plan to make available on Haven’s public GitHub repo the entire xUSD codebase we have been developing for more than a year. We believe public disclosure of the xUSD code is critical to Haven’s success in the long term and will provide an opportunity to strengthen the project through the assistance of other interested developers.
You’ll be able to view the xUSD code here when it is released. We will post a separate announcement when the code is shared to GitHub.
After sufficient public testing, we intend to announce a hard fork date and launch xUSD live on Haven’s mainnet. We have been in communication with exchanges and pools to ensure a successful mainnet launch.