Learn to build on Secret with Figment Learn

Secret 101

In the blockchain world, being open and transparent is a good thing, but some data is just too sensitive to be exposed. That’s why Secret exists. Built with privacy in mind and encryption by default, it wants to enable the secure transfer of sensitive and personal data on blockchains.

Secret

1 hour

Beginner

Intermediate

JS/TS

Rust

Privacy

React

NodeJS

Smart contracts

Next.js

Tools & Infra

Time Commitment

Difficulty

Programming Language

Feature

Technology

We no longer host the Pathway pages on this website, the content has moved to the `learn-web3-dapp` repository at <https://github.com/figment-networks/learn-web3-dapp#-get-started>.

The workflow for Pathways is easy to follow:

- Using the `learn-web3-dapp` code repository, you will be running a local development server (`yarn dev`)
- Each Pathway is accessible from the main page displayed when the development server is running
- Once you begin a Pathway, your completion progress is saved in the local storage of your web browser
- Each Pathway has a similar goal: To guide you through using various code libraries to work with different parts of the web3 stack
- Many of the individual steps of a Pathway provide you with coding challenges, so that you can learn by doing
- You will need to complete the code as explained in the instructions before moving on to the next step
- All of the coding challenges have solutions which are blurred until you click on them, to prevent you from being stuck
- Once you have completed a Pathway, you should have a working knowledge of that protocol which will help you tackle larger projects

