DEV Community: shabbiryk.eth

Overview of CyberConnect on-chain protocol and explore the potential use cases

shabbiryk.eth — Wed, 16 Nov 2022 14:40:41 +0000

Overview

This guide will be covering:

How Does Composable Middleware Accelerate dApps in Web3?
What is CyberConnect?
Use Cases
CyberConnect SDK
What to build with CyberConnect?

How Does Composable Middleware Accelerate dApps in Web3?

The term "middleware" refers to a versatile part of the web3 building block that embraces Composability and Pluggability and allows it to quickly and intelligently inform other parts of the entire construction. As an illustration, if we consider EVM to be an infrastructure, then the Cyberconnect, APIs for a thriving decentralised environment, will serve as a Middleware.

Infrastructure integration in a manner of longboard effect

Each tool is extremely effective in the current infrastructure situation, but there is no way to combine their functions. There are numerous toolkits that, despite having a similar appearance, approach the subject from various perspectives. For instance, Next.ID focuses on syncing Web2 and Web3 profiles as well as full persona ownership when processing Cross-chain Channel-based DID, .bit concentrates on Cross-chain behaviour aggregating, especially for non-EVM footprints and social recovery and CyberConnect is committed to permissionless on-chain relational solutions to maximise social network expansion.
We are missing a one-place integration of middlewares to empower more advanced web3 use cases. We think that the Longboard Effect is the core. Individual applications should play their most robust part in the construction of web3 development.

Comprehensive Ecosystem loops

As soon as cross-platform data collaboration is established, sustainability concerns are very simple to overlook. The first step in the data enabling process is data extraction using ETLs (Extract, transform, load) and indexation from full nodes; the second stage is data pre-processing through clustering and tagging; the third stage is through AI, scoring, and credit programmes; the final step is matching interactions to dApps or user protocol. However, just because a process is complete does not mean the entire task has been completed. Re-examining the logic of the entire logic and adaptive learning, or fitting it to the optimal logic, is often the most important and easily overlooked course. Here is a picture of how the loop looks.

What is CyberConnect?

CyberConnect is a blockchain-based open-source social graph (A map represents social relations between users) created to reshape the future of social media concepts in the era of Web3 and decentralization.

CyberConnect is intended to be permissionless and capable of empowering content creators to "own their digital roots" and enable people to uncompromisingly own the connections between themselves and the communities, in contrast to contemporary Web2 social media platforms like Twitter or Facebook that use social graphs to develop interconnections among users of social networks only in a centralised manner.

The development of the CyberConnect resulted in the emergence of a decentralised social graph that users completely own, regaining control over their information and links as well as giving them access to features that allow them to monetize their content. It empowers users to truly own their social identities, contents, and connections in a social network and provides developers with a rich set of tools to build applications with meaningful social experiences.

As the next stage of web3 begins to take shape, the CyberConnect protocol will offer decentralized options for how data is used and perceived with the following features:

Publicly accessible: All dApps will have open access to the decentralised social graph data as an optional feature, allowing developers to take advantage of user connections to expand beyond their current user base.

Self-sovereign: Only users have complete control over their own social graphs, even though the social graph data is accessible to everyone (i.e., adding, deleting, and updating the connections)

Blockchain-agnostic: The protocol is designed for a multi-blockchain ecosystem to support connections from anywhere rather than being tied to a single blockchain.

Decentralized governance: CyberConnect will adhere to the principles of shared security, permissionless systems, and decentralised governance, which will influence the roadmap and development of the protocol. CyberConnect is motivated by Ethereum's vision.

Token-incentivized: CyberConnect will introduce a token-incentivized model in the early stages to fairly reward all contributors who help bootstrap the social graph in order to support the long-term development of the CyberConnect Protocol.

Options for privacy-preserving features: CyberConnect is actively looking into technical solutions to enable privacy-preserving features in the future because it is aware that some users care more about their connection data than others do.

CyberConnect use cases

Build a decentralized social graph database

At the heart of CyberConnect is a tamper-proof data structure that efficiently facilitates the creation, update, query and verification of user-centric data. Long-term data retention on CyberConnect is guaranteed through Ceramic’s blockchain anchoring and a custom data pinning service.

