Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
This documentation will help you understand how the NFT Kit works and how you can use it. However, it presumes a certain level of knowledge about Non-Fungible Tokens (NFTs) so
if you are already familiar with NFTs, you can jump to the NFT Kit.
if you are new to the world of NFTs, please continue with our introduction to Non-Fungible Tokens (NFTs).
Learn what SSI is.
In a nutshell, NFTs are non-fungible tokens which digitally represent ownership of something.
Following this definition each NFT shares at least three properties:
NFTs are “non-fungible” which means that each NFT (or token) is unique in a sense that there is no other thing just like it. In other words, each NFT is one of a kind just like there is only one painting that is the real Mona Lisa. (A fungible token, on the other hand, is not unique. It would not make any difference if a fungible token would be exchanged for another token of the same kind such as a Bitcoin.)
NFTs represent ownership which implies that an NFTs is treated as the actual thing that it stands for so that by selling an NFT you are also selling “the real thing” that it represents.
NFTs can be used to tokenize and represent anything from physical things (like a house) to natively digital assets (like a crypto punk) to ideas and intellectual property.
To understand how NFTs work, one must consider two perspectives:
The functional perspective which is about understanding the implications of NFTs for its adopters and the market, particularly what NFTs enable one to do (that could not be done without NFTs).
The technical perspective, which is about understanding the technologies on which NFTs are built and their properties which give rise to NFT’s functionality in the first place.
NFTs allow us to have digital representations of potentially anything in a way that these representations are unique, trustworthy (or at least a tamper proof record of ownership) and can be traded. We can distinguish the following roles or functionalities:
Issuers - Parties who create (“mint”) NFTs and issue (“drop”) them to someone else (“Holders”). Issuers are the original sources of an NFT. For example, artists who mint their creations as NFTs and transfers them to buyers.
Holders - Individuals or organizations who receive NFTs from someone else (but not necessarily from the original “Issuer”, considering that NFTs are transferable).
Verifiers - Parties who verify NFT ownership and metadata in order to provide access to information, services, products or other benefits, such as is the case with tickets, vouchers or other forms of memberships more generally.
Illustration of functional roles in NFT ecosystems
This section elaborates the theory behind the NFT Kit:
NFT Kit | Basics - Learn what the NFT Kit is and what it does.
NFT Flavors & Ecosystems- Learn which NFT flavors and ownership ecosystems we support.
Architecture - Explore the NFT Kit's multi-layered architecture and components.
Use Cases - Explore use cases you can implement with the NFT Kit.
NFT Kit Feature List - Explore all features in an overview list
Learn what the NFT Kit is.
The NFT Kit offers everything you need to use Non-Fungible Tokens (NFTs) with ease.
The following sections elaborate the NFT Kit's unique properties and enabled functionality.
Here are the most important things you need to know about the NFT Kit:
It is written in Kotlin/Java. It can be directly integrated (Maven/Gradle dependency) or run as RESTful web-service. A CLI tool allows you to run all functions manually.
It is open source (Apache 2). You can use the code for free and without strings attached.
It is a holistic solution that allows you to build use cases “end-to-end”. There is no need to research, combine or tweak different libraries to build pilots or production systems.
It abstracts complexity such as low-level functionality related to key handling, data storage, minting operations and interactions with third party systems.
It is customizable in a sense that you can build NFTs in all kinds of variations based on different smart contracts (e.g. ERC-721, ERC-1155) using various configurations (e.g. supply size, metadata storage).
It gives you advanced features like "soulbound" or "dynamic" NFTs or royalties.
It is modular, composable and built on open standards allowing you to customize and extend functionality with your own or third party implementations and to preventing lock-in.
It is flexible in a sense that you can deploy and run it on-premise, in your (multi) cloud environment or as a library in your application.
It enables you to use different blockchains / ecosystems - starting with EVM-compatible blockchains (e.g. Ethereum, Polygon, Binance Smart Chain, Avalanche).
Metadata is one of the core components of a NFT. We have a flexible and an abstract system to manage metadata. It can be on-chain (struct in smart contract, base64 string) or off-chain (IPFS, Arweave, centralized server).
The NFT Kit establishes an ownership infrastructure layer for any use case in any industry. Its core services are in the scope of:
Registry Interactions e.g. read, write; agnostic towards the underlying tech e.g. blockchain
Key Management e.g. generate, sign, import, export, manage lifecycle
Smart Contracts and NFT/Token e.g. create, mint, distribute, claim, verify ownership
Metadata handling e.g. on-chain or off-chain storage, look-up, verify metadata and attributes
Illustration:
The NFT Kit abstracts complexity for developers by following a "multi-stack approach" that enables you to use different implementations or "flavours" of NFT.
As a result, you can participate in different ecosystems (e.g. Ethereum, Polygon, Tezos, ...) and avoid technology-related lock-in effects.
Based on our Introduction to Non-Fungible Token (NFT), we distinguish the following concepts or building blocks, which illustrate the variety of NFT "flavours" that exists.
The architecture of the NFT Kit consists of three layers:
Low-Level Services Abstraction: Abstracts complex, low-level operations (e.g. cryptography, key management, smart contract or minting operations).
Ecosystem Abstraction: Abstracts ecosystem-specific requirements based on the relevant technical and governance frameworks of a blockchain / NFT ecosystem.
High-Level Interfaces / APIs: Provides high-level interfaces that hide complexity and facilitate usage for developers.
Also, the architecture allows for the integration of third party solutions throughout the stack. For example:
Key storage (e.g. HSM)
Data storage (e.g. IPFS)
Registries (e.g. blockchains)
This architectural openness prevents vendor lock-in and allows you to build NFT-based solutions that meet your unique requirements.
Illustration:
Read on to explore all three abstraction layers in more detail.
This software-layer holds a set of generic core services for common NFT and cryptographic functions. The services are in the scope of Smart Contract deployment, Meta Data management, Token Minting etc..
The low-level services expose common interfaces that can be conveniently utilised directly via Kotlin/Java or via the REST API (Swagger doc of the core API).
We believe in a multi-blockchain & multi-ecosystem future.
This is why we built an abstraction layer for ecosystem-specific operations and business logic. The idea is to support any ecosystem with a single solution that does not put any additional burden on developers. As a result, you can use our solutions to participate in different ecosystems without having to switch between different technical implementations.
Get started with your preferred option here.
The following is a short summary of the interfaces available. The detailed functions are described in the documentation further on.
The NFT Kit exposes high-level interfaces / APIs to hide the complex introduced by
low-level services (e.g. key management, smart contract and minting operations)
different ecosystems (i.e. different NFT flavours, business logic and governance frameworks).
The functionality of the high-level interfaces are grouped around:
Creating / Minting NFTs
Managing NFTs
Verifying NFTs (ownership, metadata)
The interfaces can be used in JVM-based applications directly, or via the REST API. Get Started
Select your ecosystem/blockchain of choice here and start exploring the REST API.
Use cases you can build with the NFT Kit.
As the world is going digital, it becomes necessary to model ownership in a digital way. NFTs allow us to do just that by encoding ownership of any type of asset in a digital format.
As a result, NFT use cases can be found wherever there’s a need to digitally model ownership. In other words, the list of use cases is long and NFTs will likely be among the most important building blocks on which the digital world (or something like a metaverse) will be built.
The following graphic shows a range of NFT use cases across different industries to illustrate the potential of NFTs:
You can use the NFT Kit to enable your users, customers, employees or partners to create and manage any form of ownership (whether it's about a physical good, or digital items). This allows businesses to create digital ownership documents that are very hard to counterfeit but easy to verify, which makes the user experience more secure and enjoyable.
Decoupling the access to a product or service from a users’ identity is also possible as access can be given to the owner of a specific NFT only without having to know the identity of this owner in advance. The following categories show more specific use cases and examples.
The most famous NFT use case is certainly digital art. With NFTs, artist have the ability to create digital scarcity and thus sell their digital art as NFT. The creator economy also includes fashion brands that uses NFT as a "digital twin" of a physical product that a customer bought. In the luxury industries, NFT can also be used to issue authenticity certificates.
Entertainment is a big industry for NFTs. They can be used to represent items in video games which makes the players the true owners of those NFT gaming items, while allowing them to trade them and even use them in another video game or another context. Another use case that is becoming more and more popular is ticketing. When NFTs are used for ticketing, it allows a better management of events ticket because they are on a public blockchain with a high level of traceability, but it also reduces fraud because users can verify that the NFT they are buying is authentic. Lastly, NFT ticketing also provides consumers with a better user experience.
Similar tho the ticketing use case for events, NFT can be use to represent airplane or any public transport tickets; but also membership cards to access any services and transport.
Loyalty program, exclusive content and vouchers are 3 practical use cases for NFTs in the Tourism and Travel industry. They are a great way to engage guests in a digital and interactive way as well as rewarding them.
Thanks to its traceability characteristic, NFT are of course perfectly designed for Supply Chain usage. Product tracking and product authenticity is made easy when physical products are associated with NFTs.
Digital art can be monetized by making unique digital assets that can have exclusive properties, on top of being easily sold or rented. In DeFi (Decentralized Finance), art NFTs can also be used as collateral for a loan
In a similar way to digital art, musicians and singers can link their music to NFTs which makes it possible to own a piece of a song or album and receive royalties from it.
Event organizers may issue event tickets using NFT, as it would avoid fraud (by providing an easy way to verify tickets), but it would also allow for a better traceability of all the tickets that are resold.
Property ownership documents can also be made (created and issued) via NFTs which would represent a digital and immutable certificate of ownership of a physical real estate property. In another fashion, NFTs are also used to represent virtual properties.
Items in online games can now be truly owned by the players, which offers many new possibilities such as selling and buying items outside of a game’s centralized marketplace, but also using those items in other digital environments like in other games.
Similar to the property ownership documents for the real estate use case, NFTs can also be used to prove the authenticity of any other physical products, such as clothing items, jewelry, cars, etc.
Foundations and charities have already started to raise money by selling their own NFT collection, but crowdfunding platforms are now challenged by NFTs as it allows startups to raise funds in a peer to peer way.
If you have any questions, feel free to get in touch.
Improving the base functionalities of smart contract standards with Extensions.
Pause token transfers, minting and burning.
Path parameter:
chain
: chain to work with.
Main chains: ETHEREUM, POLYGON
Testnet chains: SEPOLIA, GOERLI, MUMBAI, SHIMMEREVM
contract
: smart contract address
Path parameter:
chain
: chain to work with.
Main chains: ETHEREUM, POLYGON
Testnet chains: SEPOLIA, GOERLI, MUMBAI
contract
: smart contract address
Path parameter:
chain
: chain to work with.
Main chains: ETHEREUM, POLYGON
Testnet chains: SEPOLIA, GOERLI, MUMBAI, SHIMMEREVM
contract
: smart contract address
Pause token burning.
Path parameter:
chain
: chain to work with.
Main chains: ETHEREUM, POLYGON
Testnet chains: SEPOLIA, GOERLI, MUMBAI, SHIMMEREVM
contract
: smart contract address
Path parameter:
chain
: chain to work with.
Main chains: ETHEREUM, POLYGON
Testnet chains: SEPOLIA, GOERLI, MUMBAI, SHIMMEREVM
contract
: smart contract address
burnable
: [boolean] set to true
if you want to activate the burn token feature and false
if not.
Path parameter:
chain
: chain to work with.
Main chains: ETHEREUM, POLYGON
Testnet chains: SEPOLIA, GOERLI, MUMBAI, SHIMMEREVM
contract
: smart contract address
token
: token ID
Path parameter:
chain
: chain to work with.
Main chains: ETHEREUM, POLYGON
Testnet chains: SEPOLIA, GOERLI, MUMBAI, SHIMMEREVM
contract
: smart contract address
token
: token ID
signedAccount
: the account used to sign the transaction.
metadataUri
: [string] metadata URI of the token.If you want to generate metadata URI using NFT KIT, set the "metadataUri "value as an empty string.
metadata
: NFT KIT will use values inside metadata to generate metadata URI of the token. It confirms the structure defined by ERC721 and ERC1155 standards. For more details about NFT metadata standard.
description
: [string] a description of the token
name
: [string] the name of this specific token
image
: [string] this is the URL to the image of the item. Can be just about any type of image and can be IPFS URLs or paths.
image_data
: [string] Raw SVG image data, if you want to generate images on the fly (not recommended). Only use this if you're not including the image parameter.
external_url
: [string] This is the URL that will appear below the asset's image on OpenSea and will allow users to leave OpenSea and view the item on your site.
attributes
: [string] To give your items a little more pizazz, we also allow you to add custom "attributes" to your metadata that will show up underneath each of your assets.
trait_type
: [string] the name of the trait
value
: [string] the value of the trait
Getting started with the NFT-Kit.
The NFT Kit offers everything you need to use Non-Fungible Tokens (NFTs) with ease on different ecosystems. Chose yours and get started.
Learn how to setup the NFT-Kit on your local system
Do you want to build using our APIs or add the NFT-Kits functionalities as a direct dependency in a Kotlin/Java application
Make sure you have Docker or a JDK 16 build environment including Gradle installed on your machine
Clone the project
2. Change the folder
4. Building the docker container
5. Running the container
Clone the project
2. Change the folder
4. Build the project
5. Run the executable
In build/distributions/
you have two archives, a .tar, and a .zip.
Extract the one that is built for your system and run it.
Gradle
Maven
Required Maven repos:
In this section, we have a set of APIs that help you verify ownership or traits of an NFT, making ownership-based access management possible.
You can use this API to verify if an account is the real owner of an NFT.
Path parameter:
chain
: chain to work with.
Main chains: ETHEREUM, POLYGON
Testnet chains: SEPOLIA, GOERLI, MUMBAI, SHIMMEREVM
contract
: smart contract address
account
: [string] the NFT owner address.
tokenId
: [string] the NFT token ID.
The verification process can be based on NFT ownership and metadata traits.
Path parameter:
chain
: chain to work with.
Main chains: ETHEREUM, POLYGON
Testnet chains: SEPOLIA, GOERLI, MUMBAI, SHIMMEREVM
contract
: smart contract address
account
: [string] the NFT owner address.
tokenId
: [string] the NFT token ID.
traitType
: [string] the name of the trait that you want to verify..
traitValue
: [string] the trait value.
Description of the main functions to manage NFTs: smart contract deployment, minting tokens, etc.
The NFT-Kit supports the ERC-721 standard with the option to be deployed as regular contract for NFTs or modified for Soulbound Tokens.
Do you want to modify your contract further? Have a look at our Smart Contract Extension Sections:
Path parameter:
chain
: chain to work with.
Main chains: ETHEREUM, POLYGON
Testnet chains: SEPOLIA, GOERLI, MUMBAI, SHIMMEREVM
After you have successflully deployed the contract, you can start minting NFTs to your users.
name
: [string] the human-readable name of the contract.
symbol
: [string] the abbreviated symbol of the contract.
tokenStandard
: [string] NFTs smart contract standard. Supported values: ERC721.
transferable
: [boolean] activate/deactivate token transfer.
burnable
: [boolean] activate/deactivate token burn.
Path parameter:
chain
: chain to work with.
Main chains: ETHEREUM, POLYGON
Testnet chains: SEPOLIA, GOERLI, MUMBAI, SHIMMEREVM
After you have successflully deployed the contract, you can start minting NFTs to your users.
name
: [string] the human-readable name of the contract.
symbol
: [string] the abbreviated symbol of the contract.
tokenStandard
: [string] NFTs smart contract standard. Supported values: ERC721.
transferable
: [boolean] in order to make sure a soulbound token contract is created we need to set this option to false otherwise it will create a regular NFT contract as shown in the section above.
burnable
: [boolean] activate/deactivate token burn.
It is a rich API to mint a new NFT token. It manages NFT metadata in multiple ways. You can generate token URI by yourself or let the NFT KIT generate it.
Path parameter:
chain
: chain to work with.
Main chains: ETHEREUM, POLYGON
Testnet chains: SEPOLIA, GOERLI, MUMBAI, SHIMMEREVM
contract
: smart contract address
metadataUri
: [string] metadata URI of the new token.If you want to generate metadata URI using NFT KIT, set the "metadataUri "value as an empty string.
description
: [string] a description of the token
name
: [string] the name of this specific token
image
: [string] this is the URL to the image of the item. Can be just about any type of image and can be IPFS URLs or paths.
image_data
: [string] Raw SVG image data, if you want to generate images on the fly (not recommended). Only use this if you're not including the image parameter.
external_url
: [string] This is the URL that will appear below the asset's image on OpenSea and will allow users to leave OpenSea and view the item on your site.
attributes
: [string] To give your items a little more pizazz, we also allow you to add custom "attributes" to your metadata that will show up underneath each of your assets.
trait_type
: [string] the name of the trait
value
: [string] the value of the trait
recipientAddress
: [string] the account address who will receive the NFT
metadataStorageType
: [string] when you let the NFT KIT to generate metadata URI, you need to specify how the metadata will be stored. Supported values: ON_CHAIN, OFF_CHAIN. You can use ON_CHAIN if you want to store NFT metadata on the chain. You can use OFF_CHAIN if you want store NFT metadata off chain using IPFS.
Owner of a soul bound NFT smart contract , can revoke a minted Token.
Path parameter:
chain
: chain to work with.
Main chains: ETHEREUM, POLYGON
Testnet chains: SEPOLIA, GOERLI, MUMBAI, SHIMMEREVM
contract
: smart contract address
token
: token ID
Find out more information about your NFTs with the following actions.
Path parameter:
chain
: chain to work with.
Main chains: ETHEREUM, POLYGON
Testnet chains: SEPOLIA, GOERLI, MUMBAI, SHIMMEREVM
contract
: smart contract address
token
: token ID
Path parameter:
chain
: chain to work with.
Main chains: ETHEREUM, POLYGON
Testnet chains: SEPOLIA, GOERLI, MUMBAI, SHIMMEREVM
contract
: smart contract address
token
: token ID
Path parameter:
chain
: chain to work with.
Main chains: ETHEREUM, POLYGON
Testnet chains: SEPOLIA, GOERLI, MUMBAI, SHIMMEREVM
contract
: smart contract address
token
: token ID
key
: [string] the name of the metadata attribute that you want to update.
value
: [string] the new value of the attribute
Path parameter:
chain
: chain to work with.
Main chains: ETHEREUM, POLYGON
Testnet chains: SEPOLIA, GOERLI, MUMBAI, SHIMMEREVM
contract
: smart contract address
owner
: account address
Path parameter:
chain
: chain to work with.
Main chains: ETHEREUM, POLYGON
Testnet chains: SEPOLIA, GOERLI, MUMBAI, SHIMMEREVM
contract
: smart contract address
token
: token ID
Path parameter:
chain
: chain to work with.
Main chains: ETHEREUM, POLYGON
Testnet chains: SEPOLIA, GOERLI, MUMBAI, SHIMMEREVM
contract
: smart contract address
It will return a list of all NFTs which are associated with the provided account address.
Path parameter:
chain
: chain to work with.
Main chains: ETHEREUM, POLYGON
Testnet chains: SEPOLIA, GOERLI, MUMBAI, SHIMMEREVM
owner
: account address
If you want to learn more about the NFT-Kit architecture and the general ideas? Visit the .
- How to use the NFT-Kit
- How to deploy Smart Contracts and mint NFTs
- How to verify NFT ownership within a collection and traits
- Pause token transfers, minting and burning
- Access Control functionalities
3. your project
3. your project
- How to deploy Smart Contracts and mint NFTs
- How to verify NFT ownership within a collection and traits
- Pause token transfers, minting and burning
- Access Control functionalities
- How to deploy Smart Contracts and mint NFTs
- How to verify NFT ownership within a collection and traits
- Pause token transfers, minting and burning
- Access Control functionalities
|
|
- Pause token minting and burning.
Enable role-based access control
Ensure that the is configured with the appropriate gasPrice and gasLimit based on current market conditions prior to smart contract deployment, to ensure successful transactions.
accessControl
: [string] access control approach for the smart contract. Supported values: OWNABLE, ROLE_BASED_ACCESS_CONTROL. For more details about approaches.
Ensure that the is configured with the appropriate gasPrice and gasLimit based on current market conditions prior to smart contract deployment, to ensure successful transactions. In the contract deployment call we set the transferable option to false, which deploys a soulbound token contract. This contract prevents any token transfers after the initial mint.
accessControl
: [string] access control approach for the smart contract. Supported values: OWNABLE, ROLE_BASED_ACCESS_CONTROL. For more details about approaches.
Ensure that the is configured with the appropriate gasPrice and gasLimit based on current market conditions prior to minting, to ensure successful transactions.
metadata
: NFT KIT will use values inside metadata to generate metadata URI of the new token. It confirms the structure defined by ERC721 and ERC1155 standards. For more details about .
Managing a required us to update the NFT metadata
You will learn how you can use the NFT Kit to verify the ownership and properties of Ocean protocol's (V4) ERC721 data NFT.
Ocean protocol V4 data NFTs have a specialized Smart Contract architecture to handle data or intellectual property related use cases. Therefore, the NFT Kit was extended with special interfaces to deploy contracts, mint tokens and most importantly to verify the ownership of data NFTs. Learn more in detail how things were implemented in the architecture section.
Deep dive
Setup - How to use the NFT-Kit
NFT | Verification - How to verify NFT ownership and properties in the metadata
NFT | Wallet - View NFTs via a Web-Wallet
Architecture - See how the Ocean Protocol was integrated into the NFT-Kit
The following example shows an OCEAN Data NFT minted by a contract from our own deployed contract factory on MUMBAI.
Visit the wallet
Proof of State Blockchain - Open-Source, Self-Upgradable, Energy-Efficient
Tezos is an open-source, self-upgradable, energy-efficient and built to last Proof of Stake blockchain protocol for assets and applications, backed by a global community of validators, researchers, and builders. Tezos will drive social, political and economic innovation on a global scale.
Depending on your preference, start exploring with the deep dive or a tutorial.
Deep dive
Architecture - See how Tezos was integrated into the NFT-Kit
NFT | Minting - How to deploy Smart Contracts and mint NFTs
NFT | Ownership - How to verify NFT ownership within a collection and traits
NFT | Wallet - View NFTs via a Web-Wallet
Tutorials
Minting NFTs on Tezos - Deploy a contract, mint, validate and view an NFT in a web wallet
Tezos offers a platform to create smart contracts and build decentralized applications, that cannot be censored or shut-down by third parties. Furthermore, Tezos facilitates formal verification, a technique used to improve security by mathematically proving properties about programs such as smart contracts. This technique, if used properly, can help avoid costly bugs and the contentious debates that follow.
Tezos + NFT-Kit Integration Diagramm
This diagram resume the integration of Tezos ecosystem in our NFT Kit. Tezos is rich ecosystem, theirs is flexibility in the integration of a such ecosystem. You can use our product either using REST APIs our as a library.
In general, there are two types of interactions: reading or writing from the Tezos blockchain.
For the writing operation, you need the smart contract (address or code), private key to sign operation, and an RPC connection. The NFT Kit will take care of the operation signing with the specified private key. Then, send the operation the the specified network(Mainnet or Testnet).
For reading operation, We use a Tezos indexer. We are making queries to TzKT API.
The smart contract is developed using the Archetype high-level programming language. We use FA2 Tezos standard.
Using our wallet, you can fetch and list your NFTs on Tezos blockchain.
Step1: Click on "Connect Tezos wallet" button.
Step 2: Choose an account.
Step 3: You will have the list of your NFTs in the main Tezos chain.
Step 4: You can switch between networks. Choose another network.
Step 5: You will have the list of your NFTs on the selected network.
Step 6: Click on the NFT you want to see their details.
Before we can start with configuring our NFT collection, we need to clone and run the NFT-Kits REST API on our machine.
Make sure you have a JDK 16 build environment including Gradle installed on your machine
Make sure you have a Node.js and the npm installed on your machine.
Clone the project
2. Change the folder
3. Put the configuration needed by the file under the path: js/.env
of the project
4. Run the following command:
4. Run the following command:
5. Open new terminal under the path: waltid-nftkit
6. Make the rest of the configuration
7. Build the project
8. Run the executable
In build/distributions/
you have two archives, a .tar, and a .zip.
Extract the one that is built for your system and run it.
Now we can visit the REST API at the endpoint displayed in the terminal after running the project. In the next section, we will be configuring our NFT collection and deploy the Smart Contract on Tezos.
How to mint NFTs on Tezos
In this tutorial with 5 modules, we will create our first Tezos NFT collection, mint one of the NFTs to our address, learn how to verify ownership + metadata and how to admire the minted token in a web wallet.
Setup - Clone and run the NFT-Kit
A new collection - Configurations and Deployment of the NFT Smart Contract
First NFT - Minting of the collection NFTs
Verification - How to verify NFT ownership + metadata fields
Wallet - Viewing the NFT in a web-wallet
The NEAR protocol is a sharded, proof-of-stake, layer-one blockchain that is simple to use, secure and scalable.
NEAR Protocol is a public Proof-of-Stake (PoS) blockchain that aims to bring DeFi to the masses with low transfer fees and fast transactions. NEAR competes with Avalanche, Solana, Cardano, Algorand, the new version of Ethereum, and other PoS networks.
Depending on your preference, start exploring with the deep dive or a tutorial.
Deep dive
Architecture - See how Near was integrated into the NFT-Kit
NFT | Minting - How to deploy Smart Contracts and mint NFTs
NFT | Ownership - How to verify NFT ownership within a collection and traits
NFT | Wallet - View NFTs via a Web-Wallet
Tutorials
Mint an NFT - Learn how to mint an NFT on Near using the REST interface
Verify NFT Ownership - Learn how to verify NFT ownership on Near using the REST interface
On Near Protocol , NFTs are not stored in the user's wallet, instead, each NFT lives in a NFT contract. The NFT contract works as a bookkeeper, this is: it is in charge of handling the creation, storage and transfers of NFTs.
In order for a contract to be considered a NFT-contract it has to follow the NEP-171 and NEP-177 standards. The NEP-171 & NEP-177 standards explain the minimum interface required to be implemented, as well as the expected functionality.
Swagger Doc | ReDoc
Path parameters:
chain
: [string] chain to work with. Either testnet
or mainnet
.
account_id
:[string] your account.
Body Details:
Body parameters:
spec
: a string that MUST be formatted nft-n.n.n
where "n.n.n" is replaced with the implemented version of this Metadata spec.
name
: the human-readable name of the contract.
symbol
: the abbreviated symbol of the contract.
icon
: a small image associated with this contract. Encouraged to be a data URL.
base_uri
: Centralized gateway known to have reliable access to decentralized storage assets referenced by reference
or media
URLs. Can be used by other frontends for initial retrieval of assets, even if these frontends then replicate the data to their own decentralized nodes, which they are encouraged to do.
NFTs (Non-Fungible Tokens) are a type of digital asset that are stored on a blockchain network and represent unique items or pieces of content. NFTs are typically used to represent things like artwork, music, videos, or other types of creative works, as they allow creators to verify and authenticate the ownership and provenance of their creations.
On the Near Protocol, NFTs are created and managed through smart contracts that are stored on the blockchain. These contracts define the rules and logic for how the NFTs are created, transferred, and managed.
To create an NFT on the Near Protocol, you would first need to create a smart contract that defines the NFT's properties and behaviors. This contract would typically include things like the NFT's name, description, image, and any other relevant metadata.
Once the NFT contract is deployed to the blockchain, you can then use it to mint new NFTs. To mint an NFT, you would typically need to provide some sort of payment, such as Near tokens, in exchange for the new NFT.
Once the NFT is minted, it can be transferred and traded just like any other asset on the blockchain. The unique properties of NFTs, such as their provenance and authenticity, make them particularly valuable for creators and collectors of digital content.
Minting NFTs
Ownership verification
Wallet integration
Using our , you can fetch and list your NFTs on Polkadot blockchain.
Flow Blockchain is a permission-less layer 1 blockchain, empowering developers to create limitless Web3 apps for mainstream adoption.
Architecture - Learn how Flow was integrated into the NFT-Kit
NFT | Metadata - Query NFT information
NFT | Ownership - How to verify NFT ownership within a collection and traits
NFT | Wallet - View NFTs via a Web-Wallet
Cadence is a programming language designed for developing smart contracts in a blockchain environment. It introduces new features to smart contract programming that help developers ensure that their code is safe, secure, clear, and approachable. Cadence utilizes a strong static type system, resource-oriented programming, built-in pre- and post-conditions for functions and transactions, and capability-based security. Its syntax is inspired by popular modern general-purpose programming languages such as Swift, Kotlin, and Rust. Cadence aims to be safe and secure, clear, approachable, and developer-friendly. It makes use of resources to intuit ownership, which is tied to the account that owns it, ensuring that assets can only exist in one location at a time and cannot be copied or lost due to a coding mistake. The language addresses challenges with existing languages, such as safety and security concerns due to the immutable nature of blockchains and the lack of support for modifying or updating smart contracts.
In the Flow blockchain, the concept of "capabilities" is used to enforce access control and ensure security. A capability is an object that represents a specific permission to access a resource, such as a smart contract or a resource stored in an account.
In Flow, capabilities are created and owned by the resource itself, and can only be passed to other accounts or contracts through a special "borrow" mechanism. This mechanism ensures that access to a resource can only be granted by the owner of the resource, and that the permission to access the resource is explicitly granted on a per-resource basis.
Capabilities are also used to limit the scope of access to a resource. For example, a capability can be created that allows read-only access to a resource, or that only allows access to a specific function or method within a resource. By limiting the scope of access in this way, capabilities help to prevent unintended or malicious access to resources and reduce the risk of attacks.
Overall, the use of capabilities in Flow provides a flexible and secure access control mechanism that is well-suited to the needs of decentralized applications and smart contracts.
NFTs are digital assets that represent ownership of a unique asset and are indivisible. Cadence, the smart contract language on Flow blockchain, represents NFTs as a resource object stored in user accounts. This ensures NFTs benefit from resource ownership rules, protecting them from accidental or malicious programming errors.
NFTs allow for the trading of assets and proving of ownership, and on Flow, NFTs are interoperable across different smart contracts and app contexts. All NFTs on Flow implement the NFT Token Standard, defining a basic set of properties.
The NonFungibleToken
contract defines the following set of functionality that must be included in each implementation.
Contracts that implement the NonFungibleToken
interface are required to implement two resource interfaces:
NFT
- A resource that describes the structure of a single NFT.
Collection
- A resource that can hold multiple NFTs of the same type.
Users typically store one collection per NFT type, saved at a well-known location in their account storage.
For example, all NBA Top Shot Moments owned by a single user are held in a TopShot.Collection
stored in their account at the path /storage/MomentCollection
.
Return a list of NFTs in a Collection
using the getIDs
function.
This function is available on the NonFungibleToken.CollectionPublic
interface, which accounts publish as public capability.
NFT metadata is represented in a flexible and modular way using the standard proposed in FLIP-0636.
When writing an NFT contract, you should implement the MetadataViews.Resolver
interface, which allows your NFT to implement one or more metadata types called views.
Each view represents a different type of metadata, such as an on-chain creator biography or an off-chain video clip. Views do not specify or require how to store your metadata, they only specify the format to query and return them, so projects can still be flexible with how they store their data.
The NonFungibleToken
and MetadataViews
contracts are already deployed on various networks. You can import them in your contracts from these addresses. There is no need to deploy them yourself.
Note: With the emulator, you must use the -contracts flag to deploy these contracts.
This example shows how to read basic information about an NFT including the name, description, image and owner.
Source: get_nft_metadata.cdc
The views categorized as "Core views" are deemed as the essential views that must be included to offer a comprehensive representation of an NFT. If you intend to have your NFT displayed on the Flow NFT Catalog, it is mandatory to have all of these views implemented.
The NFT Catalog is a registry that resides on the blockchain and catalogs the NFT collections available on Flow blockchain that conform to the NFT metadata standard. This enables developers of decentralized applications to conveniently develop on top of and find compatible NFT collections on Flow.
NFTCatalog.cdc
: This contract contains the NFT Catalog
NFTRetrieval.cdc
: This contract contains helper functions to make it easier to discover NFTs within accounts and from the catalog
Network | Contract Address |
---|---|
Network | Address |
---|---|
Network | Address |
---|---|
Emulator/Canary
0xf8d6e0586b0a20c7
Testnet
0x631e88ae7f1d7c20
Mainnet
0x1d7e57aa55817448
Mainnet
0x49a7cda3a1eecc29
Testnet
0x324c34e1c517e4db
Mainnet
0x49a7cda3a1eecc29
Testnet
0x324c34e1c517e4db
🖼️
Get NFTs for Account
📌
Get NFTs in Collection
🚀
Get NFT by Token id
Algorand is a blockchain platform. It offers a secure, scalable, and decentralized infrastructure for developing decentralized applications (DApps).
Algorand utilizes a consensus algorithm called Pure Proof-of-Stake (PPoS), which ensures security and scalability while eliminating energy-intensive mining. The platform can handle high transaction throughput with low latency, processing thousands of transactions per second.
Architecture - See how Algorand was integrated into the NFT-Kit
NFT | Creation - How to create NFTs using the Algorand Standard Assets (ASAs)
NFT | Ownership - How to verify NFT ownership
The Algorand protocol enables the creation of on-chain assets that enjoy the same level of security, compatibility, speed, and user-friendliness as the Algo cryptocurrency. These assets are officially known as Algorand Standard Assets (ASA). ASA allows for the representation of various assets, including stablecoins, loyalty points, system credits, in-game points, and more. It also enables the representation of unique assets such as property deeds, collectible items, specific components in a supply chain, and others.
Algorand Standard Assets (ASAs) are utilized to create Non-Fungible Tokens (NFTs) within the Algorand blockchain. ASAs are integrated into the protocol itself and can be generated through a specific type of transaction, distinguishing it from other blockchains that require smart contracts for asset representation. To create an NFT, only a few parameters need to be specified to designate it as such and establish a link to the metadata. This metadata provides potential owners with the necessary information to verify the asset's integrity. For example, setting the total amount of units to 1 and the number of decimals to 0 ensures the creation of a single, indivisible unit of the ASA. For proper formatting of NFT properties, the Algorand community adheres to the standards outlined in the Algorand Request for Comments. The creation transaction for such an asset can be implemented using any of Algorand's SDKs, in our case we will be using the java sdk.
ARC-3 is the official Algorand Standard Asset Parameters Conventions for Fungible and Non-Fungible Tokens. It provides a standard for specifying ASA metadata, including asset name, unit name, and other properties. ARC-3 is more general and can be applied to both fungible and non-fungible tokens.
Asset Name: The asset name is either arc3
or suffixed by @arc3
. This allows client software to know when an asset follows the ARC-3 conventions.
JSON Metadata File Schema: ARC-3 introduces a JSON Metadata File Schema that allows indicating the MIME type of the files pointed by any URI field. This helps clients to display the resource appropriately without having to first query it to find out the MIME type.
Asset Integrity: A digest of the JSON Metadata file is included in the ASA parameters to ensure the integrity of this file. This is important to ensure the integrity of the JSON file when IPFS is not used.
MIME Type Fields: MIME type fields are added to help clients know how to display the files pointed by URI.
Relative URI Support: Support for relative URI is added to allow storing both the JSON Metadata files and the files it refers to in the same IPFS directory.
Asset Configuration: Asset Name and Asset Unit can be optionally specified in the ASA parameters. This allows wallets that are not aware of ARC-3 or that are not able to retrieve the JSON file to still display meaningful information.
ARC-69 is an unofficial Algorand Standard Asset Parameters Convention popular in the Algorand NFT community. It is inspired by Open Sea's metadata standards and EIP-1155. ARC-69 focuses on optimization for fetching digital media and the use of on-chain metadata. It also allows for mutable or immutable metadata, depending on the use case.
Asset Name, Unit Name, and URL: These are specified in the ASA parameters. This allows applications to efficiently display meaningful information, even if they aren't aware of ARC-69 metadata.
MIME types: These help clients more effectively fetch and render media.
Metadata: All asset metadata is stored on-chain. Metadata can be either mutable or immutable. If an ASA has a manager address, then the manager may update an ASA's ARC-69 metadata by sending a new acfg
transaction with the entire metadata represented as JSON in the transaction's note
field.
SBTs are non-transferable digital tokens containing information about a person or entity.
SBTs are non-transferable unique digital tokens. They are issued once to an address, which could be owned by an individual or entity, stating information or accomplishments about the address owner.
Use-Cases of SBTs:
Proof Of Personhood, e.g through verification of a phone number.
Proof Of Attendance, e.g. proofing that an individual attended an event.
Proof Of Steps Completed e.g. that the owner went through an KYC process successfully.
However, the data stored in SBTs should never include sensible personal information. For that, Verifiable Credentials and mdocs are a much better fit, because here, no sensible data is stored on the blockchain. A privacy requirement in many countries. Read more about it our post about SSI vs. NFTs
Nonetheless, the SBTs offer great utility for many different use-cases, like reputation building and more.
Leveraging the walt.id open-source products, you can mint and verify SBTs and create wallet solutions where users can view their digital tokens.
Deploy SBT smart contracts directly via Java, Kotlin or our REST interface on different EVM chains, thereunder:
Ethereum
Polygon
Shimmer
Deploy your first SBT Smart Contract and start minting SBTs.
Verify SBT ownership, metadata and more using REST endpoints for common use-cases or more complex ones by creating dynamic verification policies with the Open-Policy-Agent (OPA) and the REGO language.
Start verifying SBTs here or learn about dynamic verification policies with OPA.
Web2 Login
You can also enable Login In Web2 by launching your own decentralised identity provider that can be integrated with popular identity and access management tools like Keycloak or Auth0. Read more about it here.
Wallet Solution
Extend your application with SBT viewing capabilities and web3 login using our wallet-kit.
Learn about the technologies and concepts on which SSI is based.
Understanding NFTs from a technological perspective requires the understanding of a few core concepts:
Registries, typically blockchains, which serve as a shared and trusted record of information. They serve as a “layer of trust” and a “single source of truth”.
Cryptographic keys, which convey control over NFTs and enable other crucial functionality such as authentication.
Token IDs, which are used to distinguish NFTs on a blockchain such that each token ID is linked to a unique address (establishing a public key infrastructure) and to metadata. This way different parties can easily find and interact with each other as well as benefit from blockchains’ unique properties like immutability.
Metadata, which can be anything like a piece of digital art or a digital representation of a physical asset. Importantly, metadata can be stored on-chain or off-chain.
Smart contracts, which can be thought of as the programs or apps that run on a blockchain and are responsible for minting NFTs.
Wallets, which are used to store keys or potentially even metadata. Also, they enable the management and sharing of NFTs via easy-to-use applications.
Illustration of main technical concepts related to NFTs:
One can think of these core concepts as different building blocks that are available in different variations and can be put together in different ways. For example:
Different blockchains (or other distributed ledger technologies) can be used to establish Registries (e.g. Ethereum, Polygon, Solana, Avalanche, Polkadot, Tezos, IOTA). Similarly, NFT metadata can be stored in different ways such as on blockchains, other distributed data storage protocols (e.g. IPFS, filecoin) or even traditional databases. Similarly, different smart contract development standards with different strengths and weaknesses can be used (e.g. ERC-721 or ERC-1155 for EVM compatible chains like Ethereum).
As a result, there are many different “flavors” of NFTs depending on which variations of which building blocks have been used and how they have been put together.
Learn how to use Ocean Protocols Data NFTs in your solutions
Do you want to build using our APIs or add the NFT-Kits functionalities as a direct dependency in a Kotlin/Java application
Make sure you have Docker or a JDK 16 build environment including Gradle installed on your machine
Clone the project
2. Change the folder
3. Configure your project
4. Building the docker container
5. Running the container
Clone the project
2. Change the folder
3. Configure your project
4. Build the project
5. Run the executable
In build/distributions/
you have two archives, a .tar, and a .zip.
Extract the one that is built for your system and run it.
NFT | Verification - How to verify NFT ownership and properties in the metadata
NFT | Wallet - View NFTs via a Web-Wallet
Architecture - See how the Ocean Protocol was integrated into the NFT-Kit
Gradle
Maven
Required Maven repos:
NFT | Verification - How to verify NFT ownership and properties in the metadata
NFT | Wallet - View NFTs via a Web-Wallet
Architecture - See how the Ocean Protocol was integrated into the NFT-Kit
API
Get started building with our API endpoints
Kotlin/Java SDK
Add the NFT-Kits functionality as a direct dependency
Learn about Non-Fungible Tokens (NFTs).
Welcome to our introduction to Non-Fungible Tokens (NFTs) for developers and technical readers.
Before you get started, feel free to explore other (less technical) resources that will help you and your team to get a more holistic understanding of NFTs and digital assets in general:
The access control of your contract is an important concept that governs many features provided by your smart contract.
Almost every smart contract must have an access control mechanism. We provide two:
Ownership
Role-Based Access Control
"Ownership" is a simple approach to set up access control within your smart contract. You can easily provide the "accessControl" property with "OWNABLE" during deployment to get started. Thereby, the restricted areas of the contract can only be called by the owner of the contract.
Path parameter:
chain
: chain to work with.
Main chains: ETHEREUM, POLYGON
Testnet chains: RINKEBY, ROPSTEN, MUMBAI, SHIMMEREVM
contract
: smart contract address
Path parameter:
chain
: chain to work with.
Main chains: ETHEREUM, POLYGON
Testnet chains: RINKEBY, ROPSTEN, MUMBAI, SHIMMEREVM
contract
: smart contract address
account
: [string] the new owner address.
Path parameter:
chain
: chain to work with.
Main chains: ETHEREUM, POLYGON
Testnet chains: RINKEBY, ROPSTEN, MUMBAI, SHIMMEREVM
contract
: smart contract address
"Role-Based Access Control" is a more complex approach than "Ownership" to manage access control. With this approach, you can define a hierarchy of roles, each allowed to perform a different set of actions. You can also assign multiple accounts to each role.
Path parameter:
chain
: chain to work with.
Main chains: ETHEREUM, POLYGON
Testnet chains: RINKEBY, ROPSTEN, MUMBAI, SHIMMEREVM
contract
: smart contract address
account
: an account address
role
: role name
Path parameter:
chain
: chain to work with.
Main chains: ETHEREUM, POLYGON
Testnet chains: RINKEBY, ROPSTEN, MUMBAI, SHIMMEREVM
contract
: smart contract address
role
: role name
Path parameter:
chain
: chain to work with.
Main chains: ETHEREUM, POLYGON
Testnet chains: RINKEBY, ROPSTEN, MUMBAI, SHIMMEREVM
contract
: smart contract address
role
: [string] the role you want to grant to the specified account.
account
: [string] an account address.
Path parameter:
chain
: chain to work with.
Main chains: ETHEREUM, POLYGON
Testnet chains: SEPOLIA, GOERLI, MUMBAI, SHIMMEREVM
contract
: smart contract address
role
: [string] the role you want to revoke from the specified account.
account
: [string] an account address.
Path parameter:
chain
: chain to work with.
Main chains: ETHEREUM, POLYGON
Testnet chains: SEPOLIA, GOERLI, MUMBAI, SHIMMEREVM
contract
: smart contract address
role
: [string] the role you want to renounce from the specified account.
account
: [string] an account address.
The goal of the NFT Kit is to provide a simple library and web service for NFT-based access management. Therefore the ownership of NFTs, aligned with OCEAN protocols specifications, must be verified.
The library provides a VerificationService which exposed the method dataNftVerification that takes the following parameter:
chain: the EVM-compatible chain name or chain ID
factorycontractAddress: The address of the factory contract
erc721contractAddress: The address of the custom contract
account: The account to be verified
propertyKey: The NFT meta data property key that should exist
propertyValue: The NFT meta data property value that should exist
The verification function is shown in the following screenshot.
A test deployment of the NFT kit and the oceanDao data NFT verification API can be accessed here https://nftkit.walt.id/nftkit/swagger#/NFT%20verification/OceanDaoVerification
In the verification process, the NFT is fetched from the chain per contract and account address, and it is checked if it was created by the particular factory contract and if the properties match. Note the properties might be any key/value pair of the JSON-structure. Either of the main data or of the nested structures (e.g. traits). By implementing the property-based validation in this generic way the NFT kit is future proof for any modifications to the meta data.
NFTs verification enables multiple use cases. The NFT Kit provides numerous approaches to verify the ownership of the NFTs and that the NFTs have customized properties.
1- You can verify that an account owns a particular NFT.
2- You can verify that an account owns an NFT in a specific collection.
3- You can verify that an account owns a particular NFT with a specific NFT metadata property.
4- You can also verify that an NFT metadata confirms a policy. The policy is implemented using the high-level declarative language called Rego. It is based on open policy agent(OPA).
You need to add new policy:
Then, you can apply the policy to any NFT metadata.
Now, you're able to mint your first NFT. We will use the deployed smart contract in the previous section to mint a new NFT. Every NFT must have metadata. Using the NFT Kit, you have two options to provide the NFT metadata. Either give the metadata URI directly or let the NFT Kit generate the metadata URI based on IPFS. This tutorial will provide the metadata and let the NFT Kit generate the metadata URI.
We also need to provide the token id and the recipient account for the NFT.
The amount parameter must be an empty string because the type of the deployed smart contract is "SINGLE". If you use the "MULTIPLE" smart contract type, you should provide the number of copies of the minted NFT.
Unlike typical ERC 721 tokens where a Smart Contract allows the creation of multiple tokens, Smart Contracts of data NFTs allow just one token per contract. Therefore, a Factory Contract serves as creator of a number of custom contracts which may have each one token minted at max. This architecture allowed the custom contracts to have individual rules, which provides a lot of flexibility compared to the traditional architecture.
The following graphic illustrates the Factory Contract, which serves as creator for several custom contracts (need to be registered first) that are bound to a data NFT.
A further notable difference to classical NFTs is that data NFTs don't make use of external storage solutions like IPFS. Data NFTs use on-chain meta-data, which has the advantage that meta-data remains persistent due to the nature of the blockchain. Nevertheless, it comes with the disadvantage that on-chain storage space is limited and costly.
Before we can mint an NFT, we need to define the collection, of which the NFT will be a part, via the deployment of a smart contract. Thanks to the REST-API from the NFT-Kit, we can easily deploy a contract based on the FA2 unified token standard from Tezos with the multiple implementation (equal to ERC-721 or ERC-1155on Ethereum). Which is one of the standards for creating NFTs.
Before you mint a new NFT, you need to have an already deployed smart contract or deploy a new one. For this tutorial, we will deploy a new smart contract.
We will deploy the smart contract on the Tezos testnet "GHOSTNET". We need to provide the owner and the type of smart contract(our NFT Kit supports two smart contract implementations: you can click here for more details).
Response:
After that, you must define who can mint new tokens within an already deployed smart contract. In our case, we take the previously deployed contract.
The "minteraddress" is the account that will sign the mint transaction.
Response:
Smart contracts are simple programs that live in a NEAR network. As any modern application, smart contracts store data and expose methods to interact with them.
NEP-171 is the standard for creating and managing NFTs on the NEAR blockchain. It specifies the data structure and smart contract interface for NFTs, allowing developers to create and manage NFTs in a consistent and interoperable way.
The NEAR Pathway utilizes AssemblyScript as the primary programming language for its smart contracts, which are then compiled to WebAssembly (WASM) for execution on the blockchain.
However, NEAR also supports the use of Rust, a language that is particularly well-suited for server applications and has gained popularity for its built-in safety checks and testing infrastructure.
The NEAR team highly recommends the use of Rust for any smart contracts of a financial nature.
which is a framework of how Dapps work