Subscribe to sijeesh
Subscribe to sijeesh
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers
Currencies are the most obvious category of tokens created on Blockchain networks. The requirement to keep the nodes virtuous demands them to be fungible. Two Bitcoins minted on different days will ideally have no difference in value on a given date, like a couple of dollar bills. Any alteration in data provided to generate these coins will not create a variant. The equivalency or non-uniqueness trait of currencies restricts the utility to the representation of account balances. However, the Blockchain, as a truth machine, can be used for purposes not confined to payments, and one such notable application is to use as a ledger for defining ownership of assets. The title records or deeds exist on the Blockchain as toke type called NFTs.
An NFT is a token living on a blockchain, which is intrinsically unique. The token has a field token id, which is of type, unsigned integer. The token id can range from 0 and go till 2^256-1. Two NFTs of the same kind would be different, unexchangeable, and depending on what metadata they hold, they may have different perceptive values. NFTs can convey possession of off-chain or on-chain assets. For instance, the City of Miami could opt to use a chain (say Ethereum) to register property settlements. The land department will be required to make individual tokens for every single property. An NFT can (and should) hold pertinent information. In this case, the address or the geolocation coordinate can be used as information to generate ownership tokens. Real-Estate is a perfect example of off-chain assets as NFTs. With regards to the on-chain case, typical NFTs hold SVGs images and surrounding metadata inside the tokens.
Ethereum was the first chain to enable the hosting of NFTs. EIP-721 introduced the concept as a proposal of having tokens on the network to represent ownerships. The EIP (proposal), now an ERC (standard), was created in January 2018 by William Entriken, Dieter Shirley, Jacob Evans, Nastassia Sachs to have deeds on the chain. This standard defines a set of interfaces to support the creation (minting), transfer, balance and store of metadata. All Smart Contracts, which wish to allow minting of these tokens, need to have methods events defined in this ERC. The standard specifies a must implement and two optional interfaces. Developers can add additional methods too to their NFT Contracts if needed. Interfaces in the specification do not imply functions for the creation and burning(destruction) of tokens, and the developer can define them as suited.
The standard prescribes 4 Interfaces:
ERC721, The first one, which also has the standard's name, is a MUST implement for the minting contract. ERC721Metadata Metadata interface is optional and provides read methods for name, symbol and URI of the Token. The URI holds the metadata of each token, which may comply with a JSON schema. Market places like OpenSean can display NFTs because the contracts store data in this spec. ERC721Enumerable Enumerable interface allows inquiry on the Contract for ownership and supply limit of the tokens. The intention was to enable the discoverability of this type of Contract. ERC721TokenReceiver Token receiver interfaces are for wallets to implement. This interface enables senders to perform safety checks before the transfer.
An Ethereum NFT contract will generate three events:
Transfer is generated when a new token is minted or transferred to a new address Approval is emitted when a new approver address is added by the owner to a token, the approver can transfer the owner token to another account ApprovalForAll same as approval, but emitted as part of a different method that can change approvers for multiple tokens.
The main contract has these methods:
balanceOf number of tokens owned by address ownerOf returns owner of tokenId safeTransferFrom Makes a safe check before doing the transfer to a new address transferFrom transfers the token to a new address approve Adds a new address as approver for a token, can be called by token owner only setApprovalForAll sets approver to multiple tokens getApproved retrieves approver address if any isApprovedForAll checks for pending approvers
To illustrate, I have created an NFT contract, which can mint ERC-721 tokens named SIJ-tokens. This DAPP would mint tokens to hold on-chain data, will represent characters with their index as they appear in the spelling of my name, for Eg S0, I1, S6 etc. The supply is limited to seven individual and unique items.
A number ranging from zero to six would be required as input to invoke the minting function. Tokens with characters S or E would be two each in number, and thus the ones with I, J and H are rarer. I am importing OpenZepplin Contract samples here to reduce my code. Openzepplin provides contract files conforming to required standards or having reusable solutions. Importing code from this repository is a common practice in Ethereum app development. The changes required to the Contract after performing the imports were minimum. To enable external minting of tokens, a public method named Claim was added. Additionally, the "TokenURI" function was overridden to have the required metadata generation. The definition for these two methods is following in the post. Nevertheless, the whole code of the Contract is available on Etherscan. The tokenURI function will return a JSON object, which will have an SVG image to show token data
function claim(uint256 tokenId) public {
require(tokenId > 0 && tokenId < 7, "Token ID invalid");
_mint(msg.sender, tokenId);
//_setTokenURI(tokenId, tokenURI(tokenId));
}
function tokenURI(uint256 tokenId) public view virtual override returns (string memory) {
string memory tokenStr = toString(tokenId);
string[19] memory parts;
parts[0]= '<svg xmlns="http://www.w3.org/2000/svg" preserveAspectRatio="xMinYMin meet" viewBox="0 0 200 200">';
parts[1] = '<circle cx="100" cy="100" r="75" stroke="black" stroke-width="4" fill="red" />';
parts[2] ='<text x="60" y="130" fill="white" font-size="smaller">~ SIJ TOKEN ~</text>';
parts[3] ='<text x="75" y="100" fill="black" font-weight="bold" font-size="3em">';
parts[4]=characters[tokenId];
parts[5]=tokenStr;
parts[6]='</text>';
parts[7] ='</svg>';
string memory output = string(abi.encodePacked(parts[0], parts[1], parts[2], parts[3], parts[4], parts[5], parts[6], parts[7]));
string memory json = Base64.encode(
bytes(
string(
abi.encodePacked(
'{"name": "SIJ -',tokenStr, '", "description": "Awesome Collectibles - SIJ Tokens", "image": "data:image/svg+xml;base64,', Base64.encode(bytes(output)), '"}'))));
output = string(abi.encodePacked('data:application/json;base64,', json));
return output;
}
I have deployed the contract on Testnet Rinkeby, links below
Rinkeby Etherscan link - https://rinkeby.etherscan.io/address/0x6b238761c25894cba26d7a7eec54b245516c9617
Sample minted NFT - https://rinkeby.rarible.com/token/0x6b238761c25894cba26d7a7eec54b245516c9617:1?tab=details
Currencies are the most obvious category of tokens created on Blockchain networks. The requirement to keep the nodes virtuous demands them to be fungible. Two Bitcoins minted on different days will ideally have no difference in value on a given date, like a couple of dollar bills. Any alteration in data provided to generate these coins will not create a variant. The equivalency or non-uniqueness trait of currencies restricts the utility to the representation of account balances. However, the Blockchain, as a truth machine, can be used for purposes not confined to payments, and one such notable application is to use as a ledger for defining ownership of assets. The title records or deeds exist on the Blockchain as toke type called NFTs.
An NFT is a token living on a blockchain, which is intrinsically unique. The token has a field token id, which is of type, unsigned integer. The token id can range from 0 and go till 2^256-1. Two NFTs of the same kind would be different, unexchangeable, and depending on what metadata they hold, they may have different perceptive values. NFTs can convey possession of off-chain or on-chain assets. For instance, the City of Miami could opt to use a chain (say Ethereum) to register property settlements. The land department will be required to make individual tokens for every single property. An NFT can (and should) hold pertinent information. In this case, the address or the geolocation coordinate can be used as information to generate ownership tokens. Real-Estate is a perfect example of off-chain assets as NFTs. With regards to the on-chain case, typical NFTs hold SVGs images and surrounding metadata inside the tokens.
Ethereum was the first chain to enable the hosting of NFTs. EIP-721 introduced the concept as a proposal of having tokens on the network to represent ownerships. The EIP (proposal), now an ERC (standard), was created in January 2018 by William Entriken, Dieter Shirley, Jacob Evans, Nastassia Sachs to have deeds on the chain. This standard defines a set of interfaces to support the creation (minting), transfer, balance and store of metadata. All Smart Contracts, which wish to allow minting of these tokens, need to have methods events defined in this ERC. The standard specifies a must implement and two optional interfaces. Developers can add additional methods too to their NFT Contracts if needed. Interfaces in the specification do not imply functions for the creation and burning(destruction) of tokens, and the developer can define them as suited.
The standard prescribes 4 Interfaces:
ERC721, The first one, which also has the standard's name, is a MUST implement for the minting contract. ERC721Metadata Metadata interface is optional and provides read methods for name, symbol and URI of the Token. The URI holds the metadata of each token, which may comply with a JSON schema. Market places like OpenSean can display NFTs because the contracts store data in this spec. ERC721Enumerable Enumerable interface allows inquiry on the Contract for ownership and supply limit of the tokens. The intention was to enable the discoverability of this type of Contract. ERC721TokenReceiver Token receiver interfaces are for wallets to implement. This interface enables senders to perform safety checks before the transfer.
An Ethereum NFT contract will generate three events:
Transfer is generated when a new token is minted or transferred to a new address Approval is emitted when a new approver address is added by the owner to a token, the approver can transfer the owner token to another account ApprovalForAll same as approval, but emitted as part of a different method that can change approvers for multiple tokens.
The main contract has these methods:
balanceOf number of tokens owned by address ownerOf returns owner of tokenId safeTransferFrom Makes a safe check before doing the transfer to a new address transferFrom transfers the token to a new address approve Adds a new address as approver for a token, can be called by token owner only setApprovalForAll sets approver to multiple tokens getApproved retrieves approver address if any isApprovedForAll checks for pending approvers
To illustrate, I have created an NFT contract, which can mint ERC-721 tokens named SIJ-tokens. This DAPP would mint tokens to hold on-chain data, will represent characters with their index as they appear in the spelling of my name, for Eg S0, I1, S6 etc. The supply is limited to seven individual and unique items.
A number ranging from zero to six would be required as input to invoke the minting function. Tokens with characters S or E would be two each in number, and thus the ones with I, J and H are rarer. I am importing OpenZepplin Contract samples here to reduce my code. Openzepplin provides contract files conforming to required standards or having reusable solutions. Importing code from this repository is a common practice in Ethereum app development. The changes required to the Contract after performing the imports were minimum. To enable external minting of tokens, a public method named Claim was added. Additionally, the "TokenURI" function was overridden to have the required metadata generation. The definition for these two methods is following in the post. Nevertheless, the whole code of the Contract is available on Etherscan. The tokenURI function will return a JSON object, which will have an SVG image to show token data
function claim(uint256 tokenId) public {
require(tokenId > 0 && tokenId < 7, "Token ID invalid");
_mint(msg.sender, tokenId);
//_setTokenURI(tokenId, tokenURI(tokenId));
}
function tokenURI(uint256 tokenId) public view virtual override returns (string memory) {
string memory tokenStr = toString(tokenId);
string[19] memory parts;
parts[0]= '<svg xmlns="http://www.w3.org/2000/svg" preserveAspectRatio="xMinYMin meet" viewBox="0 0 200 200">';
parts[1] = '<circle cx="100" cy="100" r="75" stroke="black" stroke-width="4" fill="red" />';
parts[2] ='<text x="60" y="130" fill="white" font-size="smaller">~ SIJ TOKEN ~</text>';
parts[3] ='<text x="75" y="100" fill="black" font-weight="bold" font-size="3em">';
parts[4]=characters[tokenId];
parts[5]=tokenStr;
parts[6]='</text>';
parts[7] ='</svg>';
string memory output = string(abi.encodePacked(parts[0], parts[1], parts[2], parts[3], parts[4], parts[5], parts[6], parts[7]));
string memory json = Base64.encode(
bytes(
string(
abi.encodePacked(
'{"name": "SIJ -',tokenStr, '", "description": "Awesome Collectibles - SIJ Tokens", "image": "data:image/svg+xml;base64,', Base64.encode(bytes(output)), '"}'))));
output = string(abi.encodePacked('data:application/json;base64,', json));
return output;
}
I have deployed the contract on Testnet Rinkeby, links below
Rinkeby Etherscan link - https://rinkeby.etherscan.io/address/0x6b238761c25894cba26d7a7eec54b245516c9617
Sample minted NFT - https://rinkeby.rarible.com/token/0x6b238761c25894cba26d7a7eec54b245516c9617:1?tab=details
No activity yet