Multi-account identity

Optimize identity management in a multi-account environment with a simplified single sign-on experience, user provisioning, and password management for your dApp

Identity index for composability

identity protocol, for easy user data indexing and integration with other protocols and applications.

Universal social graph index

CyberConnect also collects and organises social graph data from websites such as Twitter, Foundation, and Rarible, among others. The combination of all this information results in a rich and distinctive user experience. Consider a social network that can automatically generate a "suggested user list" for each user based on their historical purchases of NFTs, their past transactions (sending and receiving tokens or NFTs), and the people they follow on other websites like Twitter and Rarible. This is vastly different from the majority of modern centralised architecture-based new social platform creations, where you start from scratch whenever a chance arises.

CyberConnect also indexes higher dimensional network data, which allows it to generate new connection suggestions based on existing social graphs. This curation and indexing aims to combine both the user-owned publicly accessible social graph with other off-chain data from across web2 and web3 applications.

An API gateway makes this global social graph index available to app developers. Without worrying about creating and maintaining the corresponding database to store contact lists and followers, developers can quickly create a new "instagram for NFTs." Because of this, CyberConnect shortens the time it takes for application developers to see results, enabling them to concentrate on developing content curation and recommendation systems based on social graph data. CyberConnect allows users to import their existing friend lists, allowing developers to concentrate on the gaming experience rather than the social aspects.

CyberChat

A trustless, decentralized chat app that helps round out the social ecosystem for web3. CyberChat enables users to log in with a blockchain wallet, create their user profile based on on-chain data, and frictionlessly send chat messages while interacting with the blockchain. With CyberChat, decentralized projects and DAOs can now manage their communities on a crypto-native basis.

CyberConnect SDK

Developer- friendly gateway to help write social connection data to decentralized datastores.

Ways to connect

JS SDK
Follow Button
Social Verifier

CyberConnect SDK - Data Standard

type Proof = {
   /** Name of the operation. E.g, Follow */
   name: string; 
   /** State of the operation, E.g, true or false for following or not */
   state: boolean; 
   /** The originator address */ 
   from: string;
   /** The target address */
   to: string;
   /** Which dApp is this connection originated */
   namespace: string: 
   /** Which network is this connection on */ 
   network: string; 
   /** timestamp */ 
   timestamp: number;
};

What to build with CyberConnect?

Blogging with crowdfunding

With the help of the CyberConnect protocol, developers can create social dApps that store and manage user social data like profiles, posts, and content decentralized. Additionally, users can monetize their data by publishing it in NFT format on a chosen blockchain. For instance, the content creator could charge 14 $CYBER tokens for each of the 100 editions of their blog and only permit subscribers to NFT-collect such content.

SBT/NFT issuing platform

Top Web3 projects frequently and successfully use airdrops and tokens to entice early adopters, convert them to contributors, and keep them engaged with rewards like badges. With the help of the protocol, communities can create sizable audiences using social data that resides as ERC-721 NFTs on CyberConnect. Applications for community tooling use CyberConnect to power community profiles and give members badges for participating in activities.

Recommendation

When creating your social dApp, you can use CyberConnect to obtain interesting recommendation data. The protocol, for instance, can produce a list of suggested users to follow based on users' connections and social data from both off-chain and on-chain sources. Additionally, a list of suggested token purchases can be created by modelling trading activity and holdings in relation to other addresses (i.e. collaborative filtering model).

CONCEPT

To get an idea of what it would look like to build on the CyberConnect protocol, let's first understand CyberConnect's concepts and key features.

Schema

CyberConnect has the indexed data schema designed as below that represents social relationships on Link3. You can find the more detailed gql schema on our API Playground and query subfields that all start from the wallet address.

Identity

Users can aggregate their identities across various platforms and applications by using a decentralised social graph. This enables developers to get access to more detailed information about a user's address, like:

Their ENS or Solana Domain
Their NFTSs
Their Avatar
Their verified WEB2 social account
Their first ON-CHAIN Transaction
Their followers/followings

Profile

A CyberConnect profile is similar to a profile in Web2 social applications because it is the starting point for every on-chain action. Each profile is an ERC-721 NFT and is the owner of its content and paid subscribers. Additionally, each user may have multiple profiles. As of right now, the protocol only permits people to mint profiles through Link3 on Ethereum; however, on the testnet, minting profiles is free.