For less experienced developers or for anybody who wants to dive in without needing to set up a development environment, **[we recommend using Gitpod](https://gitpod.io/#https://github.com/figment-networks/learn-web3-dapp)** to work with the `learn-web3-dapp` project (this requires you to have a GitHub account to sign in). Gitpod can save you a considerable amount of time, as you don't have to install dependencies or set up any software - everything just works! Gitpod provides you with a fully functional Visual Studio Code editor running in your browser, so you can jump right in. This is what it looks like: 

![Gitpod UI](https://raw.githubusercontent.com/figment-networks/learn-tutorials/master/assets/gitpod-firstlook.png?raw=true)

If you are an experienced developer, or if you prefer to use a different code editor, [cloning the repo locally](https://github.com/figment-networks/learn-web3-dapp#-clone-locally) is still possible, however you might encounter various system configuration issues depending on how your local environment is set up. It will be more difficult to develop on a Windows system than on Linux or MacOS, and there are also some known issues with developing Solana programs on Windows. It is strongly recommended to use the [Windows Subsystem for Linux](https://docs.microsoft.com/en-us/windows/wsl/install#manual-installation-steps) (WSL) if you are running Windows 10. 

If you are cloning the repo locally, a minimum of **NodeJS version 14.17 is required**. Some of the Pathways will require use of the [Rust toolchain](https://rustup.rs/). If you are developing on Linux, you will want to make sure you have the [build-essential](https://itsfoss.com/build-essential-ubuntu/) package installed, as the `cc` linker is required for compiling Solana programs.

🎓 Pathway complete!

Deploy a smart contract

# Introduction

[Non-Fungible Tokens](https://en.wikipedia.org/wiki/Non-fungible_token) implement the idea of uniqueness in the blockchain world. With classical, fungible tokens the only important characteristic is how _many_ of them you own. You can think of those as currency, or to make a more exotic example, carrots. It is interesting to know how many kilograms of carrots you have, but nobody is likely to be really into you telling them which carrots you own precisely. For non-fungible tokens on the other hand, the number you are holding is not as important as _which_ token you hold. Given an example: If I tell you that I own three paintings, it's not that impressive. If I tell you on the other hand that I own the Mona Lisa, Guernica and The Persistence of Time you might be impressed and still want me to prove it.

At a high level, an NFT has a number of important properties. First we are interested in which account holds a token, as this can decide who is allowed to interact with it. Secondly we need a way to store the metadata, which is the information that users will see and interact with that makes this NFT more than just a tokenID!

{% embed url="https://youtu.be/jRuSOos9ig4" %}

# Prerequisites

This tutorial assumes that you have completed the [Secret Pathway](https://learn.figment.io/protocols/secret) already, as we will be building upon that foundation of knowledge and skill. If you have not already done so, you would be wise to take the time to complete the Pathway. We will start with the same project folder as in section 5 of the Pathway.
# Requirements

* The latest version of NodeJS installed $use of nvm, the node version manager, is _encouraged_ for Web 3 developers$
* A code editor like VSCode, Theia, Atom, _etc_.
* Required JavaScript packages –
  * secretjs - for the Secret Network JavaScript API
  * dotenv - for working with environment variables

It is not required to install docker and the Rust toolchain _yet_, as we are using a pre-deployed contract in this case. A future installment in this series will guide you through writing and compiling your own variant of a snip721 token.

# What is different between ERC721 and snip721

As mentioned above each NFT contains unique data or at least a way to identify the unique data. Due to the distributed public ledger property of most blockchains, this means that anyone can read this data. So even if you bought an expensive painting as an NFT no one is stopping me from finding the NFT on a blockchain explorer, having a look at the data and downloading that image for myself.

Secret Network is focused on privacy by default and this paradigm extends to its implementation of NFT standards. The snip721 standard mimics the functionality of the corresponding ERC721 standard on the Ethereum blockchain but provides more granular control over what information is private, rather than everything being publicly available. When a new snip721 token contract is deployed to the secret network you can define if the total supply and the owners of tokens should be publicly available. The deployer of the contract decides which data is public and which is only available to the current owner of the NFT.

# Getting started with secretNFTs

We will connect to an already deployed instance of the [snip721 reference implementation](https://github.com/baedrik/snip721-reference-impl): The _SecretFigment token_. We will build the functionality needed to interact with an NFT on secret. Namely the ability to mint new tokens, to set the Viewing key on tokens and to query the token private metadata.
# Minting

As we will be frequently communicating with the contract, the first thing we will do is add the contract address to our `.env` file:

```text
SECRET_NFT_CONTRACT='secret166tjlgmahhjrl8ndegq8xmzjxfe6p6h4hdvx6a'
```

Next, we create a new file in the project folder called `mint.js` and add the following code into it:

```javascript
const {
  EnigmaUtils,
  Secp256k1Pen,
  SigningCosmWasmClient,
  pubkeyToAddress,
  encodeSecp256k1Pubkey,
} = require("secretjs");

// Requiring the dotenv package in this way
// lets us use environment variables defined in .env
require("dotenv").config();

const customFees = {
  upload: {
    amount: [{ amount: "2000000", denom: "uscrt" }],
    gas: "2000000",
  },
  init: {
    amount: [{ amount: "500000", denom: "uscrt" }],
    gas: "500000",
  },
  exec: {
    amount: [{ amount: "500000", denom: "uscrt" }],
    gas: "500000",
  },
  send: {
    amount: [{ amount: "80000", denom: "uscrt" }],
    gas: "80000",
  },
};

const main = async () => {
  const httpUrl = process.env.SECRET_REST_URL;

  // Use the mnemonic created in step #2 of the Secret Pathway
  const mnemonic = process.env.MNEMONIC;

  // A pen is the most basic tool you can think of for signing.
  // This wraps a single keypair and allows for signing.
  const signingPen = await Secp256k1Pen.fromMnemonic(mnemonic).catch((err) => {
    throw new Error(`Could not get signing pen: ${err}`);
  });

  // Get the public key
  const pubkey = encodeSecp256k1Pubkey(signingPen.pubkey);

  // get the wallet address
  const accAddress = pubkeyToAddress(pubkey, "secret");

  // initialize client
  const txEncryptionSeed = EnigmaUtils.GenerateNewSeed();

  const client = new SigningCosmWasmClient(
    httpUrl,
    accAddress,
    (signBytes) => signingPen.sign(signBytes),
    txEncryptionSeed,
    customFees
  );
  console.log(`Wallet address=${accAddress}`);

  // 1. Define your metadata

  // 2. Mint a new token to yourself

};

main().catch((err) => {
  console.error(err);
});
```

Here we are getting our account data from the `.env` file and generating a secretjs client from it, which we can use to sign our transactions. The next step is to define the metadata that we want to attach to our Secret NFT. In this example, we use strings: One public, one private and only accessible to the holder of the NFT. Under `// 1. Define your metadata` add both constant declarations. Feel free to change the string to whatever you like. If we wanted to use string interpolation to import data programmatically, remember to swap the double quotes with backticks!

```javascript
  // String interpolation example
  // const derivedMetadata = "<additional payload>";
  // const publicMetadata = `<public metadata> ${derivedMetadata}`;


  const publicMetadata = "<public metadata>";
  const privateMetadata = "<private metadata>";
```

The next step is for us to construct a message object to pass into our client, populate it with data, then send it to our pre-defined contract. Paste the snippet below under `// 2. Mint a new token to yourself`.

```javascript
  const handleMsg = {
    mint_nft: {
      owner: accAddress,
      public_metadata: {
        name: publicMetadata,
      },
      private_metadata: {
        name: privateMetadata,
      },
    },
  };

  console.log("Minting yourself a nft");
  const response = await client
    .execute(process.env.SECRET_NFT_CONTRACT, handleMsg)
    .catch((err) => {
      throw new Error(`Could not execute contract: ${err}`);
    });
  console.log("response: ", response);
```

`handleMsg` is the data we pass into our Secret client, which mints a new token for our own address then assigns the values we created above as public and private metadata. We pass and execute the object to the contract and read the response. If there were no errors, the output will be in the form of the reponse object:

```javascript
  response:  {
  logs: [ { msg_index: 0, log: '', events: [Array] } ],
  transactionHash: '644332C51EEB404E68B0B73BDEFAD36209A2C78C532DDFF03F83AD3AD68EE5F13',
  data: Uint8Array(256) [
    123, 34, 109, 105, 110, 116,  95, 110, 102, 116, 34, 58,
    123, 34, 116, 111, 107, 101, 110,  95, 105, 100, 34, 58,
     34, 48,  34, 125, 125,  32,  32,  32,  32,  32, 32, 32,
     32, 32,  32,  32,  32,  32,  32,  32,  32,  32, 32, 32,
     32, 32,  32,  32,  32,  32,  32,  32,  32,  32, 32, 32,
     32, 32,  32,  32,  32,  32,  32,  32,  32,  32, 32, 32,
     32, 32,  32,  32,  32,  32,  32,  32,  32,  32, 32, 32,
     32, 32,  32,  32,  32,  32,  32,  32,  32,  32, 32, 32,
     32, 32,  32,  32,
    ... 156 more items
  ]
}
```

Congratulations! We have just minted a Non-Fungible Token on the Secret network using an already deployed contract!

### Querying the contract

In this section, we want to query information about our token from the contract. For this create a new file called `query_token.js` and paste the following code into it:

```javascript
const {
  EnigmaUtils,
  Secp256k1Pen,
  SigningCosmWasmClient,
  pubkeyToAddress,
  encodeSecp256k1Pubkey,
} = require('secretjs');

// Load environment variables
require('dotenv').config();

const customFees = {
  upload: {
    amount: [{ amount: '2000000', denom: 'uscrt' }],
    gas: '2000000',
  },
  init: {
    amount: [{ amount: '500000', denom: 'uscrt' }],
    gas: '500000',
  },
  exec: {
    amount: [{ amount: '500000', denom: 'uscrt' }],
    gas: '500000',
  },
  send: {
    amount: [{ amount: '80000', denom: 'uscrt' }],
    gas: '80000',
  },
};

const main = async () => {
  const httpUrl = process.env.SECRET_REST_URL;

  // Use key created in tutorial #2
  const mnemonic = process.env.MNEMONIC;

  // A pen is the most basic tool you can think of for signing.
  // This wraps a single keypair and allows for signing.
  const signingPen = await Secp256k1Pen.fromMnemonic(mnemonic).catch((err) => {
    throw new Error(`Could not get signing pen: ${err}`);
  });

  // Get the public key
  const pubkey = encodeSecp256k1Pubkey(signingPen.pubkey);

  // get the wallet address
  const accAddress = pubkeyToAddress(pubkey, 'secret');

  // initialize client
  const txEncryptionSeed = EnigmaUtils.GenerateNewSeed();

  const client = new SigningCosmWasmClient(
    httpUrl,
    accAddress,
    (signBytes) => signingPen.sign(signBytes),
    txEncryptionSeed,
    customFees
  );
  console.log(`Wallet address=${accAddress}`);

  // 1. Get a list of all tokens

  if (response.token_list.tokens.length == 0)
    console.log(
      'No token was found for you account, make sure that the minting step completed successfully'
    );
  const token_id = response.token_list.tokens[0];

  // 2. Query the public metadata

  // 3. Query the token dossier

  // 4. Set our viewing key

  // 5. Query the dossier again

};

main().catch((err) => {
  console.error(err);
});
```

The overall structure of this file should look familiar by now. It contains the setup for the client and signing functionality that we will use to interact with the contract. The first step is to get a list of all our tokens. For this, we will add the following code under `// 1. Get a list of all tokens`:

```javascript
 let queryMsg = {
    tokens: {
      owner: accAddress,
    },
  };

  console.log("Reading all tokens");
  let response = await client
    .queryContractSmart(process.env.SECRET_NFT_CONTRACT, queryMsg)
    .catch((err) => {
      throw new Error(`Could not execute contract: ${err}`);
    });
  console.log("response: ", response);
```

We will ask the contract for a list of all token ids, which are currently assigned to our address. _**Note -**_ The deployed contract is configured to have public ownership for the sake of this tutorial. If you would deploy the contract yourself you can also decide to make it private, so that nobody but you will be able to see which tokens you own. This will be covered in a later installment of this series.

Next, we will take the first token id and ask for the details of this NFT. There are a few different queries supported by the reference implementation. After `// 2. Query the public metadata` insert this code block:

```javascript
  queryMsg = {
    nft_info: {
      token_id: token_id,
    },
  };

  console.log(`Query public data of token #${token_id}`);
  response = await client
    .queryContractSmart(process.env.SECRET_NFT_CONTRACT, queryMsg)
    .catch((err) => {
      throw new Error(`Could not execute contract: ${err}`);
    });
  console.log("response: ", response);
```

This will retrieve the message you added as `publicMetadata` during the mint process. Next, add this code block after `// 3. Query the token dossier`:

```javascript
 queryMsg = {
    nft_dossier: {
      token_id: token_id,
    },
  };

  console.log(`Query dossier of token #${token_id}`);
  response = await client
    .queryContractSmart(process.env.SECRET_NFT_CONTRACT, queryMsg)
    .catch((err) => {
      throw new Error(`Could not execute contract: ${err}`);
    });
  console.log("response: ", response);
```

The token dossier returns all of the data that we have access to, including public and private metadata, as well as some overall configuration of this token. If you run this file using `node query-token.js` you should receive similar output to this:

```text
Reading all tokens
response:  { token_list: { tokens: [ '0' ] } }
Query public data of token #0
response:  {
  nft_info: {
    name: '<your public meta data>',
    description: null,
    image: null
  }
}
Query dossier of token #0
response:  {
  nft_dossier: {
    owner: '<your address>',
    public_metadata: {
      name: '<your public meta data>',
      description: null,
      image: null
    },
    private_metadata: null,
    display_private_metadata_error: 'You are not authorized to perform this action on token 0',
    owner_is_public: true,
    public_ownership_expiration: 'never',
    private_metadata_is_public: false,
    private_metadata_is_public_expiration: null,
    token_approvals: null,
    inventory_approvals: null
  }
}
```

Of interest is this line: `display_private_metadata_error: 'You are not authorized to perform this action on token 0',`. Why are we not able to see our private metadata even if we _are_ owning the NFT?

To answer this we need to take a small detour through the inner workings of secret contract interactions.

Interaction with a contract falls into one of two distinct categories, you either _execute_ a contract or you _query_ a contract. The main difference here is that execution modifies the internal state of the contract and incurs a gas fee for doing so, while a query only reads from the internal state and it usually free.

_**Note -**_ Queries also have a calculated gas cost but are executed for free by the secret nodes. Node runners can define how expensive a query might be until they refuse to execute it. Also if you run a query during an execution call, its gas cost will be added to the total cost of the query.

In regards to the [privacy model](https://build.scrt.network/dev/privacy-model-of-secret-contracts.html#outputs) of Secret contracts - whenever we send a query, the sending address is not verified, as a query does not happen on-chain but rather just between the client and the contract. This means ultimately that we need to execute on a contract if we want to make sure who the contract is talking to. This is not optimal because of gas costs.

This leads to the problem above: We do not want to execute on the contract, because we are not changing its inner state. As a query is not recorded on-chain we have no way of making sure _who_ is sending that query. So even if we tell the contract that the query was sent by us, it rejects our request for the private data, as there is no tamperproof way to make _sure_ it is us.

The concept of Viewing keys is a clever solution for this problem. Instead of executing every time you will execute a single call and set a secret phrase, the so called key, for the contract. Whenever you send a query in the future you include this key with your query and the contract can look it up and validate it is actually you it is talking to. As secret network transmits fully encrypted messages no one will ever know your viewing keys.

To be able to use this mechanic to get access to our private metadata, we must add a string for the viewing key to our `.env` file, so that we can reuse it in our code.

```
SECRET_VIEWING_KEY = "<random phrase>"
```

We will use this phrase in the following code, which should go add after `// 4. Set our viewing key`, as a kind of passphrase, uniquely identifying our address.

```javascript
 const handleMsg = {
    set_viewing_key: {
      key: process.env.SECRET_VIEWING_KEY,
    },
  };

  console.log('Set viewing key');
  response = await client
    .execute(process.env.SECRET_NFT_CONTRACT, handleMsg)
    .catch((err) => {
      throw new Error(`Could not execute contract: ${err}`);
    });
  console.log('response: ', response);
```

After we set our viewing key, we also need to pass it along with the query for the token dossier. Add the following code after `// 5. Query the dossier again`.

```javascript
queryMsg = {
    nft_dossier: {
      token_id: token_id,
      viewer: {
        address: accAddress,
        viewing_key: process.env.SECRET_VIEWING_KEY,
      },
    },
  };

  console.log(`Query dossier of token #${token_id} with viewing key`);
  response = await client
    .queryContractSmart(process.env.SECRET_NFT_CONTRACT, queryMsg)
    .catch((err) => {
      throw new Error(`Could not execute contract: ${err}`);
    });
  console.log('response: ', response);
```

Take note of how we changed `queryMsg` to specify who is viewing the contract information, passing our own address and the Viewing key. When we run the script at this point using `node query_token.js` there will be two results of querying the contract in your output. The first one, that you already saw above has no access to the private metadata. The second entry where we supplied the Viewing key, will return the private metadata along with all the other info and should look like this:

```
response:  {
  nft_dossier: {
    owner: '<your address>',
    public_metadata: {
      name: '<your public meta data>',
      description: null,
      image: null
    },
    private_metadata: {
      name: '<your private meta data>',
      description: null,
      image: null
    },
    display_private_metadata_error: null,
    owner_is_public: true,
    public_ownership_expiration: 'never',
    private_metadata_is_public: false,
    private_metadata_is_public_expiration: null,
    token_approvals: [],
    inventory_approvals: []
  }
}
```

# Conclusion

Congratulations! We have made it to the end of the first installment of this Secret NFT series. We have covered a lot of information, and I feel you can really be proud of what you have achieved. Just to recap:

* You have minted your own, personalized NFT on the Secret network
* You learned about the privacy model and how Viewing keys help us to save gas, while making sure we can verify ownership of an account
* You had hands-on experience interacting with the Secret network, learning about public, private and extended metadata.

This is a solid foundation to play with and build upon!

# Next Steps

Of course, we are not yet at the end of our journey. In the coming tutorial, we will have a look together into interesting and more complex examples of NFT properties. You can look forward to:

* Customizing your NFT by deploying your own contract
* Sending NFTs between different accounts
* Building a simple NFT viewer
* Adding complex logic to your NFTs, making them much more than _just_ a store of secret data

Let's keep on building!

# About the author

This tutorial was created by [Florian Uhde](https://twitter.com/florianuhde), a software engineer and game developer with a passion for blockchain, creativity and systemic design. You can get in touch with the author on [Figment Forum](https://community.figment.io/u/floar) if you have any queries pertaining to the tutorial, secretNFTs, etc.hello


This is the first part of a series about using snip721 tokens on the Secret network.

Create your first secret NFT

# Introduction

If you are interested in staking SCRT tokens but do not want to run your own node, delegation is a great option. In this tutorial, we will delegate SCRT tokens to a validator, and unbond the delegation using SecretJS and a [DataHub](https://datahub.figment.io/sign_up?service=secret) node.

## What is Delegation?

Delegation involves giving some of your staking power to a specific validator on the Secret Network, who will then give you a share of their fees and rewards. As a delegator, you essentially get the same returns as a node operator minus their commissions. If there is an on-chain governance vote, a delegator's vote will be the same as their validator's, unless the delegator changes their own vote manually. Since there can currently only be 50 active nodes on the network, delegators play a crucial role in decentralization.

# Prerequisites

If you have completed the Secret Pathway, you should have already taken care of these prerequisites. For this tutorial you must:

* Install node.js and npm, and set up your DataHub environment 
* Create an account on the Secret testnet 
* Make sure you have testnet tokens in your account 

# Delegate to a Validator

First, you need to decide which validator you would like to delegate to. You can go to this URL [https://explorer.secrettestnet.io/validators/](https://explorer.secrettestnet.io/validators/) to check the active validators. Once you have selected one, you can start to build the delegation transaction by creating a new file `delegate.js` and adding the code below:

```javascript
const {
  CosmWasmClient, Secp256k1Pen, pubkeyToAddress, encodeSecp256k1Pubkey, makeSignBytes,
} = require('secretjs');

require('dotenv').config();

const main = async () => {
  // As in previous tutorial, initialize client from .env
  const mnemonic = process.env.MNEMONIC;
  const signingPen = await Secp256k1Pen.fromMnemonic(mnemonic)
    .catch((err) => { throw new Error(`Could not get signing pen: ${err}`); });
  const pubkey = encodeSecp256k1Pubkey(signingPen.pubkey);
  const accAddress = pubkeyToAddress(pubkey, 'secret');
  const client = new CosmWasmClient(process.env.SECRET_REST_URL);
  // Define the validator address to delegate
  const valAddress = '<VALIDATOR ADDRESS YOU WANT TO DELEGATE>';

  // Optionally, define a memo for the transaction
  const memo = 'My first secret delegation';

  // 1. Define TX message

  // 2. Define fees

  // 3. Sign transaction

  // 4. Broadcast TX

  // 5. Query TX by hash/ID
}

main().catch((err) => {
  console.error(err);
});
```

# Define TX message

Now, you need to define the TX message that allows you to specify the delegator address, validator address and the amount of tokens you want to delegate. In the `delegate.js` file under the comment `// 1. Define TX message` add the following code snippet:

```javascript
  const sendMsg = {
    type: 'cosmos-sdk/MsgDelegate',
    value: {
      delegator_address: accAddress,
      validator_address: valAddress,
      amount: {
          denom: 'uscrt',
          amount: '1000000',
      },
    },
  };
```

# Define fees

Then, you have to define the fee and gas for this transaction. Under the comment `// 2. Define fees` add the following code snippet:

```javascript
  const fee = {
    amount: [
      {
        amount: '50000',
        denom: 'uscrt',
      },
    ],
    gas: '200000',
  };
```

# Sign transaction

In order to authorize the transaction, and prove it is valid, you need to sign the transaction with the details you defined above. Under the comment `// 3. Sign transaction` add the following code snippet:

```javascript
  const chainId = await client.getChainId()
    .catch((err) => { throw new Error(`Could not get chain id: ${err}`); });
  const { accountNumber, sequence } = await client.getNonce(accAddress)
    .catch((err) => { throw new Error(`Could not get nonce: ${err}`); });
  const signBytes = makeSignBytes([sendMsg], fee, chainId, memo, accountNumber, sequence);
  const signature = await signingPen.sign(signBytes)
    .catch((err) => { throw new Error(`Could not sign: ${err}`); });
  const signedTx = {
    msg: [sendMsg],
    fee,
    memo,
    signatures: [signature],
  };
```

# Broadcast transaction

Now, you can broadcast your transaction, let others know and process it as well. Under the comment `// 4. Broadcast transaction` add the following code snippet:

```javascript
  const { transactionHash } = await client.postTx(signedTx)
    .catch((err) => { throw new Error(`Could not post tx: ${err}`); });
```

# Query transaction

After your transaction is accepted and processed, you can query the information about your transaction on the Secret Network. Under the comment `// 5. Query transaction` add the following code snippet:

```javascript
  const query = { id: transactionHash };
  const tx = await client.searchTx(query)
    .catch((err) => { throw new Error(`Could not search tx: ${err}`); });
  console.log('Transaction: ', tx);
```

Let's run the code:

```text
node delegate.js
```

If everything works $you have enough tokens, validator is valid, etc$ you should see an output similar to:

```
Transaction:  [
  {
    height: 1137370,
    hash: 'B10B6F540E95635B9E7D9F03DB4A423D70553CB7E7391F62D6CC295B4CCD9335',
    code: 0,
    rawLog: '[{"msg_index":0,"log":"","events":[{"type":"delegate","attributes":[{"key":"validator","value":"secretvaloper132yjx48nerguvdcpv7huljhyrtlrt86n8f8u72"},{"key":"amount","value":"1000000"}]},{"type":"message","attributes":[{"key":"action","value":"delegate"},{"key":"module","value":"staking"},{"key":"sender","value":"secret14hevdc4hfzdkqjqk38pgmk4kj9988l3ce80lkr"}]}]}]',
    logs: [ [Object] ],
    tx: { type: 'cosmos-sdk/StdTx', value: [Object] },
    timestamp: '2021-01-23T07:58:09Z'
  }
]
```

Copy the transaction's `hash` from the output and replace `<TRANSACTION HASH>` in the link below. OPEN LINK BELOW to see the transaction in Secret Explorer!

`https://explorer.secrettestnet.io/transactions/<TRANSACTION HASH>`

# Unbond Tokens

> **WARNING**: There currently is a 21 day unbonding period, during which no rewards are handed out and your tokens are locked.

If for any reason the validator misbehaves, or you just want to unbond a certain amount of tokens, make a copy of `delegate.js` and rename is as `unbond.js`. Then, change the code under the comment `// 1. Define TX message` as following code snippet below:

```javascript
  const sendMsg = {
    // This time, we use MsgUndelegate type to unbond tokens.
    type: 'cosmos-sdk/MsgUndelegate',
    value: {
      delegator_address: accAddress,
      validator_address: valAddress,
      amount: {
          denom: 'uscrt',
          amount: '1000000',
      },
    },
  };
```

The other parts can remain the same, and let's run the code:

```text
node unbond.js
```

If everything works $you have enough delegation on the validator and etc$ you should see an output similar to:

```
Transaction:  [
  {
    height: 1137693,
    hash: '06335FCD7E2A1D91101F051763173A7EE8AD6B2D859389D135058FDD1CADD8BB',
    code: 0,
    rawLog: '[{"msg_index":0,"log":"","events":[{"type":"message","attributes":[{"key":"action","value":"begin_unbonding"},{"key":"sender","value":"secret1jv65s3grqf6v6jl3dp4t6c9t9rk99cd896s45r"},{"key":"sender","value":"secret1fl48vsnmsdzcv85q5d2q4z5ajdha8yu3h7axyt"},{"key":"module","value":"staking"},{"key":"sender","value":"secret14hevdc4hfzdkqjqk38pgmk4kj9988l3ce80lkr"}]},{"type":"transfer","attributes":[{"key":"recipient","value":"secret14hevdc4hfzdkqjqk38pgmk4kj9988l3ce80lkr"},{"key":"amount","value":"33561525770uscrt"},{"key":"recipient","value":"secret1tygms3xhhs3yv487phx3dw4a95jn7t7lr7phjl"},{"key":"amount","value":"1000000uscrt"}]},{"type":"unbond","attributes":[{"key":"validator","value":"secretvaloper132yjx48nerguvdcpv7huljhyrtlrt86n8f8u72"},{"key":"amount","value":"1000000"},{"key":"completion_time","value":"2021-02-13T08:28:59Z"}]}]}]',
    logs: [ [Object] ],
    tx: { type: 'cosmos-sdk/StdTx', value: [Object] },
    timestamp: '2021-01-23T08:28:59Z'
  }
]
```

Copy the transaction's `hash` from the output and replace `<TRANSACTION HASH>` in the link below. OPEN LINK BELOW to see the transaction in Secret Explorer!

`https://explorer.secrettestnet.io/transactions/<TRANSACTION HASH>`

The unbonding will be automatically completed when the unbonding period has passed.

# Conclusion

Congratulations! You now know how to delegate and unbond your tokens by crafting advanced transactions from scratch with SecretJS and DataHub. You will be able to make complex transactions and interactions on the Secret Network. More message types can be found in the [Cosmos SDK](https://docs.cosmos.network/master/modules/).

The complete code can be found on [**Github**](https://github.com/figment-networks/tutorials/blob/main/secret/6_delegations)**.**

# About the Author

This tutorial was created by [Minato Fund](https://github.com/minatofund), an active group helping merge blockchain projects operating as a validator.


Learn how to delegate and unbond tokens on Secret Network

Delegate to a Validator & Unbond Tokens

Learn the basics of creating a new secret contract from scratch.

Developing your first secret contract

# Introduction

In this tutorial we will demonstrate how to add Viewing Key code to the reminder secret contract that we built in the [Developing your first secret contract](https://learn.figment.io/tutorials/creating-a-secret-contract-from-scratch) tutorial. In that tutorial we implemented code to store and read a private reminder for a user. As implemented, each read of the reminder costs gas, which is not ideal. We will show here how a *viewing key* can be used to implement the same functionality in way that does not require the user to send a gas payment every time they want to read the reminder. 

A viewing key is simply a randomly generated password defined for an address that is stored in the contract. If a query sends a user's address and viewing key together as parameters in the query, then we can use that information to share read-only private data with the user without needed to incur any gas fees.

The viewing key code implemented in this tutorial is based on the implementation used in the SecretSCRT contract: https://github.com/enigmampc/secretSCRT.

# Prerequisites

If you have not completed the [Developing your first secret contract tutorial](https://learn.figment.io/tutorials/creating-a-secret-contract-from-scratch), do that first. That tutorial also assumes you have completed the [Secret Pathway](https://learn.figment.io/pathways/secret-pathway). This tutorial builds on the contract that was used in that tutorial, the full code for which you can find on GitHub at this link: [https://github.com/darwinzer0/secret-contract-tutorials/tree/main/tutorial1/code](https://github.com/darwinzer0/secret-contract-tutorials/tree/main/tutorial1/code).

If you get stuck at any point, the completed code for this tutorial can also be found on GitHub here: [https://github.com/darwinzer0/secret-contract-tutorials/tree/main/tutorial2/code](https://github.com/darwinzer0/secret-contract-tutorials/tree/main/tutorial2/code).

# Preparing the build environment

To begin you will need to add the following packages to the `Cargo.toml` file:

```toml
secret-toolkit = { git = "https://github.com/enigmampc/secret-toolkit", branch = "debug-print" }
subtle = { version = "2.2.3", default-features = false }
base64 = "0.12.3"
hex = "0.4.2"
sha2 = { version = "0.9.1", default-features = false }
```

# Adding viewing key utility

First we will import two source files that define the main ViewingKey struct as well as a couple of utility functions. This code is pulled directly from the [Secret SCRT contract](https://github.com/enigmampc/secretSCRT). Both of these files can be found on GitHub at the following link: [https://github.com/darwinzer0/secret-contract-tutorials/tree/main/tutorial2](https://github.com/darwinzer0/secret-contract-tutorials/tree/main/tutorial2). With slight modification you could easily combine these into one file if you wish.

## Add utils.rs

```rust
use crate::viewing_key::VIEWING_KEY_SIZE;
use sha2::{Digest, Sha256};
use std::convert::TryInto;
use subtle::ConstantTimeEq;

pub fn ct_slice_compare(s1: &[u8], s2: &[u8]) -> bool {
    bool::from(s1.ct_eq(s2))
}

pub fn create_hashed_password(s1: &str) -> [u8; VIEWING_KEY_SIZE] {
    Sha256::digest(s1.as_bytes())
        .as_slice()
        .try_into()
        .expect("Wrong password length")
}
```

This utility crate defines two helper functions: `ct_slice_compare`, which will be used to test if two hashed passwords are the same; and `create_hashed_password`, which creates a hashed password from a random seed using the SHA-256 hash algorithm.

## Add viewing_key.rs

```rust
use std::fmt;

use schemars::JsonSchema;
use serde::{Deserialize, Serialize};

use cosmwasm_std::Env;
use secret_toolkit::crypto::{sha_256, Prng};

use crate::utils::{create_hashed_password, ct_slice_compare};

pub const VIEWING_KEY_SIZE: usize = 32;
pub const VIEWING_KEY_PREFIX: &str = "api_key_";

#[derive(Serialize, Deserialize, JsonSchema, Clone, Debug)]
pub struct ViewingKey(pub String);

impl ViewingKey {
    pub fn check_viewing_key(&self, hashed_pw: &[u8]) -> bool {
        let mine_hashed = create_hashed_password(&self.0);

        ct_slice_compare(&mine_hashed, hashed_pw)
    }

    pub fn new(env: &Env, seed: &[u8], entropy: &[u8]) -> Self {
        // 16 here represents the lengths in bytes of the block height and time.
        let entropy_len = 16 + env.message.sender.len() + entropy.len();
        let mut rng_entropy = Vec::with_capacity(entropy_len);
        rng_entropy.extend_from_slice(&env.block.height.to_be_bytes());
        rng_entropy.extend_from_slice(&env.block.time.to_be_bytes());
        rng_entropy.extend_from_slice(&env.message.sender.0.as_bytes());
        rng_entropy.extend_from_slice(entropy);

        let mut rng = Prng::new(seed, &rng_entropy);

        let rand_slice = rng.rand_bytes();

        let key = sha_256(&rand_slice);

        Self(VIEWING_KEY_PREFIX.to_string() + &base64::encode(key))
    }

    pub fn to_hashed(&self) -> [u8; VIEWING_KEY_SIZE] {
        create_hashed_password(&self.0)
    }

    pub fn as_bytes(&self) -> &[u8] {
        self.0.as_bytes()
    }
}

impl fmt::Display for ViewingKey {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        write!(f, "{}", self.0)
    }
}
```

This file defines the struct for our viewing key, `ViewingKey`. The `new` method is a constructor that creates a new viewing key given a `seed` and `entropy`. The `seed` is the seed we will use with the pseudorandom number generator, and is a property of the contract that is set when the contract is created. The `entropy` is provided by the user and sent from the client when they want to create a new viewing key. The `entropy` is further extended by adding in the current block height, block time, and the canonical address of the sender. The seed and entropy are used to create an instance of a `Prng` (a pseudorandom number generator from the `secret-toolkit` library). We get a slice of random bytes from the random number generator and pass this to the SHA256 algorithm to get our key, which is finally encoded in Base64.

Once a viewing key has been created, the method `check_viewing_key` can be used to test whether a given hashed password matches the viewing key.

# Integrating into your contract

After you have added `viewing_key.rs` and `utils.rs` to the `src/` directory, in `src/lib.rs` you will need to add them as modules in the project. To do that add these lines near the top:

```rust
mod viewing_key;
mod utils;
```

In the contract, we also need to add a pseudorandom number generator seed in our config. In `state.rs` add this to our `State` struct: 

```rust
    pub prng_seed: Vec<u8>,
```

We also need to create setter and getter functions to store the viewing key. Add the following functions `write_viewing_key` and `read_viewing_key` to `state.rs`. Note, as you add these functions here and in subsequent code blocks you will need to add any required imports from other files to the `use` statements at the top of the file. IDEs such as VSCode should automatically suggest these imports but if you have any questions refer to the completed code on GitHub:

```rust
pub const PREFIX_VIEWING_KEY: &[u8] = b"viewingkey";

pub fn write_viewing_key<S: Storage>(store: &mut S, owner: &CanonicalAddr, key: &ViewingKey) {
    let mut user_key_store = PrefixedStorage::new(PREFIX_VIEWING_KEY, store);
    user_key_store.set(owner.as_slice(), &key.to_hashed());
}

pub fn read_viewing_key<S: Storage>(store: &S, owner: &CanonicalAddr) -> Option<Vec<u8>> {
    let user_key_store = ReadonlyPrefixedStorage::new(PREFIX_VIEWING_KEY, store);
    user_key_store.get(owner.as_slice())
}

```

Now in `msg.rs` update the `InitMsg` struct to require the owner of the contract to send a pseudorandom number generator seed `String` when the contract is first initialized:

```rust
    pub prng_seed: String,
```

Finally, in the `init` function in `contract.rs` update the initialization of the config to store a hashed Base64-encoded version of the seed:

```rust
    let config = State {
        max_size,
        reminder_count: 0_u64,
        prng_seed: sha_256(base64::encode(msg.prng_seed).as_bytes()).to_vec(),
    };
```

# Generating a viewing key

Next we need to add a Handle function to generate a viewing key for a user. In `msg.rs` we add the following to `HandleMsg`:

```rust
    GenerateViewingKey {
        entropy: String,
        padding: Option<String>,
    },
```

And create a new response in `HandleAnswer` that returns the generated key to the user:

```rust
    GenerateViewingKey {
        key: ViewingKey,
    },
```

When we create a new key the client sends in some entropy to contribute to the randomness of the viewing key. The client should create a random string and pass it in with this parameter. Padding is simply an optional parameter that can be used to obfuscate the length of the entropy string.

Then, we add a new function in `contract.rs` to generate the key. In `handle` add:

```rust
    HandleMsg::GenerateViewingKey { entropy, .. } => try_generate_viewing_key(deps, env, entropy),
```

And add `try_generate_viewing_key`:

```rust
pub fn try_generate_viewing_key<S: Storage, A: Api, Q: Querier>(
    deps: &mut Extern<S, A, Q>,
    env: Env,
    entropy: String,
) -> StdResult<HandleResponse> {
    let config: State = load(&mut deps.storage, CONFIG_KEY)?;
    let prng_seed = config.prng_seed;

    let key = ViewingKey::new(&env, &prng_seed, (&entropy).as_ref());

    let message_sender = deps.api.canonical_address(&env.message.sender)?;

    write_viewing_key(&mut deps.storage, &message_sender, &key);

    Ok(HandleResponse {
        messages: vec![],
        log: vec![],
        data: Some(to_binary(&HandleAnswer::GenerateViewingKey { 
            key,
        })?),
    })
}
```

# Creating authenticated queries

## Updating msg.rs

Now we can update our Query messages to include authenticated queries. For example, let's say we want to implement Read as a query instead of a execute function, so we don't need to pay gas fees with every read. In `QueryMsg` in `msg.rs` add:

```rust
    Read {
        address: HumanAddr,
        key: String,
    }
```

When we make a Read query we pass in the address of the querier using their human-friendly address (i.e., `secret...`) and the viewing key string.

To easily access validation parameters for authenticated queries we can add an implementation block to our `QueryMsg` struct by adding the following below its declaration:

```rust
impl QueryMsg {
    pub fn get_validation_params(&self) -> (Vec<&HumanAddr>, ViewingKey) {
        match self {
            Self::Read { address, key, .. } => (vec![address], ViewingKey(key.clone())),
            _ => panic!("This query type does not require authentication"),
        }
    }
}
```

Then we define the `Read` response in the `QueryAnswer` enum:

```rust
    Read {
        status: String,
        reminder: Option<String>,
        timestamp: Option<u64>,
    },
```

## Updating contract.rs

Now we turn to `contract.rs` to update our `query` function. It is easiest to use a helper function to deal with all of the authenticated queries. Add the following line at the bottom of the `match msg` block in `query`:

```rust
    _ => authenticated_queries(deps, msg),
```

This means that any queries messages not already handled will be passed to a function called `authenticated_queries`. We define that as follows:

```rust
fn authenticated_queries<S: Storage, A: Api, Q: Querier>(
    deps: &Extern<S, A, Q>,
    msg: QueryMsg,
) -> QueryResult {
    let (addresses, key) = msg.get_validation_params();

    for address in addresses {
        let canonical_addr = deps.api.canonical_address(address)?;

        let expected_key = read_viewing_key(&deps.storage, &canonical_addr);

        if expected_key.is_none() {
            // Checking the key will take significant time. We don't want to exit immediately if it isn't set
            // in a way which will allow to time the command and determine if a viewing key doesn't exist
            key.check_viewing_key(&[0u8; VIEWING_KEY_SIZE]);
        } else if key.check_viewing_key(expected_key.unwrap().as_slice()) {

            return match msg {
                QueryMsg::Read { address, .. } =>
                    query_read(&deps, &address),
                _ => panic!("This query type does not require authentication"),
            };
        }
    }

    Err(StdError::unauthorized())
}
```

This code checks that the correct viewing key has been sent for the given address(es). If no viewing key has been set, we don't want that information to leak based on the time of execution, so we essentially run a noop to cycle through the same time that it would take to check the key if it did exist. If the key matches, then we can handle the specific type of query that was sent (in our case `Read`). If the viewing key does not match or was not set, then we return an unauthorized error. 

Now we can implement the `query_read` function. It is very similar to our `try_read` handle function from before, but instead of getting the sender address from `deps.api` we use the address that was sent as a query parameter:

```rust
fn query_read<S: Storage, A: Api, Q: Querier>(
    deps: &Extern<S, A, Q>,
    address: &HumanAddr,
) -> StdResult<Binary> {
    let status: String;
    let mut reminder: Option<String> = None;
    let mut timestamp: Option<u64> = None;

    let sender_address = deps.api.canonical_address(&address)?;

    // read the reminder from storage
    let result: Option<Reminder> = may_load(&deps.storage, &sender_address.as_slice().to_vec()).ok().unwrap();
    match result {
        // set all response field values
        Some(stored_reminder) => {
            status = String::from("Reminder found.");
            reminder = String::from_utf8(stored_reminder.content).ok();
            timestamp = Some(stored_reminder.timestamp);
        }
        // unless there's an error
        None => { status = String::from("Reminder not found."); }
    };

    to_binary(&QueryAnswer::Read{ status, reminder, timestamp })
}
```

Now you can read the reminder as many times as you want without paying any SCRT!

# Compiling your contract

As with any secret contract before uploading your contract to the network, you should compile it to wasm and then use the secret contract optimizer to reduce its size using the following commands. 

```bash
cargo wasm
docker run --rm -v "$(pwd)":/contract \                                                 
  --mount type=volume,source="$(basename "$(pwd)")_cache",target=/code/target \
  --mount type=volume,source=registry_cache,target=/usr/local/cargo/registry \
  enigmampc/secret-contract-optimizer
```

Refer to the [Write & deploy your first secret contract](https://learn.figment.io/network-documentation/secret/tutorials/intro-pathway-secret-basics/5.-writing-and-deploying-your-first-secret-contract) tutorial for more information on compiling and using a javascript client to execute the contract.

# About the author

This tutorial was written by Ben Adams, a senior lecturer in computer science and software engineering at the University of Canterbury in New Zealand.

This work is licensed under a [Creative Commons Attribution 4.0 International License](http://creativecommons.org/licenses/by/4.0/) ![cc](https://i.creativecommons.org/l/by/4.0/88x31.png)


Add Viewing Key code to the reminder secret contract that we built in the "Developing your first secret contract" tutorial.

Adding viewing keys to a secret contract

Get the storage of a smart contract

Set the storage of a smart contract

Connect to Secret

# Introduction

For a high level introduction to Non-Fungible-Tokens see the [first installment of this series](https://learn.figment.io/tutorials/create-your-first-secret-nft). In this tutorial we will download and compile the [snip721 reference implementation](https://github.com/baedrik/snip721-reference-impl), deploy it onto the secret testnet and interact with the contract, minting your own secret NFTs. Unlike the [previous tutorial](https://learn.figment.io/tutorials/create-your-first-secret-nft) we will configure the contract ourselves and learn about access right management of secret contracts and tokens on the way.

{% embed url="https://youtu.be/jRuSOos9ig4" %}

# Prerequisites

This tutorial assumes that you have completed the [Secret Pathway](https://learn.figment.io/protocols/secret) already, as we will be building upon that foundation of knowledge and skill. If you have not already done so, you would be wise to take the time to complete the Pathway. 

# Requirements

* The latest version of [NodeJS](https://nodejs.org/en/) installed $use of nvm, the node version manager, is _encouraged_ for web3 developers$
* A code editor like [VSCode](https://code.visualstudio.com/Download), Theia, Atom, _etc_.
* Required JavaScript packages –
  * [secretjs](https://www.npmjs.com/package/secretjs) - for the Secret Network JavaScript API
  * [dotenv](https://www.npmjs.com/package/dotenv) - for working with environment variables
* [Rust](https://rustup.rs) toolchain to compile secret contracts
* [Docker](https://docs.docker.com/get-docker/) is needed for smart contract optimization

## Generate the contract

If you do not already have the `cargo-generate` crate installed, add it with the command

```text
cargo install cargo-generate
```

Next, use `cargo-generate` to set up the snip-721 reference implementation with the command:

```text
cargo generate --git https://github.com/baedrik/snip721-reference-impl --name my-snip721
```

This git project is a reference implementation for tokens based on the [snip721 standard](https://github.com/SecretFoundation/SNIPs/blob/master/SNIP-721.md), which creates tokens that are loosely based on the [ERC-721](https://eips.ethereum.org/EIPS/eip-721) specification and are a superset of [CW-721](https://github.com/CosmWasm/cosmwasm-plus/blob/master/packages/cw721/README.md), making them compatible with both the Ethereum and Cosmos tokens.

You can have a look at the generated files by stepping into the folder using:

```text
cd my-snip721 && ls
```

The `src` folder contains the Rust smart contract.

```text
Cargo.lock  Developing.md  LICENSE  Publishing.md  examples      schema  tests
Cargo.toml  Importing.md   NOTICE   README.md      rustfmt.toml  src
```

While we will keep most of the files as-is during this tutorial, we will alter some of them for the tutorial to deepen your understanding what is happening behind the scenes. For now the goal is to compile the contract and upload it to the Secret testnet.

## Compile the contract

To compile the smart contract into a WebAssembly $.wasm$ binary, run this command in the terminal:

```text
cargo wasm
```

If the build process fails to compile the secp256k1-sys crate, you may need to run the contract optimizer instead - this can take quite some time, be patient. You will need to remember to have Docker Desktop installed and running to complete this step:

```text
make compile-optimized-reproducible
```

Before deploying or storing the contract on the testnet, you need to run the [secret contract optimizer](https://hub.docker.com/r/enigmampc/secret-contract-optimizer). Note that if you already did this due to `cargo wasm` failing, it is not necessary to do it again.

## Optimize compiled wasm

```text
docker run --rm -v "$(pwd)":/contract \
  --mount type=volume,source="$(basename "$(pwd)")_cache",target=/code/target \
  --mount type=volume,source=registry_cache,target=/usr/local/cargo/registry \
  enigmampc/secret-contract-optimizer:1.0.5
```

This will output an optimized build file, `contract.wasm.gz`, ready to be stored on the Secret Network. _Note that Windows users should replace the backslashes `\` in the command with carets `^` or optionally remove them and paste the command as a single line._

While `secretcli` supports uploading the compressed file, we'll be using SecretJS which expects the uncompressed WASM file, so lets unpack the optimized `contract.wasm` with this terminal command:

```text
gunzip contract.wasm.gz
```

You should be able to find a newly created file `contract.wasm` in the current directory.

## Uploading the contract

We are now switching back to the project root directory and will start writing some Javascript to manage our newly created contract. For this we will need the `secretjs` and `dotenv` packages to be installed.

After setting those up we start by creating a new file `deploy-nft.js` in the project root directory and add the code below:

```javascript
const {
  EnigmaUtils,
  Secp256k1Pen,
  SigningCosmWasmClient,
  pubkeyToAddress,
  encodeSecp256k1Pubkey,
} = require("secretjs");
const fs = require("fs");

// Load environment variables
require("dotenv").config();

const customFees = {
  upload: {
    amount: [{ amount: "5000000", denom: "uscrt" }],
    gas: "5000000",
  },
  init: {
    amount: [{ amount: "500000", denom: "uscrt" }],
    gas: "500000",
  },
  exec: {
    amount: [{ amount: "500000", denom: "uscrt" }],
    gas: "500000",
  },
  send: {
    amount: [{ amount: "80000", denom: "uscrt" }],
    gas: "80000",
  },
};

const main = async () => {
  const httpUrl = process.env.SECRET_REST_URL;

  // Use key created in tutorial #2
  const mnemonic = process.env.MNEMONIC;

  // A pen is the most basic tool you can think of for signing.
  // This wraps a single keypair and allows for signing.
  const signingPen = await Secp256k1Pen.fromMnemonic(mnemonic).catch((err) => {
    throw new Error(`Could not get signing pen: ${err}`);
  });

  // Get the public key
  const pubkey = encodeSecp256k1Pubkey(signingPen.pubkey);

  // get the wallet address
  const accAddress = pubkeyToAddress(pubkey, "secret");

  // 1. Initialize client

  // 2. Upload the contract wasm

  // 3. Create an instance of the NFT contract init msg

  const initMsg = {};
  const contract = await client
    .instantiate(
      codeId,
      initMsg,
      `My Snip721${Math.ceil(Math.random() * 10000)}`
    )
    .catch((err) => {
      throw new Error(`Could not instantiate contract: ${err}`);
    });
  const { contractAddress } = contract;
  console.log("contract: ", contract, "address:", contractAddress);
};

main().catch((err) => {
  console.error(err);
});
```

## Initialize the client

In the `deploy-nft.js` file, under the comment `// 1. Initialize client` add the following code :

```javascript
  const txEncryptionSeed = EnigmaUtils.GenerateNewSeed();

  const client = new SigningCosmWasmClient(
    httpUrl,
    accAddress,
    (signBytes) => signingPen.sign(signBytes),
    txEncryptionSeed, customFees,
  );
  console.log(`Wallet address=${accAddress}`);
```

## Upload the contract wasm

Under the comment `// 2. Upload the contract wasm` add the following code :

```javascript
  const wasm = fs.readFileSync('my-snip721/contract.wasm');
  console.log('Uploading contract');
  const uploadReceipt = await client.upload(wasm, {})
    .catch((err) => { throw new Error(`Could not upload contract: ${err}`); });

  // Get the code ID from the receipt
  const { codeId } = uploadReceipt;
```

Ensure that if you have changed the name of the contract folder, you also change it accordingly when passing it to `readFileSync()`:

```javascript
  const wasm = fs.readFileSync('my-snip721/contract.wasm');
```

# Instantiating the contract

Similar to what you have seen before, we first got the `codeId` from the upload receipt and then defined the `initMsg` to instantiate the contract. In this case the initMsg is more complex than for a simple counter and allows us to configure the secret NFT to our liking.

Open up the `msg.rs` file within the `src` folder of the contract code. You will see two structs: `InitMsg` and `InitConfig` in there, which describe the settings object we can pass to our contract on initialization. For most values a sensible default is predefined, giving the most privacy-preserving behavior.

Lets have a look at the different fields and what part of the contract they control:

## InitMsg

| Name | Type | Description | Optional | Value If Omitted |
| :--- | :--- | :--- | :--- | :--- |
| name | string | Name of the token contract | no |  |
| symbol | string | Token contract symbol | no |  |
| admin | string $HumanAddr$ | Address to be given admin authority | yes | env.message.sender |
| entropy | string | String used as entropy when generating random viewing keys | no |  |
| config | [Config $see below$](deploy-your-own-secret-nft.md#config) | Privacy configuration for the contract | yes | defined below |
| post\_init\_callback | [PostInitCallback $see below$](deploy-your-own-secret-nft.md#postinitcallback) | Information used to perform a callback message after initialization | yes | nothing |

## InitConfig

| Name | Type | Description | Optional | Value If Omitted |
| :--- | :--- | :--- | :--- | :--- |
| public\_token\_supply | bool | This config value indicates whether the token IDs and the number of tokens controlled by the contract are public.  If the token supply is private, only minters can view the token IDs and number of tokens controlled by the contract | yes | false |
| public\_owner | bool | This config value indicates whether token ownership is public or private by default.  Regardless of this setting a user has the ability to change whether the ownership of their tokens is public or private | yes | false |
| enable\_sealed\_metadata | bool | This config value indicates whether sealed metadata should be enabled.  If sealed metadata is enabled, the private metadata of a newly minted token is not viewable by anyone, not even the owner, until the owner calls the Reveal message.  When Reveal is called, the sealed metadata is irreversibly unwrapped and moved to the public metadata $as default$.  If `unwrapped_metadata_is_private` is set to true, the sealed metadata will remain as private metadata after unwrapping, but the owner $and anyone the owner has whitelisted$ will now be able to see it.  Anyone will be able to query the token to know whether it has been unwrapped.  This simulates buying/selling a wrapped card that no one knows which card it is until it is unwrapped. If sealed metadata is not enabled, all tokens are considered unwrapped when minted | yes | false |
| unwrapped\_metadata\_is\_private | bool | This config value indicates if the Reveal message should keep the sealed metadata private after unwrapping.  This config value is ignored if sealed metadata is not enabled | yes | false |
| minter\_may\_update\_metadata | bool | This config value indicates whether a minter is permitted to update a token's metadata | yes | true |
| owner\_may\_update\_metadata | bool | This config value indicates whether the owner of a token is permitted to update a token's metadata | yes | false |
| enable\_burn | bool | This config value indicates whether burn functionality is enabled | yes | false |

For this tutorial we will keep most of the default values and just change the name, symbol and the default ownership visibility of the token.

Add these properties to the `initMsg` object below `// 3. Create an instance of the NFT contract init msg` and add some values for name and symbol, as well as some random string for the entropy. Remember to keep the strings enclosed within the single quotes.

```javascript
const initMsg = {
  /// name of token contract
  name: '',
  /// token contract symbol
  symbol: '',
  /// entropy used for prng seed
  entropy: '',
  /// optional privacy configuration for the contract
  config: {
      public_owner: true
  },
}
```

Let's run the code:

```text
node deploy-nft.js
```

If it went well, you should see similar output:

```text
Uploading contract
contract:  {
  contractAddress: 'secret1g0t7sggeh89k27xa2vux5rnpc3ly4a9c0u8724',
  logs: [ { msg_index: 0, log: '', events: [Array] } ],
  transactionHash: 'F5E734014EA3108B071B3EA390E58FC41FA0DB28D1F49FE7A652C53E482AA0D9',
  data: '43D7E82119B9CB6578DD53386A0E61C47E4AF4B8'
} address: secret1g0t7sggeh89k27xa2vux5rnpc3ly4a9c0u8724
```

**Unable to deploy your contract or initializing it using deploy-ft.js**

Let's check for some common causes:

* First, make sure you have `.env` file saved and it's in the correct format as given in the tutorial.
* If you're getting an error message like `UnauthorizedError: { "message":"Invalid authentication credentials"` then make sure to replace the &lt;API\_KEY&gt; with your correct API key which you copied from your DataHub Dashboard.
* If you are getting `Error: Cannot find module 'secretjs'` make sure you installed the packages correctly using `npm install --save secretjs dotenv @iov/crypto`
* If you see `Error: ENOENT: no such file or directory, open 'my-snip721/contract.wasm'` make sure that file path you are using in your deploy script points to the generated `contract.wasm`

After this executed successfully you can take the program you created in the [first tutorial](https://learn.figment.io/tutorials/create-your-first-secret-nft), change the contract address to the one of your contract and interact with it in the same way!

# Conclusion

Congratulations! We have made it to the end of the first instalment of this Secret NFT series. We have covered a lot of information, and I feel you can really be proud of what you have achieved. Just to recap:

* You created and compiled your very own secretNFT contract, based on snip721
* You explored different parameters to configure the contract to your liking
* You created an instance of your contract on the secret testnet, ready to be interacted with

This is a solid foundation to play with and build upon!

# About the author

This tutorial was created by [Florian Uhde](https://twitter.com/florianuhde), a software engineer and game developer with a passion for blockchain, creativity and systemic design.

# References

snip721 Reference Implementation: [Github Repo](https://github.com/baedrik/snip721-reference-impl)


This is the second part of a series about using snip721 tokens on the Secret network.

Deploy your own secret NFT

Create an account

Setup the project

Get the balance

{% hint style="info" %}
Feel Free to skip this section and [**start the challenges**](https://learn.figment.io/tutorials/setup-the-secret-project)
{% endhint %}

------------------------

# What is Secret?

Secret Network is the first blockchain with privacy-preserving smart contracts. That means applications built on Secret can utilize encrypted data without revealing it to anyone, even the nodes in the network. For the first time, Secret Network allows developers to build powerful, permissionless, privacy-preserving applications - Secret Apps.

Secret Apps - powered by “secret”, privacy-preserving smart contracts - are built with CosmWasm smart contracts that are written in the Rust programming language and deployed on the Secret Network.

The Secret Network blockchain itself is based on Cosmos SDK / Tendermint, meaning the network has its own independent consensus, on-chain governance, and features like slashing and delegation.

## Why build on Secret?

Secret Network combines the best features of decentralized, open-source networks, and blockchains with the benefits of data privacy and improved usability. These improvements are critical for achieving mass adoption.

Developers can enjoy the benefits of smart contracts and DApps: they are robust, unstoppable, censor-resistant, and transparent. But blockchains, and by extension smart contracts have one glaring problem that is often overlooked - all data stored on them is public. In that sense, blockchains are worse than existing Web 2 solutions when it comes to privacy.

Instead of trusting your data with a single organization, you now have to trust everyone. Secret contracts and Secret Apps combine these benefits of DApps but add the ability to keep data private, helping remove one of the biggest barriers to mass adoption of the decentralized web.

## What can you build on Secret?

As the first blockchain to support encrypted inputs, encrypted outputs, and encrypted state for smart contracts, Secret Network allows for new kinds of powerful decentralized applications to be built. This can unlock substantial value across multiple verticals and industries, including the following:

* Decentralized Finance: Support for privacy-preserving asset transfers, lending, and more
* Data sharing: Sharing and monetizing data while keeping it secure
* Machine learning: Discovering powerful insights while protecting underlying data
* Healthcare: Allowing research over encrypted data, driving innovation
* Gaming Industry: Enabling more open and more usable gaming experiences

# Network Specifications

## Transaction Fees

Transaction fees are currently paid in the native token, SCRT. Since the Secret Network can handle many transactions quickly and the demand for transactions is low, the current cost of Secret transactions is very low (ie. almost nothing).

## Transaction Speed & Finality

Tendermint BFT typically have block times between 1 and 8 seconds, and can handle up to thousands of transactions per second. The Secret Network has a block time of about 7.25 seconds per block.

A property of the Tendermint consensus algorithm is instant finality. This means that forks are never created as long as more than a third of the validators are honest [**Byzantine**](https://en.wikipedia.org/wiki/Byzantine_fault). Users can be sure that their transactions are finalized as soon as a block is created, unlike Proof-of-Work blockchains, like Bitcoin and Ethereum.

## Languages supported

Secret Contracts are developed with the Rust programming language and compiled to WebAssembly ([WASM](https://rustwasm.github.io/docs/book/)) binaries.

## EVM compatibility

The Secret Network has launched a bridge with Ethereum, bringing cheaper and more usable privacy to Ethereum and Ethereum-based assets. It allows users to create synthetic (wrapped) ETH and ERC-20 tokens on Secret Network that can be used with full privacy, at a lower cost.

The bridge is bidirectional, so Secret Tokens can then be redeemed for their Ethereum-based equivalent.

## Role of the SCRT token

The SCRT is the token that: 
1. secures the Secret Network as the asset at stake, which earns its stakers new issuance rewards and transaction fees.
2. is used to pay for transactions on the network.
3. is used by stakers to vote on-chain to set Secret Network policy.


What is Secret?

We no longer host the Pathway pages on this website, the content has moved to the `learn-web3-dapp` repository at <https://github.com/figment-networks/learn-web3-dapp#-get-started>.

For less experienced developers or for anyone who wants to dive in without complicated setup, **[we recommend using Gitpod](https://gitpod.io/#https://github.com/figment-networks/learn-web3-dapp)** to work with the `learn-web3-dapp` project (this requires you to have a GitHub account to sign in). Gitpod can save you a considerable amount of time, as you don't have to install dependencies or set up a development environment - everything just works!

If you are an experienced developer, [cloning the repo locally](https://github.com/figment-networks/learn-web3-dapp#-clone-locally) is still possible, however you might encounter various system configuration issues depending on how your local environment is set up. A minimum of NodeJS version 14.17 is recommended, and you'll want to make sure you have the `build-essential` package installed. You'll also want to make sure your Rust toolchain is up to date and that you have the `wasm32-unknown-unknown` target triple set up and installed.


You can now access the Secret 101 Pathway on our GitHub repo.