The 404 Revolution: Opening the Purse Box | Part 2

Continuing the first article about ERC-404, we will explain in more details about the other upgrades that we added to the PURSE-404.

Transferring PURSE

The upgraded PURSE contract has a number of functions to transfer PURSE as ERC20 or ERC721. PURSE transfers that are ERC20 related remain mostly the same prior to the upgrade, however there are some important updates.

During PURSE ERC20 transfers, the contract will first try to use up all the PURSE in an address’s Inactive Balance. Once the Inactive Balance is depleted, the contract will start to use the PURSE in the address’s Active Balance — which represents the PURSE NFTs owned by the address. However, this will result in NFTs being removed from the address to offset the deficit in the Inactive Balance; and each removal of an NFT would result in an increment of 1,000,000 PURSE in the Inactive Balance, but a reduction of 1,000,000 PURSE in the Active Balance.

When a PURSE NFT is successfully transferred from one address to another — regardless of whether the recipient is an Externally Owned Account (EOA) or a smart contract, the ownership of the NFT is transferred to the recipient, and the Active Balances of both the sender and the recipient are updated accordingly. Since 1 PURSE NFT is represented by 1,000,000 PURSE ERC20, the sender’s Active Balance will be deducted by this amount while the recipient’s Active Balance will be increased by the same amount; and the Inactive Balance for both parties will remain unchanged since this is an ERC721 transfer.

When a PURSE NFT is transferred, the transfer is technically moving 1,000,000 PURSE from the sender to the recipient; but instead of the change in balance being accounted for in the Inactive Balance, it is accounted for in the Active Balance. Since the Total Balance is the sum of the Inactive Balance and Active Balance, this change will also be reflected in the current Total Balance of PURSE for both the sender and the recipient.

You can learn more about the implementation of these changes on our gitbook.

Maintaining PURSE NFT(s)

As with any 404 token, it is each user’s responsibility to ensure that they have sufficient balance to preserve any 404 NFT they have in their address. PURSE is no exception to this rule. Different 404 tokens will enforce this rule differently. In some 404 tokens, once an address does not have sufficient balance to maintain its NFTs, the NFTs get burned from the address; but in others, the address’s NFTs might get transferred out from the address and are stored somewhere temporarily.

In most cases, it is an address’s most recent NFT(s) that gets affected by this rule, and the minimum balance required to maintain any 404 NFT in an address simply follows the following equation:

minimum balance required = number of NFTs * ERC20 equivalent amount for 1 NFT

In PURSE, 1 PURSE NFT requires 1,000,000 $PURSE(ERC-20) to be maintained in an address. And if this condition cannot be maintained, then the address would lose that PURSE NFT. When this PURSE NFT is transferred out of the address, it does not get burned, instead it gets transferred back to the PURSE contract and is available for minting; and anyone who successfully mints a PURSE NFT thereafter will obtain the PURSE NFT that is stored in the contract.

PURSE NFTs that get sent back to the contract as a result of an address having insufficient balance to maintain them are stored in a queue-like structure, this will be highlighted in the next section after the following example.

NFTs in Queue

PURSE NFTs that are transferred back to the PURSE contract are stored in a queue-like data structure. This queue is a First-In-First-Out (FIFO) structure, which means that the first PURSE NFT that is sent to this queue will be the first NFT minted on the next mint transaction. If the queue is empty, then a brand new NFT token id will be minted on the next mint transaction.

Token IDs

Because PURSE has been upgraded from an ERC20 to a 404 token, token transfers must now take into account what constitutes an ERC20 transfer or an ERC721 transfer when `transferFrom` is executed. Both ERC20 and ERC721 tokens have a `transferFrom` function which yields the same signature hash:

➜ keccak256(“transferFrom(address,address,uint256)”)
Type: bytes32
└Data: 0x23b872dd7302113369cda2901243429419bec145408fa8b352b3dd92b66c680b

This means that on the level of the EVM, when PURSE is being transferred, calls to `transferFrom` will produce the same function selector of `0x23b872dd` regardless of whether they are intended for an ERC20 or ERC721 transfer.

In order to allow PURSE to discern if a `transferFrom` should be an ERC20’s or ERC721’s implementation, the function was overridden to make that discernment based on its uint256 argument. The maximum value for the uint256 type is: 2256–1, which is an extremely large number (to put this in perspective, there are approximately 1080 atoms in the observable universe and the max value of uint256 can be used to enumerate almost every known atom).

Most ERC20 transfers will not, realistically, exceed half of that maximum value, so the upper half of the range of uint256 remains to be utilized. Thus, PURSE reserves the lower half of 2256–1 for ERC20’s `transferFrom` and the upper half of that number for PURSE NFT token ids.

This essentially means that when `transferFrom` is called, if the value of the uint256 argument is a number: 0<x2255, it will be executed as a ERC20 `transferFrom`. And if the value of the uint256 argument is a number: x>2255 (or x2255+1), then `transferFrom` will be executed as ERC721’s implementation.

Note that even though `transferFrom` is used here, it is always recommended to use `safeTransferFrom` when transferring as ERC721 to mitigate any possibility of permanently locking the NFT in an unintended address. For more information on this, please refer to EIP721.

For clarity, 2255 in its full numerical representation, is: 57896044618658097711785492504343953926634992332820282019728792003956564819968.

And this means that the very first PURSE NFT token id is: 57896044618658097711785492504343953926634992332820282019728792003956564819969.

So far, we’ve covered PURSE-404.

More details are written in the Gitbook, and if you have any questions, please ask them in the Starscan forum.

Join PURSE Official Channels

Twitter: https://twitter.com/Purse_Land
Telegram: https://t.me/purse_land
Website: https://purse.land/