Content

Content created by users, including blogs, videos, and publications. We also examine how users interact with this content in novel ways enabled by smart contracts, such as by supporting public goods, giving to charities, and governing. Users must first create their profiles before they can create content because each piece of content is linked to a profile in order to establish authority and trust. Each piece of content can be gathered using dynamic rules.
Users can begin developing their on-chain social network by creating "content" after creating their profiles. Content in CyberConnect can be anything a user develops, issues, or builds. Through this design, dynamic use cases like:

Creators posting short-form content on video platforms,
Event organizers issuing reward/recognition badges for participation, or
Universities issuing verifiable credentials like diplomas for students.

All content is represented in the format of an ERC-721 token called EssenceNFT. The content itself can be stored on different storage platforms like IPFS or Arweave, depending on the developer’s discretion.

Additionally, Collect Middleware Contracts are provided by the protocol. Thus, each profile owner can add unique functionality regarding the nature of the token and the "collecting" conditions (such as pay to collect or hold NFT to collect)

The protocol also offers Collect Middleware Contracts. Thus, each profile owner can add unique functionality regarding the nature of the token and the "collecting" conditions (such as pay to collect or hold NFT to collect) (e.g. transferable or non-transferable). Link3 is an illustration. EssenceNFT is used by the Web3 social network of verifiable identities to enable organisation profiles to issue badges/SBTs for attendance. EssenceNFT is used by our own demo app to represent a post.

Subscribe

Web3 users can enable paid subscriptions to their profiles using CyberConnect's Smart Contract Protocol. Rules for profile subscriptions will need to be established, and our Subscribe Middleware Contracts will be crucial for this. Upon successful subscription, each subscriber will receive a SubscribeNFT.

Interaction

A general interaction is illustrated in the diagram below:

Further Readings

That’s it for this guide! Hope you found it useful and thanks for reading 😁. For more information, read the official white paper on the CyberConnect website. Follow the team on Twitter or join their communities in Discord & Telegram to stay up-to-date!

Overview of common DID methods and when to use each one.

shabbiryk.eth — Tue, 15 Nov 2022 10:33:59 +0000

What is Ceramic?

Composability has roots in the open-source technology movement and was critical to the Internet's early growth. Web3 needs composability to unlock value for users and foster innovation. In application development, composability refers to the ability to combine existing components and reassemble them to create new products.

In a composable architecture, every component has a specific use case. Developers can then combine these components and add new functionality to build applications—without having to reinvent the wheel or build from scratch.

Ceramic is a decentralized network for composable data. By letting you browse a marketplace of data models, plug them into your app, and store, update, and retrieve data from those models, Ceramic makes creating applications with composable Web3 data simple. Their data is automatically interoperable when various applications reuse the same data models. Ceramic makes data composable and reusable across all applications by decentralizing application databases.

Check out this great article

Decentralized Identifiers (DIDs)

DIDs are globally distinct identities that can be used to interact with any off-chain services or data as well as sign documents on the Ceramic network. More specifically, they are abstract, key-agnostic interfaces used to uniquely identify entities, interoperable sign and encrypt information, authorize authentication/access control to services, and store mappings to additional resources.

A DID can be a user, an organization, an application, a service, a device, etc. because Ceramic makes no assumptions about the type of entity it represents. DIDs are flexible and interoperable across wallets and platforms because they can be controlled by one or several private keys. By using DIDs to manage data stores, data can traverse platforms and blockchains and be associated with any entity, including NFTs.

DID methods

A DID method is defined by a DID method specification, which specifies the precise operations by which DIDs and DID documents are created, resolved, updated, and deactivated. DID methods are DID specifications that have been put into practice.

A DID resolver that can return a DID document given a URI that complies with that specific DID method is required. DID methods must also specify a name for the method in the form of a string (see below), a description of how the DID document is generated statically, and the location of the DID document's storage. The official DID registry maintained by the W3C lists more than 40 DID methods. Ceramic currently supports PKH DID method, 3ID DID method and the Key DID method. DID URIs look like this:

did:<method-name>:<method-specific-identifier>

