BURNT_FUNDS_ACTOR explanation

[snissn]

address constant BURNT_FUNDS_ACTOR = address(99);

is address(99) special or just chosen to be any other burn address? Why not 0?

Interpretation of 'BURNT_FUNDS_ACTOR' as an address constant (address(99)) requires explanation. Does this address signify a special use case within the IPC context?

[linear]

IPC-22 BURNT_FUNDS_ACTOR explanation

[snissn]

There's other discussion about the value of using 0x0 as the explicit burn address
consensus-shipyard/ipc-solidity-actors#313

with this being worth reading

https://forum.openzeppelin.com/t/removing-address-0x0-checks-from-openzeppelin-contracts/2222/2

I think that it's important to consider this coding standard - use 0x0 as the explicit burn address and create specific functions for burning.

The idea is to have a safeTransfer method that reverts if the 0x0 burn address used
and a safeBurn method that is the only accepted method to transfer to the 0x0 burn address

[raulk]

@aakoshh @adlrocha any reason for this choice? Note that this makes the burn address clash with the Ethereum precompile designated address range (0x01..0xff), which weakens forward compatibility. Why can't this be the nil address (0x00)?

[adlrocha]

I think we should use the zero address for this. This is another of the "blunders" coming from the close to literal translation of the native actors implementation of IPC to Solidity that we got from the team that did it.

[snissn]

Another benefit of using the 0x0 address is that there's standardized acceptance about how to measure the supply of a token by discounting anything owned by the 0x0 burn account (and the 0x29 etc burn account)

[aakoshh]

The IDs are coming from ref-fvm. The 0x0 address became the system actor ID.

[aakoshh]

There were apparently other expectations regarding 0x0 in #166 which lead to consensus-shipyard/fendermint#409