Near-One / near-erc20-connector

A connector to Rainbow Bridge that allows sending $NEAR to Ethereum as an ERC-20 token (eNEAR)
Apache License 2.0
11 stars 7 forks source link

Total supply behaviour change #3

Open alexauroradev opened 3 years ago

alexauroradev commented 3 years ago

At the moment totalSupply of eNEAR corresponds to the supply of the bridged tokens. From one side this is logical, since this represents the whole amount of ERC-20 tokens available.

However, it causes confusion and creates some weird info on web-sites that collecting info from smart contracts, like super-low market cap of NEAR token.

Suggested change:

  1. Rename current totalSupply -> totalBridgedSupply
  2. Create a totalSupply field that will represent the actual total supply of NEAR tokens.
  3. Make an additional admin only method setTotalSupply.
  4. Set the token supply to the current total supply available at https://explorer.near.org/

Since $NEAR has non-fixed supply, the above value of totalSupply will be drifting the correct value. IMO, this can be solved in future with one of these approaches:

  1. A script for updating the value (perhaps this can be combined with the light client updated from the Rainbow Bridge)
  2. User transactions that transfer $NEAR from NEAR to Ethereum in the execution outcome start to emit the total supply of $NEAR (if this is available in the runtime). And during the transfer finalisation, this value is used to update the totalSupply.
mfornet commented 3 years ago

What do you think about educating consumers of totalSupply about its meaning.

However, it causes confusion and creates some weird info on web-sites that collecting info from smart contracts, like super-low market cap of NEAR token.

I see this point :( however I don't think anyone should be looking for NEAR total supply on a contract on Ethereum. I don't see a lot of value about exposing the totalSupply of NEAR on the contract (thinking about composability with other contracts in Ethereum).

What do you think about doing a simpler approach:

  1. Rename current totalSupply -> totalBridgedSupply
  2. Remove totalSupply

Note: Even with this simpler approach, it requires that we upgrade the Locker contract itself, so all balances must be transferred from this contract to the new deployed Locker. This is a complex, slow, expensive and sensitive process.

User transactions that transfer $NEAR from NEAR to Ethereum in the execution outcome start to emit the total supply of $NEAR (if this is available in the runtime).

I don't see it exposed by the runtime, however, this value is stored in the BlockHeader, so a proof can be built, and the value can be safely bridged, with an external service that orchestrate this process.

alexauroradev commented 3 years ago

Removing totalSupply will make eNEAR non-compliant with ERC-20 standard, so this is not an option.

@mfornet, thanks for noting the info on total $NEAR supply in the header. Maybe it's actually stored in the light client already? If so, we can add to the light client a method to expose the supply and in connector, the totalSupply method will just proxy the call to the light client.