3ID DID Accounts

The first and most widely used DID method on Ceramic is 3ID. More than 15,000 3IDs are already being used in production. The 3ID DID Method (CIP-79) is a Ceramic-native account which can be used to authenticate to Ceramic to perform transactions on streams.

3ID is a DID method that is implemented natively on Ceramic. The data that makes up the DID document for the 3ID is stored in a mutable stream that is created using the Tile Document StreamType. Since its updates must be anchored into a blockchain and provide explicit versions and proofs of publication at specific points in time, the Tile Document StreamType supports secure key rotation for 3IDs (blockheights). As a result, 3ID inherits this attribute.

The 3ID DID Method is on the W3C's official DID method registry and is fully compliant with decentralized identity standards.

Multiple keys, secure rotations: The DID Document for the 3ID DID Method is implemented using a Ceramic Tile Document, as was previously stated, making it fully mutable and capable of supporting the secure addition and removal (rotation) of keys. This makes it possible for 3ID DIDs to manage multiple keys at once and remove keys as necessary.

Support for blockchain wallets: A 3ID DID can be controlled from a user's current blockchain wallets when used with the Identity Index protocol (CIP-11) and the 3ID Keychain definition (CIP-20). 3ID Connect is in charge of implementing this functionality.

Aggregated identities: All of a user's blockchain and Web3 accounts can control their 3ID DIDs from any L1 or L2 protocol, acting as a cross-chain identifier. Through this, a user's identity can be unified across all other platforms.

Great for end users: Due to all of the reasons above.

3ID Connect

3ID Connect is an authentication system that allows users to use blockchain wallets to interact with browser-based Ceramic apps.

3ID Connect is an account & key management application run in an iFrame, which is privately controlled by users and can be accessed by wallets and applications during onboarding. A user-controlled, iFrame-based application for managing accounts and keys called 3ID Connect can be accessed by wallets and other applications during onboarding. The Oauth consent flows that users have grown accustomed to on web2—such as signing into apps with Facebook, Google, Twitter, or Github—are very similar to the new 3ID Connect flow. However, 3ID Connect offers much more robust, user-centric identity and data storage capabilities for your application.

3ID Connect uses the Ceramic Network’s dedicated 3IDProvider (via IdentityWallet SDK) to deliver a more feature-complete, secure, friendly, and cross-chain experience. There are many reasons to love 3ID Connect, but here are some highlights:

Secure key material 🔐
Data consent clarity ✅
Fewer wallet signatures 🔑
Standalone 3ID provider 🆔
Multi-address support 🔗
Multi-network support 🕸
Contract wallet support 🛡
Ceramic Network compatibility 🔸

To improve the onboarding flow in your application and get started with 3ID Connect today, check out this tutorial

Further Reading

Check out the other posts in this three-part series on 3ID Connect:

DID PKH (CIP-79)

There are hundreds of billions of on-chain, balance-holding accounts across the major 50 or so blockchains, all secured and namespaced using similar technologies. Most of them use public keys that are provided at the time of the transaction and are hashed or otherwise obscured as their identifiers.

These accounts are used to protect billions of dollars in assets and critical digital infrastructure. Governments and businesses are also actively experimenting with and utilising them. They are quickly developing into a significant form of shared data infrastructure across continents and industry verticals. DIDs should favor usability where possible, and it is extremely beneficial from a security & human computer interaction perspective to have DIDs that readily correspond to their equivalents on decentralized networks.

The primary goal of the DID PKH method is to allow any valid blockchain address to "spin up" a feature-limited but valid and widely interoperable DID and DID Document, valid in a limited context where accounts are represented by DIDs. By enabling interoperability between blockchain accounts and DIDs, PKH DID accounts enable users to directly sign, authorise, and authenticate using their blockchain account. The related blockchain account has complete control over a PKH DID account; key rotations, changes, deactivation, etc. are not supported.

This approach's extreme narrowness and neutrality enable a variety of implementations. For example, the validity of each address to be wrapped in a DID is checked according to the CAIP-10 standard before generating, to prevent a did:pkh being presented as valid that would not be on its corresponding blockchain. Implementers may still decide to gate generation to on-chain accounts or balance-holding accounts based on the needs of their particular use case even though no additional validation is assumed or offered in the reference implementation.

