Solv Documentation
Search…
⌃K

Token-to-Token Transfer

The address-to-address transfer in ERC-3525 is compatible with that of ERC-721.
What makes ERC-3525 special is its ability to transfer only a fraction of the underlying asset within an ERC-3525 token. Such a transfer is implemented through the token(_tokenId)-to-token(_tokenId) transfer function transferFrom(uint256 _fromTokenId, uint256 _toTokenId, uint256 _value) external payable; and the token(_tokenId)-to-address transfer function transferFrom(uint256 _fromTokenId, address _to, uint256 _value) external payable;.
As mentioned previously, the token(_tokenId)-to-token(_tokenId) transfer applies to the transferring of ERC-3525 tokens that have the same _slot. This type of transfer allows users to transfer an amount of the underlying asset within an ERC-3525 token(_tokenId) to another:
/**
* @notice Transfer value from a specified token to another specified token with the same slot.
* @dev Caller MUST be the current owner, an authorized operator or an operator who has been
* approved the whole _fromTokenId or part of it.
* MUST revert if _fromTokenId or _toTokenId is zero token id or does not exist.
* MUST revert if slots of _fromTokenId and _toTokenId do not match.
* MUST revert if _value exceeds the balance of _fromTokenId or its allowance to the
* operator.
* MUST emit TransferValue event.
* @param _fromTokenId The token to transfer value from
* @param _toTokenId The token to transfer value to
* @param _value The transferred value
*/
function transferFrom(uint256 _fromTokenId, uint256 _toTokenId, uint256 _value) external payable;
The token(_tokenId)-to-address transfer applies to the transferring of a certain amount of underlying assets within an ERC-3525 token (_tokenId) to a different address. The token(_tokenId)-to-address transfer allows a new ERC-3525 token with the same _slot value as the original token to receive the asset transferred:
/**
* @notice Transfer value from a specified token to an address. The caller should confirm that
* _to is capable of receiving ERC-3525 tokens.
* @dev This function MUST create a new ERC-3525 token with the same slot for _to to receive
* the transferred value.
* MUST revert if _fromTokenId is zero token id or does not exist.
* MUST revert if _to is zero address.
* MUST revert if _value exceeds the balance of _fromTokenId or its allowance to the
* operator.
* MUST emit Transfer and TransferValue events.
* @param _fromTokenId The token to transfer value from
* @param _to The address to transfer value to
* @param _value The transferred value
* @return ID of the new token created for _to, which receives the transferred value
*/
function transferFrom(uint256 _fromTokenId, address _to, uint256 _value) external payable returns (uint256);
This new transfer model fundamentally changes the way blockchain-based assets can be transferred. We can use an example of the bitcoin payment to understand the importance of ERC-3525's transfer model.
Suppose Alice and Bob each have $50 in bitcoin in their accounts. Alice sends $20 to Bob. Now her remaining balance is $30, and Bob now has $70. Through Bitcoin’s state transition function, the transfer process looks something like this:
APPLY({ Alice: $50, Bob: $50 }, "send $20 from Alice to Bob") = { Alice: $30, Bob: $70 }
With the advent of smart contracts, the original account system utilized in Bitcoin has been expanded into EOA (that are controlled by private keys) and contract accounts (that are controlled by their contract codes). An EOA has no code and can allow anyone to send messages by creating and signing a transaction through itself. A contract account, on the other hand, can read and write to internal storage, send a new message, or even create a new contract when it receives a message from outside itself.
Ethereum’s transfer function looks something like this:
function transferFrom(address _from, address _to, uint256 _value) public returns (bool success)
Since Ethereum has no restriction as to what type of account can transact with the other and what can’t, it has built an entire ecosystem supported by asset transfers among EOAs and contract accounts.
ERC-3525 provides a paradigm shift in the asset transfer model, namely, token(_tokenId)-to-token(_tokenId) transfer. It enables receiving, storing, and transferring of an asset from tokens, rather than addresses:
function transferFrom(uint256 _fromTokenId, uint256 _toTokenId, uint256 _value) external payable
In ERC-3525, a token(_tokenId)-to-address transfer involves creating and transferring to the recipient’s address a new SFT with the same _slot as the original. An address-to-token(_tokenId) transfer would involve custom programming based on the Ethereum Transaction Simulation.
ERC-3525’s token(id)-to-token(id) transfer
To sum it up, ERC-3525 SFTs have gained equal importance as EOAs and contract accounts. Like Ethereum smart contracts, ERC-3525 SFTs are capable of external interactions, conditional judgments, and smart executions – the whole nine yards.