[BUG] Amount of pToken in network is not fully pegged 1:1 to vault balance

For this discussion, we’ll be looking at Litecoin. However this issue likely applies to other coins such $BTC, $XMR and maybe even $ETH. However the Incognito network volume of those assets is much larger than $LTC. With $LTC being a recent addition to Incognito, it’s easier to review Litecoin’s full transaction history with Incognito.

CONTEXT

When $LTC is shielded, Incognito generates a single use address to receive the coin.

image

Here we see that single-use shielding address Lba4WKQybGoZMwv4LEJKsZjVAj2HVRh8uy received 4.35 $LTC. Address MS8g7KDz3atp82qrQidtqBXtpHimNr2Uwp is a change address in the bottom transaction.

About fifteen seconds later we see the received $LTC automagically sent to LLD6JTeDP8smXDFQf1FiGwoQeaeWWvqSMd which is Incognito’s $LTC vault. It is here in the vault this new $LTC mingles with the existing $LTC represented on the network, making new friends and generally enjoying the big party at it’s new home.

It’s important to remember that both Lba4W…8uy (as a single use receive address) and LLD6J…SMd (the vault address) are BOTH controlled by Incognito’s $LTC bridge. For every shield transaction, the receive address will be different but still controlled by Incognito’s $LTC bridge.

THE ISSUE

Let’s take a look at the amount of $LTC reported by the external network explorer.

image

Blockchair (and any other $LTC explorer) reports the address currently holds 52.43 $LTC.

Now let’s compare this amount with the $pLTC reported by the Incognito network explorer:

image

These snapshots were taken today at the same time. The $LTC vault holds 52.43 $LTC while there are 52.52 $pLTC tokens minted on the network. That, ladies and gentlemen, is NOT a 1:1 peg.

Why the difference? I’ll tell you. It’s “internal” transaction fees. To be certain, I pulled the transaction history for all^ 204 transactions involving LLD6J…SMd. The fees representing transfers in (shielding) and out of (unshielding) the vault equals 0.0865$LTC. 52.4319 (vault balance) + 0.0865 (total tx fees) = 52.5184. Yep, there’s the missing $LTC.

The automagic transfer of received funds from the single use address to the vault address is an on-chain transfer. On-chain transfers, of course, incur miner fees. These fees appear to be deducted from the vault balance but are not represented in the corresponding pToken allocations.

WHAT’S THE BIG DEAL?

Miner fees are small, right? Eventually these small miner fees will begin to add up to a not insignificant amount of missing value in the $LTC vault. Should a crypto bank-run occur, the last user in line is going to have a very nasty surprise.

Consider this example (fees are exaggerated for clarity’s sake):

  • The Incognito vault has a balance of 0 $LTC.
  • Alice shields 10 $LTC.
  • Incognito mints 10 $pLTC and deposits them to Alice’s Incognito address.
  • Incognito transfers the 10 $LTC to the vault. The transfer deducts 0.5 $LTC in miner fees.
  • The Incognito vault holds 9.5 $LTC. The Incognito network has 10 $pLTC.
  • Bob shields 10 $LTC.
  • Incognito mints 10 $pLTC and deposits them to Bob’s Incognito address.
  • Incognito transfers the 10 $LTC to the vault. The transfer deducts 0.5 $LTC in miner fees.
  • The Incognito vault holds 19 $LTC. The Incognito network has 20 $pLTC.
  • Alice unshields her 10 $pLTC.
  • Incognito withdraws 10 $pLTC from Alice’s Incognito address and burns them.
  • Incognito transfers 10 $LTC from the vault to Alice’s external LTC address. The transfer deducts 0.5 $LTC in miner fees from the vault balance.
  • The Incognito vault holds 8.5 $LTC. The Incognito network has 10 $pLTC.
  • Bob unshields his 10 $pLTC.
  • Incognito withdraws 10 $pLTC from Bob’s Incognito address and burns them.
  • However there are only the 8.5 $LTC left after transaction fees – so Bob only receives 8 $LTC, after his own unshielding transaction fee?

With large volume coins such as $BTC, $XMR and even $ETH, it does seem unlikely the entire balance of pTokens would ever be redeemed revealing the above issue for the last transactor. But the issue would still exist.

Conversely with mid and small volume coins such as $LTC, $DASH, $ZIL, etc, one can see how it is plausible for the entire network pToken balance to be redeemed (for one reason or another) leaving the last transactor without a complete redemption of burn pTokens.

As-is, $LTC has been available on Incognito for about 6 weeks. In that six weeks, $10 in value has already been eroded by fees. In a year, that will be over $90 at the current shield/unshield rate. In all likelihood, it will be much more.

SOLUTIONS?

I don’t know what the solution should be. Should some of the DAO funds be used to make the vault “whole” again? Should the “internal” vault transfers be deducted from the pToken minted? Perhaps both? Perhaps neither? Maybe this becomes a good first use for the oft-proposed DAO community governance?


^ Current as of 2030 UTC on 1/27/2021.

14 Likes

^^^

Nice post friend…and needs to be addressed.

2 Likes

It could be an Incscan bug too :wink:

I don’t process data before a token is validated so you could see some differences between on-chain and Incscan data if some shielding / unshielding operations happened before the validation of the token.

5 Likes

Thanks @Mike_Wagner for addressing the problem. We will provide proper feedback soon.

6 Likes

Curious about the answer :slight_smile:

Has a solution been implemented?

1 Like

I was looking for this post and the answer. It seems it has been forgotten.

1 Like

Was the bug related to Incscan? I remember seeing a few bugs like this in the past with ghost coins and negative liquidity.

Maybe. Before any investigation on my side, I prefer to wait for Incognito team answer about how they manage fees paid in PRV by the user but spent in targeted currency.

3 Likes

Waits at the edge of his seat for the answer…hears final jeopardy music playing in the background…raises eyebrow and thinks…‘wtf’… :sunglasses:

1 Like

Waiting for 1 month and a half now.

Hi @Stradimarius and everybody,

Currently, the shielding process for trusted bridges relies on temporary addresses, which is made up of two transactions (we’ll use 1 BTC as an example):
Tx 1: Shielding 1 BTC to a temporary address.
Tx 2: Sending that 1 BTC to the BTC vault address.
Since users only initiate the shielding transaction and pay fees for Tx 1, the fees for Tx 2 are left unpaid. Those fees are BTC network fees, not Incognito fees, so for now, these are paid by Incognito via the vault address. This is why the address would have slightly less than a 1:1 balance, as we have to top up the balance and make sure the ratio is balanced at 1:1. This results in a brief time period where the balance isn’t exactly 1:1. The deficit though is only a sum of fees, so there’s no risk of not being able to supply enough crypto to users who unshield.
Even though this workaround is only for trusted bridges and is thus abolished when bridges are made trustless, it’s still not ideal. So, we’re working on a solution in the meantime.

and please check the solution for decentralized bridged (Portal v4) is on the plan to release in May here :

thank you,

7 Likes