Additional reading

Key DID

A DID method statically generated from any Ed25519 key pair. Key DIDs are typically used for developer accounts. Key DID is lightweight, but the drawback is that its DID document is immutable and has no ability to rotate keys if it is compromised.

It is the most basic DID method. When resolved, it merely encrypts a public key in the DID string and turns it into a DID Document. Key DID is on the W3C's official DID method registry and is fully compliant with decentralized identity standards. Before choosing to apply the Key DID Method to your project, carefully read the considerations listed below:

One key only: The DID Document for a Key DID is specifically linked to a solitary cryptographic key. In order to control the DID, only one key can ever be used, and it can never be changed in the event that it is compromised. It cannot support multiple keys in the DID document, nor can it support key rotation.
For advanced users: The Key DID Method is generally not suitable for identities for non-technical end users because it is only suitable for advanced users who will only ever want to use one keypair to control their DID and who have strong key security practises, such as a developer.

Additional reading

NFT DID (experimental and not recommended for production use)

NFT is a DID method that uses the Ceramic network to resolve DID documents for NFTs. A DID method for any NFT on any blockchain. The DID document is statically generated from on-chain data. The DID associated with the blockchain account of the asset's current owner (using CAIP-10 Links) is the only entity authorized to act on behalf of the NFT DID, authenticate in DID-based systems, and make updates to streams or other data owned by the NFT DID. When ownership of the NFT changes, so does the controller permissions.

Any non-fungible token on any blockchain can be turned into a decentralised identifier using the NFT DID Method, where the NFT's owner serves as the DID's controller. This is accomplished by describing NFT assets and blockchain accounts using Chain Agnostic Improvement Proposals, and by locating the NFT owner's DID on the Ceramic network.

Extensible, mutable NFT metadata – At the moment, NFTs have fixed metadata that is created at token issuance. What happens, though, if we want an NFT to be able to gather data over time? With the help of NFT DID, an NFT owner can annotate an NFT with extra information that changes over time, such as a social graph for the NFT, a background story for the artefact, owner-restricted content, or, for instance, a certificate for carbon offsetting.

How does it work? When resolving an NFT DID account, Ceramic and the did-nft-resolver perform the following steps:

Using a subgraph on the The Graph protocol, Query a blockchain for the owner(s) of the NFT.
For each owner, find a corresponding CAIP-10 Link (CIP-7), which provides a link from blockchain account to Ceramic account. This determines who can write to the stream.
When a transaction is sent to the stream owned by the NFT, verify the Ceramic account that signed the message is linked to the blockchain account that is a current owner.

Additional reading

Safe DID (experimental and not recommended for production use)

A DID method for a Gnosis Safe smart contract on any blockchain. Typically used for organizations, DAOs, and other multi-sig entities.

Accounts with the Gnosis Safe DID Method (CIP-101) can conduct stream transactions. The active participants in a Gnosis Safe smart contract manage the Safe DID accounts. Despite being fully compliant with decentralised identity standards and being listed on the W3C's official DID method registry, Safe DID is still very experimental. Use at your own risk.

Safe account

Every Gnosis Safe contract becomes a Ceramic account with the ability to send transactions to streams on Ceramic thanks to the Safe DID Method. It is similar to the NFT DID account method in both design and application.

Only the DIDs of the blockchain accounts that manage the Gnosis Safe contract are allowed to write permissions for streams whose controller is set to a Safe DID. The write permissions to streams owned by the Gnosis Safe also change when the controller permissions for the Safe are modified on-chain.

Additional reading

Safe DID Method (CIP-101) Specification

That’s it for this tutorial! Hope you found it useful and thanks for reading 😁.

Creating an NFT with Stacks

shabbiryk.eth — Sat, 12 Nov 2022 16:27:51 +0000

What You Will Need

Clarinet installed on your machine (follow the instructions in the link to install it)
IDE or Text Editor (we recommend VSCode)
Hiro Web Wallet (learn more about the installation here)
STX Testnet tokens (you can get some at this faucet)

Overview

