Open alexauroradev opened 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:
totalSupply -> totalBridgedSupply
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.
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.
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:
totalSupply
->totalBridgedSupply
totalSupply
field that will represent the actual total supply of NEAR tokens.setTotalSupply
.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:totalSupply
.