Transmission control
Spam protection with Page.NFT tokens
In the Crypto.Page ecosystem there are three ways how Page.NFT (i.e. post) can be transferred from one account to the other (from one user's wallet to the wallet of another user):
Using standard ERC-721 token methods for token transfer, such as transferFrom.
Creating Page.NFT by one user for another user at the initial creation of the post. As described in the Emission Model section - this will lead to the creation of Page.Tokens for the creator and for the recipient of the token.
Token transfer from Page.Community (later on - from other smart contracts as well) to another user based on the rules established in such a community (for example, based on the results of voting in the community).
Since the presence of Page.NFT on the user's account means that the post from this token is published on the user's social profile, a mechanism that will protect users from Page.NFT spam by other users is needed. Crypto.Page offers three ways how a user can configure his "readiness" to receive Page.NFT from other users:
The user can enable the unconditional obtaining of tokens from all blockchain addresses or from a specific address. In this case, the sender of the token can transfer the token to the recipient without performing additional actions on the part of the recipient. By default, unconditional obtaining is disabled for all users and a separate smart contract call is required to enable this option. Usage examples:
Contracts that bridge (transfer) tokens between different networks include unconditional token receipts from any network address.
Page.Community contracts for communities that allow the publication of posts by all members of the community, include the unconditional obtaining of a token for each member of the community when they join the community (and cancel token receipts opportunity if the user is banned).
Users who are familiar with each other can enable the unconditional receipt of tokens for each other since there is a high level of trust between them.
It should be noted that information about unconditional receipt is public information on the blockchain and by enabling unconditional receipt from all addresses on the network, there is a possibility that attackers will immediately find out about it and will send Page.NFT spam to such users.
The user can enable unconditional receipt for a specific token without specifying the address from which it will be received. A "specific token" can be indicated by one of two methods:
Indicating a specific unique Page.NFT ID - which is possible for already existing tokens.
Indicating the IPFS URL value in the token - which is possible for tokens that have not yet been created.
Usage examples:
When buying a token from another user through a smart contract (for example, a stock market smart contract), which takes the token from the seller and transfers it to the buyer in response to the transferred funds within a single transaction, the buyer includes the possibility of receiving such a token in order to make sure that the entire transaction (including receiving the token from the seller and transferring funds and the transfer of the token to the buyer) will be successfully completed and does not open up opportunities for the seller not to transfer the token in response to the transferred funds. It should be noted that the buyer includes permission only for a specific token and will be protected from spam by other tokens.
Receiving the transferred token after the transfering stage. In this approach, the recipient performs an additional transaction after the transfer in order to confirm the receipt of the token. Until this transaction is completed, the token remains on the sender's balance, however, a special mark in the token code will prohibit the re-sending of such a token. Usage examples:
A lottery that raffles tokens of the ERC-721 standard transfers any NFT tokens to the winning party (including Page.NFT), while the purchase of such a "lottery ticket" takes place in a different transaction compared to the winning transaction (for example, the purchase of a lottery ticket takes place a week before the draw). In this case, there is no way for the recipient to confirm that he/she is ready to accept this particular Page.NFT token, since the token ID is not known at the time of purchase of the lottery ticket. To solve this problem, the buyer sends the token using ERC-721 standard methods, but the real transfer does not occur. Instead, after checking the conditions for unconditional receipt described above, the behavior of the transfer method becomes similar to the behavior of the “approve” method in the ERC-20 standard, i.e. the transmitting party notes that the receiving party can take this token as part of a separate transaction. If the receiving party is interested in taking this token, the receiving party must call safeTransferFrom for this token and receive it. The receiving party can also call a method to refuse to receive the token, which will remove the protection from the double transfer of the token by the sending party. The sending party can also remove such protection, but not earlier than 10 days after the initial token sending (the deadline is configured by Page.DAO).
Creating content for a user when the decision on whether this user will accept the token or not, depends on the receiving party. In this case, the token is created by one user for another one, but the actual transfer of the token does not occur until the receiving party calls the receipt confirmation method. It should be noted that Page.Token tokens for both the token owner and the token author, according to Emission model, in this case are created only at the time of receiving such a token by the receiving party. The creator of the token can change the recipient or add additional possible recipients for such a token by calling a separate method, however, the real recipient of the token will be the recipient added by the author who calls the method of obtaining the token first. An example from real life may be a journalist's offer of an article to be placed in several Page.Communities, and acceptance of such a proposal after pre-moderation by the leadership of such a community (in the future, with the possibility of paying for such an article).
It should be noted that the balance check shows the presence of a token on the user's balance in case of a conditional transfer. Thus, if one smart contract transfers a token to another smart contract with a conditional transfer, there will be no real transfer. However, if the second smart contract tries to transfer the token to the third address (for which unconditional transfer can be enabled, or the owner of this third address can call the confirmation method for a conditional transfer in the future), such transfer will be successfully implemented, because the information about the token balance for this second smart contract will show its availability to the user.
It should be noted that a conditional transfer may allow the transmitting party to sell the token twice in a period of >10 days, if the receiving party does not call the receipt confirmation method, therefore, when trading Page.NFT tokens it is more recommended to use an unconditional transfer from an address or an unconditional transfer for a token.
Thus, method operation rules of transferring and creating a token for the user use the following logic:
We check whether the conditional transfer of the token has already been enabled and whether 10 days have passed since such a transfer was enabled. If the conditional transfer is already enabled and the deadline has not passed, we refuse to complete the transfer.
The transmitting party can cancel a conditional transfer by calling a special contract method for such cancellation. It is important to note that those contracts that work only according to the ERC-721 standard do not know anything about this method. Thus, the token transfer by such contracts will be performed only once.
We check whether the receiving party has enabled an unconditional receipt for all blockchain addresses or for a specific sender address.
If unconditional transfer is enabled, we transfer the token.
We check whether the receiving party has enabled an unconditional receipt for this token identifier or IPSF URL.
If an unconditional transfer is enabled for this token, we transfer the token.
We record information about a conditional transfer in the token contract, but do not carry out the actual transfer.
The recipient can call the receiving method and get the token.
The recipient can refuse to receive the token.
The sender can refuse to send the token after a special period of time passes (10 days by default).
The solution described above will allow existing software products and contracts to work with Page.NFT tokens in a quite similar way to how they work with other ERC-721 tokens, where the only difference from the standard behavior is that the token is shown on the sender's balance until the recipient confirms the receipt.
The Crypto.Page team publishes the smart contract interface IApproveAndReceiveERC721, which extends the standard ERC721 interface with methods for conditional and unconditional receipt of tokens. We expect gradual adaptation to this interface and the creation of a whole new layer of smart contracts that can work with tokens requiring confirmation of the receipt.
Indicating the rules for obtaining a token is specific to each blockchain, i.e. if there is a need to obtain a token with the same ID on different networks, it is required to allow the receipt of such a token on each of the blockchain networks.
The approach described above, in addition to the described functionality, creates protection against the transfer of a token to an external smart contract (from where, in case of absence of special methods for withdrawing the received tokens in such a smart contract, it may be impossible to collect it). Since an external contract cannot call Page.NFT contract method to confirm the acceptance of a specific token or to allow the unconditional acceptance of Page.NFT, the token will not be forwarded to the contract address. Nevertheless, such protection also has a negative side - for example, transferring a token from one smart contract to another smart contract, if at least one of the smart contracts does not support the necessary functionality for conditional or unconditional transfer, will be impossible. In the future, a possible solution may involve the use of Wrapped tokens to work in such contracts.
Last updated