Stacks is a layer-1 blockchain that allows for the execution of smart contracts, Proof of Transfer (PoX) consensus mechanism. Stacks is associated with the Bitcoin ecosystem because it aims to enhance Bitcoin’s capabilities by building on top of it. Stacks is also exciting because it supports smart contracts, so developers can build dApps such as decentralised exchanges, DAOs, NFT marketplaces, and more!

This guide will demonstrate how to create and deploy NFT on the Stacks Testnet using Clarity. Clarity is a smart contract programming language that was purpose-built for writing safer, more secure code.

Understanding Clarity

Clarity is a smart contract language with a Lisp style created for the Stacks blockchain. Clarity is intentionally Turing incomplete as it avoids “Turing complexity.” This allows for complete static analysis of the entire call graph of a given smart contract. What does this mean exactly? To make your solidity contract code understandable by the EVM on most EVM-based chains, you must compile it into bytecode. Because you don't have to compile your code, the Stacks blockchain is unique. Instead, the executed code can be easily audited because it is human readable. Another advantage this has for users is that, unlike on EVM-based chains, the source code for a smart contract is always accessible when it is deployed on the Stacks blockchain. Finally, you can analyse Clarity code for runtime cost and data usage. This empowers developers to predict what a given Clarity program will do, and how much it will cost.

Clarity vs Solidity NFT Standards

A comparison between the SIP-009 trait and the analogous EIP 721 standard will help as a starting point. SIP-009 is the Clarity standard for NFT and reads as follows;

(define-trait nft-trait
 (
   ;; Last token ID, limited to uint range
   (get-last-token-id () (response uint uint))

   ;; URI for metadata associated with the token
   (get-token-uri (uint) (response (optional (string-ascii 256)) uint))

    ;; Owner of a given token identifier
   (get-owner (uint) (response (optional principal) uint))

   ;; Transfer from the sender to a new principal
   (transfer (uint principal principal) (response bool uint))
 )
)

The fact that EIP 721 is longer simply demonstrates a portion that the Clarity trait left out and emphasises the differences between the two in terms of who is able to transfer ownership of an NFT.

interface ERC721 /* is ERC165 */ {...
   function approve(address _approved, uint256 _tokenId) external payable;


   function setApprovalForAll(address _operator, bool _approved) external;


   function getApproved(uint256 _tokenId) external view returns (address);


   function isApprovedForAll(address _owner, address _operator) external view returns (bool)
}

You’ll notice that EIP 721 defines the ability for the NFT owner to delegate, to an approved address, the ability to transfer the asset on the owner's behalf.

In Clarity there is no need for an approval mechanism because Clarity leaves this up to the smart contract developer. While this is great for innovation and rapid development it is also a concern from a security perspective as it means the contract builder can insert backdoors which allow any NFT in the contract to be transferred to anyone else — without the consent of the owner.

What is Clarinet?

Now that you have some familiarity with Stacks and Clarity, let us dive into the tool we will use to build our smart contract, Clarinet. Clarinet is a command-line tool useful for efficient smart contract development. It can be used for developing, testing, debugging, and deploying your contracts to local and production environments. It's similar to other popular web3 smart contract libraries such as Hardhat.

Prerequisites

For this tutorial, you should have a local installation of Clarinet. Refer to Installing Clarinet for instructions on how to set up your local environment. You should also have a text editor or IDE to edit the Clarity smart contracts.

If you are using Visual Studio Code, you may want to install the Clarity Visual Studio Code plugin.

Building an NFT Smart Contract

With that high-level description of Clarity, let’s get into how to actually create a smart contract with it.

Hiro Web Wallet Set Up

The Hiro Web Wallet must be set up in order for us to deploy our clarity smart contract to the Stacks Testnet network. You must switch the network configuration of your wallet to Testnet once it has been configured. On the homepage of your wallet, click the ellipses ("...") button, then select Change Network.

Next, you'll want to ensure you have some STX Testnet tokens. You can request some tokens on the Stacks Explorer Faucet page. Just connect your wallet, then click the Request STX button.
Feel free to continue to the next section after you have your wallet and STX Testnet tokens!

Clarity Basics

The syntax of Clarity is LISP-like. As a result, there will be numerous parentheses. You can discover additional parenthesis, symbols, sentences, values, and more within these ones. People that are new to LISP-like languages may feel intimidated as it looks very foreign compared to both natural languages as many other programming languages.

A way to conceptualize Clarity code is to think of lists inside lists. (The technical term for these kinds of expressions is "S-expression".) Expressions do not differentiate between data and code, that makes things a bit easier! Here is an example of a Clarity expression.

For instance, if we wrote 4 + 5 in JS, we would get the result of 9.
The identical expression would be represented as (+ 4 5) in Clarity.
In this case, we are invoking the + function, which has two parameters: 4 and 5. All of Clarity functions this way, with everything being basically a function call with passed parameters.

Create and configure a Clarinet project

Open up a terminal window and navigate into the directory you want this project to live in. Then, run the following command to create a new clarinet project and navigate inside it.

clarinet new nft-project && cd nft-project

The clarinet command above creates a boilerplate project directory called nft-project that we can use to develop smart contracts quickly.

clarinet contract new nft-trait; clarinet contract new nft-sample

The above command creates two .clar files, which are the Clarity file format. One of these files contains the metadata for our NFTs and the other contains the logic for our NFT contracts (for example, nft-sample.clar) (e.g., nft-trait.clar). Two test files in TypeScript format will also be produced in a test directory.

At this point, your project folder setup should look like this:

├── Clarinet.toml
├── contracts
│ ├── nft-sample.clar
│ └── nft-trait.clar
├── settings
│ ├── Devnet.toml
│ ├── Mainnet.toml
│ └── Testnet.toml
└── tests
├── nft-sample_test.ts
└── nft-trait_test.ts

In the next section, we will start configuring and implementing the NFT smart contract.

Create and Define the Clarity Smart Contract

Implementing the SIP-009 Standard

To make sure the contract we are building complies with SIP-009, we must configure some dependencies before we begin writing the smart contract code. Open Clarinet.toml and edit the contracts.nft-sample section (around line 11-12) to match the following configuration:

[contracts.nft-sample]
path = "contracts/nft-sample.clar"
depends_on = ["nft-trait"]

Our smart contract complies with the necessary characteristics specified in the SIP-009 standard thanks to the configuration described above. If we don’t implement the configured traits, our deployment to test and production environments will fail.

Next, open the nft-trait.clar file. Copy the following code and replace it with the content already in the file:

define-trait nft-trait
  (
    ;; Last token ID, limited to uint range
    (get-last-token-id () (response uint uint))

    ;; URI for metadata associated with the token
    (get-token-uri (uint) (response (optional (string-ascii 256)) uint))

     ;; Owner of a given token identifier
    (get-owner (uint) (response (optional principal) uint))

    ;; Transfer from the sender to a new principal
    (transfer (uint principal principal) (response bool uint))
  )
)

Then, save the file. The Clarity code above sets the functions our contract should conform to. These functions should be familiar to you as we discussed them in the previous section.

Implementing the NFT Contract Logic

We will now update the nft-sample.clar file with the NFT smart contract logic. We will be able to mint NFTs using the contract on the Stacks blockchain. Open the file and add the following code to the existing content:

;; using the SIP009 interface (testnet)
;; trait configured and deployed from ./settings/Devnet.toml
(impl-trait 'ST1PQHQKV0RJXZFY1DGX8MNSNYVE3VGZJSRTPGZGM.nft-trait.nft-trait)

;; declare a new NFT
(define-non-fungible-token NFT-SAMPLE uint)

;; store the last issued token ID
(define-data-var last-id uint u0)

;; mint a new NFT
(define-public (claim)
  (mint tx-sender))

;; SIP009: Transfer token to a specified principal
(define-public (transfer (token-id uint) (sender principal) (recipient principal))
  (begin
     (asserts! (is-eq tx-sender sender) (err u403))
     ;; Make sure to replace NFT-SAMPLE
     (nft-transfer? NFT-SAMPLE token-id sender recipient)))

(define-public (transfer-memo (token-id uint) (sender principal) (recipient principal) (memo (buff 34)))
  (begin
    (try! (transfer token-id sender recipient))
    (print memo)
    (ok true)))

;; SIP009: Get the owner of the specified token ID
(define-read-only (get-owner (token-id uint))
  ;; Make sure to replace NFT-NAME
  (ok (nft-get-owner? NFT-SAMPLE token-id)))

;; SIP009: Get the last token ID
(define-read-only (get-last-token-id)
  (ok (var-get last-id)))

;; SIP009: Get the token URI. You can set it to any other URI
(define-read-only (get-token-uri (token-id uint))
  (ok (some "https://token.stacks.co/{id}.json")))

;; Internal - Mint new NFT
(define-private (mint (new-owner principal))
    (let ((next-id (+ u1 (var-get last-id))))
      (var-set last-id next-id)
      ;; You can replace NFT-SAMPLE with another name if you'd like
      (nft-mint? NFT-SAMPLE next-id new-owner)))

In the next section, we'll demonstrate how to verify your contracts to make sure they are deployable.

Testing the Smart Contract in a Local Environment

Clarity is an interpreted language, which means it doesn't compile code down to a lower level before execution; instead, the code gets executed in the same format at runtime. This makes the code slower but more transparent. To check that our clarity code is syntactically correct, we can run the command clarinet check from the nft-project directory.

You may get some warnings; however, don't worry about those for the purpose of this guide.

Before deploying to Stacks Testnet, it is good practice to check a few functions to make sure the responses are what we expect. We can initiate the clarinet console to do this:

clarinet console

Once the console is initiated, you'll see your contract address and public functions available in your contract. There will also be a list of test accounts that are associated with your local clarinet console. Run the command below to call the claim function of our smart contract, which will mint an NFT in our local environment.

(contract-call? .nft-sample claim)

You should see a response similar to this:

If all goes well, move on to the next section where we will deploy our NFT contract to Stacks Testnet 👀

Deploy the NFT Contract to Stacks Testnet

This section will demonstrate how to deploy your NFT contract to Stacks Testnet using the Stacks Explorer Sandbox. Before we get started, make sure you have the Hiro Wallet already installed and set up. Moreover, make sure to have some test STX tokens for gas fees (you can get some at this faucet).

Once your wallet is set up, connect your wallet to the Stacks Explorer Sandbox and navigate to the Write & Deploy page. Copy and paste the code from your nft-sample.clar file, and then fill in the contract name (in our example, it's "nft-sample") if you don't want the randomly generated name provided to you.

Next, click the deploy button. You should get a prompt from the Hiro wallet window with information about the transaction. Verify that the transaction looks correct, then click Confirm

The mining (transaction/process) can go on for a short while.
On the transactions page of the Stacks explorer or in the activity section of your Hiro wallet, you can keep track of the transaction.
The homepage of our contract can be reached by searching for the contract address or selecting the transaction in our wallet once we have verified that the contract has been mined. The contract page will display your contract's name, deployer address, fees to deploy the contract, the source code, and what block number it was mined in.

Where is the NFT that you recently minted, you might be wondering? Technically speaking, it hasn't yet been minted. We have only developed and deployed the NFT contract thus far. We will walk you through the minting process in the following section, where you can view your NFT in your Hiro wallet and claim it. To take your time and learn more about the explorer page, feel free to do so, then proceed to the next section when you're ready.

Mint the NFT through the Stacks Sandbox

The moment you've been waiting for! It's time to mint it up!

To mint the NFT, we will need to call the claim function of our NFT contract. Navigate to the Call a contract page (the f in the left sidebar), then input your contract's address (i.e., ST12KGMZCKXERR1VG1TFEQQZ3VQXSMVVC3J31S604.nft-sample) and the sandbox should detect the address and name. Click the Get contract button and should see the callable functions listed in the table like so:

Click the Claim function then click Call function. You'll get a prompt in your Hiro wallet. Verify the claim function is being called, then confirm the transaction. Your transaction may take a couple of minutes to confirm. Feel free to take a quick break; it should be confirmed once you return. If it still takes a while, you can click the Increase fee* icon on your transaction within your Hiro wallets activity tab.

Once the transaction is mined, you can see your NFT within the Balances tab on your Hiro wallet or the Stacks explorer by going to your personal wallet address page and looking at the Collectibles tab.

Awesome Work! You’ve learned how to create and deploy, and execute an NFT contract to the Stacks Testnet blockchain