Credit makes the world go ‘round. For most individuals, financing major expenses like a home or car is a necessity, and credit cards are used over cash due to their reward programs, financial protections, and the opportunity to build credit lines.

However, in the crypto space, there is yet to be a comprehensive credit system. Current decentralized lending offerings are often too simple—once a user’s assets dip below a threshold, their collateral is immediately liquidated. This is equivalent to a bank instantly foreclosing your house when the stock market dips or there is a late mortgage payment. Though there have been improvements with user and collateral management and protection, decentralized lending is still largely unforgiving.

As for credit cards, existing crypto credit cards are tethered to traditional banking systems and do not solely operate off-chain. At most, they provide points and rewards via tokens. Currently, airdrops and whitelists, usually managed by individual projects, serve as the primary means of rewarding on-chain transactions. There isn’t a dedicated system to track points and build credit on-chain, despite the number of crypto users worldwide surging to 420 million in 2023, with 54 million in the US as reported by IMF. In addition, countries like Venezuela are experiencing widespread adoption of crypto for both salaries and everyday transactions.

What if we could establish an DeFi credit system that offers smart contract-backed credit cards for borrowing funds and earning rewards, akin to traditional credit cards?

By operating on the blockchain, this system would not only provide rewards for on-chain transactions, but also enhance credit scoring. Unlike traditional credit score formulas and criteria, an on-chain score calculation increases transparency. Moreover, while traditional credit scoring systems lack global standardization (e.g. FICO in the US, CIBIL in India, etc.), the blockchain operates on a global scale, allowing for a universal credit system.

The basic workflow of the on-chain credit platform can look like the following:

Here, the DeFi credit platform has its own token pool, which can have a variety of tokens such as USDC for better hedging. Like a classic DeFi protocol, customers (Fig. 1: User 1) can stake their tokens in the token pool to receive interest payments. The DeFi credit platform can provide interest payments by performing on-chain and off-chain investments.

On top of this, the DeFi credit platform will provide an on-chain credit card. Customers (Fig. 1: User 2) can borrow money and make payments with the on-chain credit card, along with interest payments if the user cannot pay their full outstanding balance. Here, all the components of the credit card borrowing solely exists on-chain.

Users can build an on-chain credit score through borrowing or staking history, and establish custom credit limits, interest rates, and late payment rules.

Of course, it wouldn’t be a true credit card without a solid rewards system. A potential rewards system, perhaps with Aave, may look like this:

Here, Aave contributes significantly to the token pool through staking, allowing the DeFi credit platform to invest in diverse projects across blockchain and traditional domains. To benefit Aave as well, the DeFi credit platform will allow users who interact with Aave through the credit card to gain heightened yields. Aave in turn gains customer expansion and passive interest earnings from the token pool.

Another potential rewards system can be with Yuga Labs:

In this scenario, by taking a percentage of the credit card fees, Yuga Labs will send airdrops to customers that purchased a Yuga Lab NFT with the on-chain credit card. In return, the DeFi credit platform will see increased usage and adoption of credit cards.

To measure how feasible this is, I’ve implemented a small proof of concept for the DeFi credit platform and the credit card. In this implementation, we utilize the ERC20 approve function, which allows a user to spend a specified amount of the caller’s tokens. For our use case, the credit platform will call approve for a credit card user to spend up to their credit limit.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/access/AccessControl.sol";
import "@openzeppelin/contracts/token/ERC20/IERC20.sol";

contract CreditPlatform is ERC20, Ownable {
    uint256 public constant DEFAULT_CREDIT_LIMIT = 1000;
    uint256 public constant DEFAULT_CREDIT_SCORE = 400;

    mapping(address => uint256) public creditLimits;
    mapping(address => uint256) public creditScores;

    constructor(string memory name, string memory symbol, uint256 supply) ERC20(name, symbol) Ownable(msg.sender) {
        _mint(msg.sender, supply);
    }

    function addCreditWallet(address creditWalletAddr) external onlyOwner {
        setCreditLimit(creditWalletAddr, DEFAULT_CREDIT_LIMIT);
        setCreditScore(creditWalletAddr, DEFAULT_CREDIT_SCORE);
        approve(creditWalletAddr, DEFAULT_CREDIT_LIMIT);
    }

    function setCreditLimit(address user, uint256 limit) public onlyOwner {
        creditLimits[user] = limit;
    }

    function creditLimit(address user) public view returns (uint256) {
        return creditLimits[user];
    }

    function setCreditScore(address user, uint256 limit) public {
        creditScores[user] = limit;
    }

    function creditScore(address user) public view returns (uint256) {
        return creditScores[user];
    }

    function approve(address user, uint256 value) public override onlyOwner returns (bool) {
        require(value <= creditLimits[user], "Allowance exceeds the credit limit for user");
        return super.approve(user, value);
    }
}

contract CreditCard is AccessControl {
    CreditPlatform public creditPlatform;

    bytes32 public constant AUTHORIZED_USER_ROLE = keccak256("AUTHORIZED_USER_ROLE");

    address private creditPlatformAdmin;
    uint256 private _balance;
    uint256 private _point;

    constructor(address creditPlatformAddr, address user) {
        creditPlatform = CreditPlatform(creditPlatformAddr);
        creditPlatformAdmin = msg.sender;

        _grantRole(DEFAULT_ADMIN_ROLE, msg.sender);
        _grantRole(AUTHORIZED_USER_ROLE, user);
        _grantRole(AUTHORIZED_USER_ROLE, msg.sender);
    }

    function balance() public view onlyRole(AUTHORIZED_USER_ROLE) returns (uint256) {
        return _balance;
    }

    function point() public view onlyRole(AUTHORIZED_USER_ROLE) returns (uint256) {
        return _point;
    }

    function setBalance(uint256 newBalance) external onlyRole(DEFAULT_ADMIN_ROLE) {
        _balance = newBalance;
    }

    function setPoint(uint256 newPoint) external onlyRole(DEFAULT_ADMIN_ROLE) {
        _point = newPoint;
    }

    function transfer(address to, uint256 value) external onlyRole(AUTHORIZED_USER_ROLE) {
        creditPlatform.transferFrom(creditPlatformAdmin, to, value);
        creditPlatform.setCreditScore(address(this), creditPlatform.creditScore(address(this)) - 100);
        _setBalance(_balance + value);
    }

    function payBalance(uint256 value) external onlyRole(AUTHORIZED_USER_ROLE) {
        creditPlatform.transfer(creditPlatformAdmin, value);
        creditPlatform.setCreditScore(address(this), creditPlatform.creditScore(address(this)) + 100);
        _setBalance(_balance - value);
    }

    function _setBalance(uint256 newBalance) internal virtual onlyRole(AUTHORIZED_USER_ROLE) {
        _balance = newBalance;
    }
}

The smart contract workflow will look like the following:

1. With the CreditPlatform admin wallet, deploy the CreditPlatform contract.

2. With the CreditPlatform admin wallet, deploy the CreditCard contract, and pass in the address of the credit card’s authorized user.

3. To borrow funds, the credit card user will call the CreditCard contract’s transfer function.

4. To payback the balance, the credit card user will first send funds to the CreditCard contract, and then call the CreditCard contract’s payBalance function. The code can be changed so that the credit card user can directly pay the balance with his/her address.

Such a DeFi credit platform seems quite feasible!

As a parting thought, I’ve outlined a few potentials of the DeFi credit platform below—personally, I’m excited about the prospect of using such a product:

• The DeFi credit platform’s success will largely rely on the backing institution. If established institutions such as Amazon or JP Morgan created a DeFi credit platform, it could usher a new era of crypto utilization.

  • If an established institution backed the DeFi credit platform, an implicit KYC can be formed with the credit card.

• On-chain credit scoring systems can expand to off-chain borrowing, which is especially useful for immigrants and travelers.

• Customer can select credit cards and lenders based on its credit score calculation, as the formula is on-chain

• Establishing tier-based on-chain credit cards (similar to Amex Platinum card vs Amex Blue Cash Everyday card) can provide further benefits

• Confidentiality of transactions and credit scores may be achieved with ZK proofs or technologies such as Dusk

In the blockchain world where “code is law,” irreversible losses can easily occur with smart contract exploits. At the same time, code on the blockchain is immutable. So what do you do?

Auditing contracts can provide high confidence, but if you want to change code logic in the future, consider creating a proxy contract.

What are proxy contracts?

Proxy contracts are contracts that reroute calls to other contracts. Similar to an API gateway, a proxy contract can serve as a single endpoint for callers and redirect calls to other resources. As shown in the diagram below, the proxy contract can forward calls to logic (aka implementation) contracts, contracts that contain the logic of the service.

If a bug is found or a feature upgrade is needed in the logic contract, the smart contract owner can simply deploy a new logic contract and submit a transaction to the proxy contract to update its logic contract address. By doing so, the proxy contract will start rerouting calls to the new logic contract, thereby “upgrading” the service.

I’m interested… how do proxy contracts work?

At a low level, proxy contracts reroute data by using the EVM’s delegatecall opcode, which allows a contract to execute code of another contract. Here, it is important to note that delegatecall executes the callee’s code in the context of the caller’s state. This information makes upgrades possible, since the proxy contract maintains the service data (aka state). Therefore if our service is an NFT collection, the token balances and URIs will be stored in the proxy contract, while the logic on how to mint and transfer tokens will be stored in the logic contract. Upgrading the service may change who can mint tokens, but the token balances will remain the same since the proxy contract remains constant.

Though writing everything in the proxy’s data prevents data loss during upgrades, we now have to worry about the logic contract overwriting existing proxy contract data. The proxy contract maintains important data such as the logic contract address, and so it is crucial that the logic contract does not write token metadata in the same data storage slot. The most common and simplest way to solve this is through the “Unstructured Storage” proxy pattern, where a random storage slot is chosen for variables in a proxy contract. This slot is sufficiently random so the probability of a logic contract declaring a variable at the same slot is negligible. An Ethereum standard for this exists as EIP-1967: Standard Proxy Storage Slots, and OpenZeppelin provides implementation for this standard.

Got it! What are the different types of proxies I can use?

The two main proxy patterns to look at are the UUPS proxy pattern and beacon proxy pattern. OpenZeppelin implementations for both exist. In essence, both proxy contracts re-route calls to logic contracts. However, they each have its own merits:

• UUPS (Universal Upgradeable Proxy Standard) proxy pattern

  • A UUPS proxy inherits the logic contract address location, and holds the upgrade logic in the logic contract.

  • The UUPS proxy was created as an improvement to the transparent proxy, which holds the upgrade logic in the proxy contract. This makes UUPS proxies cheaper than transparent proxies to deploy and send transactions with.

  • Since the upgrade logic exists in the logic contract, the service has the option to freeze logic changes by removing the upgrade logic in the final logic contract version.

• Beacon proxy pattern

  • In the beacon proxy pattern, three main components exist: the beacon contract, beacon proxy contract, and logic contract(s). The beacon contract holds the address of the logic contract, and the beacon proxy contract retrieves the address from the beacon contract to reroute calls to. While this may seen redundant at first, if more than one beacon proxy points to a single beacon, batch proxy upgrades can happen by updating the logic contract address stored in the beacon.

  • For n NFT collections spread across k beacon contracts, only a total of k blockchain calls need to be made for an upgrade.

The gas costs of the different types of proxies are nicely summarized here.

Great, how do I implement my proxy?

OpenZeppelin provides Upgrades Hardhat plugins for proxy contract implementation. The step-by-step tutorial for Hardhat can be found in this post.

Alternatively, using the OpenZeppelin APIs and libraries for upgrades, we can deploy our contract directly. Here are some contract examples:

Beacon.sol - Beacon contract

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.9;

import "@openzeppelin/contracts/proxy/beacon/UpgradeableBeacon.sol";

contract BeaconContract is UpgradeableBeacon {
    constructor(address _logicAddr) UpgradeableBeacon(_logicAddr) {}
}

BeaconProxy.sol - Beacon proxy contract

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.9;

import "@openzeppelin/contracts/proxy/beacon/BeaconProxy.sol";

contract BeaconProxyContract is BeaconProxy {
    constructor(address _beacon) BeaconProxy(_beacon, "") payable {}

    function setBeacon(address _beacon) public {
        _setBeacon(_beacon, "");
    }

    function beacon() public view virtual returns (address) {
        return _beacon();
    }
}

BeaconLogicContract.sol - Beacon logic contract

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.9;

import "@openzeppelin/contracts-upgradeable/token/ERC1155/ERC1155Upgradeable.sol";

contract BeaconLogicContract is ERC1155Upgradeable {
    /// @custom:oz-upgrades-unsafe-allow constructor
    constructor() {
        // Automatically lock the implementation contract during deployment:
        // https://docs.openzeppelin.com/upgrades-plugins/1.x/writing-upgradeable#initializing_the_implementation_contract
        _disableInitializers();
    }

    event ContractBalance(address indexed account, uint256 indexed id, uint256 balance);
    event ContractVersion(string indexed version);

    function initialize() public initializer {
        __ERC1155_init("ipfs://baseUriPath");
    }

    function mint(address _to, uint256 _id, uint256 _amount) external {
        _mint(_to, _id, _amount, "");
    }

    function balances(address _account, uint256 _id) public virtual {
        uint256 _balance = balanceOf(_account, _id);
        emit ContractBalance(_account, _id, _balance);
        emit ContractVersion("V1");
    }
}

UUPSProxy.sol - UUPS proxy contract

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.9;

import "@openzeppelin/contracts/proxy/ERC1967/ERC1967Proxy.sol";

contract UUPSProxy is ERC1967Proxy {
    constructor(address _logic) ERC1967Proxy(_logic, "") payable {}
}

UUPSCompatibleLogicContract.sol - UUPS compatible logic contract

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.9;

import "@openzeppelin/contracts-upgradeable/token/ERC1155/ERC1155Upgradeable.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol";

contract UUPSCompatibleLogicContract is ERC1155Upgradeable, UUPSUpgradeable {
    /// @custom:oz-upgrades-unsafe-allow constructor
    constructor() {
        // Automatically lock the implementation contract during deployment:
        // https://docs.openzeppelin.com/upgrades-plugins/1.x/writing-upgradeable#initializing_the_implementation_contract
        _disableInitializers();
    }

    event ContractBalance(address indexed account, uint256 indexed id, uint256 balance);
    event ContractVersion(string indexed version);

    function initialize() public initializer {
        __ERC1155_init("ipfs://baseUriPath");
    }

    function mint(address _to, uint256 _id, uint256 _amount) external {
        _mint(_to, _id, _amount, "");
    }

    function balances(address _account, uint256 _id) public virtual {
        uint256 _balance = balanceOf(_account, _id);
        emit ContractBalance(_account, _id, _balance);
        emit ContractVersion("V2");
    }

    /**
     * @dev See {UUPSUpgradeable-_authorizeUpgrade}.
     *      This function is called internally when upgrading contracts by the proxy.
     *      The modifier `onlyOwner` makes sure that only the owner of the contract can upgrade the contract.
     */
    function _authorizeUpgrade(address) internal override {}
}

I’m ready to create my service using proxy contracts!

I hope that’s all the things you need to know about proxy contracts!

Blockchains are immutable, but your service doesn’t have to be.

Appendix

[1] Notable proxy storage patterns

Apart from Unstructured Storage, notable proxy storage patterns are:

• Inherited Storage: Both the proxy and logic contract inherit the same storage structure to ensure that both adhere to storing the necessary proxy state variables. An in-depth explanation is provided by OpenZeppelin here.

• Eternal Storage: Storage schemas are defined in a separate contract that both the proxy and logic contract inherit from. An in-depth explanation is provided by OpenZeppelin here.

• Diamond Storage: Similar to Unstructured Storage, values are stored at arbitrary positions. Additionally, the Diamond Standard uses a lookup table for locations of the logic contracts. Diamond Storage is a work-in-progress defined in EIP-2535: Diamonds, Multi-Facet Proxy.

  • Integration with OpenZeppelin Contracts can be found here.

  • Trail of Bits has done an audit on the Diamond Standard, and the Diamond Standard team has since released a new version and published this article.

  • Aavegotchi and PieDAO are two main services that use/have used the Diamond Standard. Additional services that are using the Diamond Standard can be found here.

If you browse the top NFT collections on OpenSea, you’ll notice they all have one thing in common—the token standard ERC-721.

What is a token standard and why do we need them? Well, an NFT can really be implemented in any way, as long as it is distinguishable from other tokens. But since we need an easy way for NFT marketplaces to recognize and understand what NFTs are, token standards come in handy. The finalized official Ethereum token standards are listed here, although a quick google search will unfold numerous unofficial ones that cater to various niche use cases.

Currently, the main Ethereum token standards are ERC-20, ERC-721, and ERC-1155. The differences between the standards can be found in many articles, but most focus on fungibility: ERC-20 represents fungible tokens, ERC-721 represents non-fungible tokens, and ERC-1155 represents both fungible and non-fungible tokens.

Below are the ERC-721 and ERC-1155 specifications for transfer:

// ERC-721 transfer specification
event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId);

// ERC-1155 transfer specification
event TransferSingle(address indexed _operator, address indexed _from, address indexed _to, uint256 _id, uint256 _value);

As shown above, ERC-721 and ERC-1155 achieve non-fungibility within a token collection simply through token identifiers (_tokenId and _id). ERC-1155s additionally support fungibility by letting more than one token to exist for a token ID (_value represents the token count of a token ID). This means that we can restrict _value to be at most 1 if we want to guarantee non-fungibility for ERC-1155 NFTs. With ERC-1155, we can create NFT collections that have both fungible and non-fungible objects.

Another way to achieve non-fungibility with ERC-1155s is with URI variables. ERC-1155 specifies that if the string {id} exists within any URI, clients must replace it with the actual token ID in hexadecimal form. Using this variable, ERC-1155 suggests “[t]he top 128 bits of the uint256 _id parameter in any ERC-1155 function MAY represent the base token ID, while the bottom 128 bits MAY represent the index of the non-fungible to make it unique.” In other words, a single contract can represent multiple collections by representing an NFT collection with the high bits of {id}. While this is also possible for ERC-721s since it has a tokenId, with an ERC-1155, a single team may only ever have to deploy a single contract for all its NFTs due to its support for both fungible and non-fungible collections.

One other notable ERC-1155 feature is batch transfers, as hinted by its transfer event name above (TransferSingle). The ability to have batch transfer events means that a batch mint, a batch safe transfer, or a batch burn can be processed in a single transaction. The gas price for a batch action will be similar to that of a single action, which is particularly beneficial for projects where the mint price less than the gas price. Furthermore, batch mints come in handy for token airdrops, since many holders own more than one NFT under the same collection. Additionally, OpenZeppelin’s ERC-1155 implementation saves gas by having only the base URI parameter in its _setURI function, so that the URI is set at the contract level and not per token.

ERC-1155s can save gas costs for both developers and buyers. So why are all the top NFT projects ERC-721 tokens?

While I haven’t found a clear answer, I did notice that there was a strong perception that all NFTs are ERC-721s (with the exception of CryptoPunk). I observed this in NFT community posts, and even the popular Azuki NFT team posted the following tweet:

Here, the Azuki team made changes to the OpenZeppelin ERC-721 implementation to do exactly what the ERC-1155 standard already does, despite the OpenZeppelin ERC-1155 implementation existing since 2020. The Azuki team also stated the ERC-721A “ for the first time ever in the NFT space, enables minting multiple NFTs for essentially the same cost of minting a single NFT.” While this may be true within ERC-721s, it is technically not true within the NFT space since ERC-1155 has already achieved this.

Another guess is that some NFT teams do not care about gas costs inflicted on buyers. At this point, a lot of us have become indifferent to high gas prices, and we are used to paying for ERC-721s. Not only that, but the support for a single contract to represent multiple collections does not yet exist in major marketplaces, such as OpenSea and LooksRare. This leads to developers ending up deploying one contract per collection even for ERC-1155 contracts.

If not the reasons above, perhaps teams are relying on gas solutions with Layer 2 (and potentially Layer 3) scaling instead. Please let me know in the comments below if you know any other reasons why the top NFT projects use ERC-721s over ERC-1155s. Regardless, we should strive to stay up to date on the latest standards and adopt the best choice.

If there was a modern day Portlandia pilot episode, the title of it would be “Put a Token On It!” NFTs have helped us define ownership in digital assets, leading to the tokenization of everything, starting from pixels to real estate.

The rise of NFTs has blown new life into developing “the metaverse,” and in particular, metaverse blockchain games. Multi-billion dollar companies such as Samsung, JP Morgan, and PwC have invested in the top metaverse games, and celebrities have publicly endorsed their holdings as well. Decentraland and The Sandbox are currently the top leading NFT metaverse games, and at the very heart of their gameplay, they allow users to build a digital world of their own and experience their creations with other players. However if you’re looking to escape to the Metaverse to avoid high real estate prices, chances are, you can’t afford the Metaverse either. I know I can’t.

Games such as Decentraland and The Sandbox require users to first own LANDs, NFTs that represent digital real estates that users can build on. The present floor price for LANDs is around $10K due to its finite supply, and although less popular games with cheaper LAND exist, the number of users is highly important for social platforms. While there is a free way to play, the free version is limited to observing LANDs of players who paid or decorating your avatar with airdrops. Tokenomics for the top NFT metaverses today don’t diverge much from this, leaving users without much choice but to pay or be a spectator.

Is this pay-to-play economics bad? I don’t think so. Tokenizing land and assets gives every player significant ownership over their creations, and limited land provides exclusivity.

Be that as it may, we live in a world where storage is increasingly cheap and demand for metaverses is booming. Is the tokenization of everything affecting gameplay? Can a free-to-build NFT game benefit players and creators alike? Nifty Island says yes.

On its homepage, Nifty Island introduces itself as the following:

Nifty Island is an open social gaming platform and virtual world being developed by Nyft Studios. It will be the centerpiece and first title in what we call the Nyftverse: a set of interoperable games, a marketplace, play-to-earn protocol, game developer tools and infrastructure —all powered by web3 to realize the dream of a truly open and player-owned metaverse.

We don't believe in land scarcity in a world of digital abundance. Every user is greeted with their own island, entirely free, and tasked with building their home in the metaverse. The player is able to build structures, play and create games, import their nft collection, purchase new 3D, metaverse-ready NFTs from our marketplace, earn new items for their island by completing quests, and socialize with other players via voice and text chat.

Nifty Island is a refreshing take on the pay-to-do-anything custom that many NFT games follow. I’ve been following Nifty Island for around a year now, and I was lucky enough to test out its Alpha version this February when it came out .

At the start the game, players are given a chunk of land and B33, a robot pet to talk to and roam islands with. The mechanics for sculpting land and assembling buildings are smooth, and I was able to create a huge turtle shaped island fairly easily. Multiplaying and voice chat works effortlessly well with large crowds, at least for the closed alpha. Charles, the founder of Nifty Island who is extremely involved with the Nifty Island community in various ways, often popped by players’ islands to help out with builds or to just have a good time.

Everything is customizable in Nifty Island including the density of the clouds and the size of an avatar’s pupil. Players can also showcase their existing NFTs as art pieces on their island, or buy Nifty Island NFTs. Nifty Island NFTs serve as in-game utilities for those who want to have a bigger island or cooler skins, and does not exclude non-paying players from enjoying the core gameplay.

What should or should not be tokenized in the metaverse will vary for each player depending on what they value the most. Regardless, metaverse companies that introduce new tokenomics and provide more options for players are important. If you’re interested in checking out an all-inclusive metaverse, give Nifty Island a try.

Let me know in the comments below if you know of any metaverse games with other unique tokenomics.

If you have written or read blockchain code, you are probably familiar with Go. Go Ethereum is one of the original implementations of the Ethereum protocol, and currently has the biggest user base for Ethereum clients. On top of this, Go is excellent for high scale projects and allows an object-oriented style of programming.

However if you look on the world wide web for deploying an NFT in Go, it’s currently hard to fund a full end-to-end tutorial. This is because much of the smart contract development has been targeted towards browser based apps, focusing the priority on Javascript or Typescript based tutorials.

In this post, we will go over end-to-end on how to deploy an NFT contract and mint NFTs with that contract in Go. Let’s get started!

All code used in this tutorial can be found here: https://github.com/noopmood/go-erc1155-tutorial . The OS used in this tutorial is macOS Monterey v12.2.1.

1. Creating an ERC-1155 contract

One of the most famous NFT and fungible token contract implementation library is OpenZeppelin Contracts, used by Bored Ape Yacht Club, Cool Cats, Tubby Cats, and many more. Code reuse is highly recommended when creating smart contracts for security reasons. Borrowing an excerpt from Mastering Ethereum, “Try not to reinvent the wheel. If a library or contract already exists that does most of what you need, reuse it.”

OpenZeppelin API docs for an ERC-1155 contract can be found here. For easy testing purposes, we will be exposing the internal _mint method so anyone can mint tokens with our contract.

1. Create a contracts directory for our smart contract code.

2. Inside contracts, create a CoinNft.sol file with the following contents

// Contract based on https://docs.openzeppelin.com/contracts/4.x/erc1155
// SPDX-License-Identifier: MIT

pragma solidity ^0.8.0;
import "@openzeppelin/contracts/token/ERC1155/ERC1155.sol";

contract CoinNft is ERC1155 {
  constructor() ERC1155("https://raw.githubusercontent.com/noopmood/TutorialNFTInGo/main/metadata/{id}.json") {}
    
  function mintCaller(uint256 tokenId, uint256 amount) public {
    _mint(msg.sender, tokenId, amount, "");
  }
  function mintAddress(uint256 tokenId, uint256 amount, address addr) public {
    _mint(addr, tokenId, amount, "");
  }
}

The HTTPS link above contains the metadata of our NFT. The string {id} will be replaced with the actual token ID by clients, in lowercase hexadecimal and leading zero padded to 64 hex characters. This means for token ID 0, clients would replace {id} with 0000000000000000000000000000000000000000000000000000000000000000 to retrieve JSON at https://raw.githubusercontent.com/noopmood/TutorialNFTInGo/main/metadata/0000000000000000000000000000000000000000000000000000000000000000.json, which has the contents:

{
  "description": "Gold coin",
  "image": "https://openmoji.org/data/color/svg/1FA99.svg",
  "name": "Gold",
  "attributes": [
    {
      "trait_type": "Color",
      "value": "Gold"
    },
    {
      "trait_type": "ID",
      "value": "0"
    }
  ]
}

Here, we can see that a token ID of 0 represents our gold token.

2. Create a Go binding

To interact with the contract, we will need to implement the Ethereum API in Go. Doing so is not trivial due to various edge cases, but luckily for us, Go Ethereum has abigen that automatically does this for us. The abigen library also handles all remote client API work for us, so we don’t have to worry about RPC codes. To use abigen, we simply have to provide a solidity contract and it will generate the full Go source code. On top of this, abigen is compile time checked, so you get no surprises during deployment. For more information on abigen, please visit Go Ethereum’s documentation.

Before we feed our contract into abigen however, we will need the help of Truffle to import the OpenZeppelin library. Since Truffle has an abigen plugin, we will ask Truffle to create the Go binding through abigen for us.

1. Initialize Truffle and install dependencies.

   cd ~/TutorialNFTInGo
   
   yarn init -y
   yarn add truffle @openzeppelin/contracts @chainsafe/truffle-plugin-abigen
   
   yarn truffle init # Answer "N" for overwriting contracts

2. Add the following line to the end of truffle-config.js.

   plugins: [
     "@chainsafe/truffle-plugin-abigen"
   ]

3. Compile the contract and generate the ABI and BIN files.

   yarn truffle compile
   
   # Create the directory that will store ABI and BIN files.
   # Truffle fails silently if this directory does not exist.
   mkdir abigenBindings
   
   yarn truffle run abigen CoinNft

4. Create a Go binding, coincontract.go. The BIN file is needed to generate deploy methods on the Go contract file.

   mkdir coincontract
   
   abigen --bin abigenBindings/bin/CoinNft.bin --abi abigenBindings/abi/CoinNft.abi --pkg=main --out=coincontract.go

3. Deploying a contract

1. Create an endpoint and private key

We need an endpoint to deploy our smart contract on an EVM compatible network. Select any endpoint service, such as Alchemy or Infura, to create a personal endpoint. To use Alchemy, follow these steps to create an Alchemy app and get its HTTPS endpoint.

Next, we will need the private key of a wallet to deploy contracts and mint NFTs. If you don’t have a wallet, Metamask provides a quick and easy option.

2. Get test ether

Blockchain transactions cost fees, and so we will be using test ether to deploy our contract. While you can choose any test Ethereum network, this tutorial will use the Ropsten network. Here is my favorite Ropsten faucet website, the Thinklair Ropsten Faucet.

3. Write deployment code

If we take a look at the Go binding code we created in the steps above, we can see that Truffle has populated OpenZeppelin contract implementations for us to call. To deploy our contract, let’s call the DeployCoincontract function.

1. Create another directory and move the go-binding to the new directory if you prefer to keep everything in one Go package. Feel free to configure Go to point to the current directory if you would like the separation.

2. Create a deployer.go file to write our contract deployer function.

   package main
   	 
   import (
     "github.com/ethereum/go-ethereum/common"
     "github.com/pkg/errors"
   )
   
   type Contract struct {
     Address common.Address
     Instance *Coincontract
   }
   
   func (c *Client) DeployContract() (Contract, error) {
     contractAddress, _, instance, err := DeployCoincontract(c.Auth, c.Rpc)
     if err != nil {
       return Contract{}, errors.Wrap(err, "failed to deploy the contract")
     }
   
     return Contract{contractAddress, instance}, nil
   }

3. Create our main function to call DeployContract. The Ropsten network has a chain ID of 3. To speed up or override previous transactions, increase the gas price.

   package main
   
   import (
     "fmt"
     "math/big"
   )
   
   func check(e error) {
     if e != nil {
       panic(e)
     }
   }
   
   func main() {
     endpoint := "${YOUR_ENDPOINT}"
     privateKey := "${YOUR_PRIVATE_KEY}"
     chainId := big.NewInt(3)
   
     client, err := NewClient(endpoint, privateKey, chainId)
     check(err)
   
     client.SetNonce(big.NewInt(${YOUR_WALLET_NONCE}))
     client.SetFundValue(big.NewInt(0))
     client.SetGasLimit(uint64(8000000))
     client.SetGasPrice(big.NewInt(1875000000))
   
     contract, err := client.DeployContract()
     check(err)
     fmt.Println("Contract address:", contract.Address.Hex())
   }
   

4. Run the program.

   export GOPROXY=direct # Avoid i/o timeouts
   xcode-select --install # Install developer path
   go env -w GO111MODULE=on # Turn on auto module imports
   go mod init # Initialize the Go module
   go mod tidy # Download module imports
   go run .

   The output should look like the following:

   Contract address: ${YOUR_DEPLOYED_CONTRACT_ADDRESS}

5. Check the status of your transaction on the Ropsten Etherscan by searching with the contract address or your public wallet address. You may have to wait a few minutes depending on your gas price.

Congratulations! You have deployed an NFT smart contract to the Ropsten network!

4. Minting NFTs and fungible tokens

1. Create a minter.go file to mint NFTs.

   package main
   	 
   import (
     "math/big"
   
     "github.com/ethereum/go-ethereum/core/types"
     "github.com/pkg/errors"
   )
   
   func (c *Contract) MintToken(client Client, tokenId *big.Int, tokenAmount *big.Int) (*types.Transaction, error) {
     tx, err := c.Instance.MintCaller(client.Auth, tokenId, tokenAmount)
     if err != nil {
       return nil, errors.Wrap(err, "failed to create signed mint transaction")
     }
   
     return tx, nil
   }
   

2. Create a checkOk function in main.go to verify boolean returns.

   func checkOk(ok bool) {
     if !ok {
       panic(ok)
     }
   }

3. Append the following to the main method in main.go to create five tokens of token ID 0, which represents gold.

   client.SetNonce(big.NewInt(${YOUR_WALLET_NONCE}))
   tokenId := new(big.Int)
   tokenId, ok := tokenId.SetString("0", 16)
   checkOk(ok)
   tokenAmount := new(big.Int)
   tokenAmount, ok = tokenAmount.SetString("5", 16)
   checkOk(ok)
   fmt.Println("Minting", tokenAmount, "tokens of ID:", tokenId)
   
   tx, err := contract.MintToken(client, tokenId, tokenAmount)
   check(err)
   fmt.Println("Mint transaction:", tx.Hash()) 

4. Run the package.

   go run .

   The output should look like the following:

   Minting 5 tokens of ID: 0
   Mint transaction: ${YOUR_MINT_TRANSACTION_HASH}

5. Check the status of your transaction on the Ropsten Etherscan by searching with the transaction hash or your public wallet address. You may have to wait a few minutes depending on your gas price.

Great work! You have created a fungible token! To create an NFT, set and restrict the tokenAmount to 1. You can view the NFT in your Metamask wallet by following the steps here. At the time of writing, NFTs images are only visible on Metamask through its mobile app.

For more activities, such as minting tokens in a different address than the caller or transferring tokens, write to the chain with other functions in coincontract.go.

Final notes

• If you are looking for an Go based Ethereum client other than Go-Ethereum due to licensing issues, please let me know if you find a good one. At the time of writing, INFURA’s go-ethlibs seems to be the only viable option with MIT licensing. However go-ethlibs lacks strong tooling, particularly around contract deployment and transaction signing.

• If you are looking to deploy and create NFTs in Javascript, the Ethereum organization has an excellent tutorial.

If you haven’t heard about it already, Cosmos is a decentralized network that aims to bridge independent blockchains together to easily allow horizontal scaling.

To create a test EVM compatible private blockchain on top of Cosmos, currently the best option is to use Evmos, a proof-of-stake blockchain that is EVM compatible and built on Cosmos SDK.

This post will go over step-by-step on how to set up Evmos on a Ubuntu host. While the Evmos website does provide a quick start on how to run a Evmos testnet, many of the commands in the website were broken or uninformative during the time of my experimentation. Until the Evmos website and setup code is fixed, I hope this post will help those struggling to run a test blockchain on Cosmos.

Standing up the blockchain

Preparing the host

1. SSH into the host. If you are using AWS EC2, make sure to select Ubuntu when selecting the platform.

2. Setup golang

   1. Install golang

      wget -c https://golang.org/dl/go1.17.5.linux-amd64.tar.gzsudo tar -C /usr/local -xvzf go1.17.5.linux-amd64.tar.gzmkdir -p ~/go_projects/{bin,src,pkg}

   2. Set go environment variables

      1. Add the following lines to $HOME/.profile

         export PATH=$PATH:/usr/local/go/binexport GOPATH="$HOME/go_projects"export GOBIN="$GOPATH/bin"export PATH=$PATH:$GOPATH/bin

      2. Don’t forget to source ~/.profile

   3. Check go version

      go version
      # Output should be: "go version go1.17.5 linux/amd64"

3. Setup gcc, jq, and make

   sudo apt install gcc
   sudo apt-get update
   sudo apt-get install jq
   sudo apt install make
   
   # To install docker (since the Evmos tutorial has examples on docker), follow steps in:
   # * https://docs.docker.com/engine/install/ubuntu
   # * https://docs.docker.com/compose/install
   
   # If you are going to run docker with the sudo command,
   # modify or comment out the "env_reset" and "secure_path" lines
   # in the /etc/sudoers file.

Steps on running Evmos on a single node

1. Install Evmos

   1. Install the latest Ethermint repository

      git clone https://github.com/tharsis/ethermint.git
      cd ethermint
      make install

   2. Check installation

      ethermintd -h

2. Run a local node for Evmos

   1. ./init.sh

   2. The console output should look like the following:

      5:54PM INF received proposal module=consensus proposal=... {truncated}
      5:54PM INF received complete proposal block hash=127C91E3EFFE5B992874280EE140E448F38D42DA6D1E243895BCA996D2214F2D height=17 module=consensus server=node
      5:54PM INF finalizing commit of block hash=127C91E3EFFE5B992874280EE140E448F38D42DA6D1E243895BCA996D2214F2D height=17 module=consensus num_txs=0 root=3F30260CA9E5F2F7F7C49F8D9DB5ED723E2AF70D856AD34E66E446E1ED915F24 server=node
      5:54PM INF minted coins from module account amount=2059731934472497943aphoton from=mint module=x/bank

   3. Single machine RPC call access test

      ethermintcli rest-server --laddr "tcp://localhost:8545" --unlock-key mykey --chain-id ethermint-1

   4. Running JSON-RPC server on Evmos

      1. Enable server

         ethermintd start
         # in a different terminal:
         ethermintcli rest-server --laddr "tcp://localhost:8545" --unlock-key mykey --chain-id 8

      2. Return current ethereum protocol version

         curl -X POST --data '{"jsonrpc":"2.0","method":"eth_protocolVersion","params":[],"id":1}' -H "Content-Type: application/json" http://localhost:8545
         {"jsonrpc":"2.0","id":1,"result":"0x41"}

Steps on running Ethermint on multiple nodes

Automated testnet

1. Clone the old Evmos repository (the latest repository commands are broken)

   # To create the automated testnet, we must use the old repository
   git clone https://github.com/cosmos/ethermint.git
   cd ethermint
   make install

2. Follow steps in the old Evmos website, or create an automated testnet through Docker with the commands below:

   1. Start the localnet through Docker

      make localnet-start

   2. Verification

      # It should look something like this:
      Creating network "ethermint_localnet" with the default driver
      Creating ethermintdnode3 ... done
      Creating ethermintdnode0 ... done
      Creating ethermintdnode1 ... done
      Creating ethermintdnode2 ... done
      
      # To see files created in each node, check the build folder.
      # Check logs through:
      docker exec ethermintdnode0 tail ethermintd.log # daemon logs
      docker exec ethermintdnode0 tail ethermintcli.log # REST & RPC logs
      # Following logs:
      docker logs -f ethermintdnode0 

   3. Stop the local net by using the command make localnet-stop

Manual testnet: Option #1

1. Clone the old Evmos repository

   # To create the automated testnet, we must use the old repository git clone https://github.com/cosmos/ethermint.git cd ethermint make install

2. Create a single node

   1. Create a single node, node 1, with init.sh

3. Deploy other nodes

   1. Create another node, node 2, on another instance with with init.sh.

   2. Copy the ~/.ethermintd/config/genesis.json file from node 1 and paste it over to node 2.

4. Set seeds

   1. Get node ID of node 1 using ethermintd tendermint show-node-id.

   2. Construct the seed of node 1 using the format ${nodeID}@${IP address}:26656

   3. Add the seed of node 1 to the file ~/.ethermintd/config/config.toml of node 2, by inserting the seed into seeds.

5. Allow nodes to talk to each other

   1. Modify the firewall (for AWS, modify the EC2 security group) of node 1 to allow traffic from node 2.

6. Start the nodes

   1. Start node 1 first, then start node 2.

      1. Use command

         ethermintd start —pruning=nothing —rpc.unsafe —log_level “main:info,state:info,mempool:info” --trace

   2. The two nodes should be synchronized. Synchronization can be verified when the app hashes for committed states will be equal to each other.

Manual testnet: Option #2

1. Clone the old Evmos repository

   # To create the automated testnet, we must use the old repository git clone https://github.com/cosmos/ethermint.git cd ethermint make install

2. Create the Ethermint configuration and genesis file for each node using the ethermintd command, which can take in a list of addresses (--ip-addrs), number of nodes (-v), and type of keyring (--keyring-backend).

   1. Run the ethermintd command

      ethermintd testnet --ip-addrs=172.31.5.94,172.31.12.215,172.31.1.32,172.31.7.5,172.31.7.53 --v 5 --keyring-backend=file

   2. The generated files should be in the build directory of where you ran the command.

3. Make the following directories in each instance:

   mkdir /home/ubuntu/.ethermintd/
   mkdir /home/ubuntu/.ethermintd/config/
   mkdir /home/ubuntu/.ethermintd/config/gentxs/
   mkdir /home/ubuntu/.ethermintd/data/
   mkdir /home/ubuntu/.ethermintcli

4. scp the generated file to each instance (add the -i /home/ubuntu/ubuntu.pem flag for EC2 instances):

   sudo scp -r /home/ubuntu/testnet/build/node4/ethermintd/config/* ${hostname}:/home/ubuntu/.ethermintd/config/
   
   sudo scp -r /home/ubuntu/testnet/build/node4/ethermintd/data/* ${hostname}:/home/ubuntu/.ethermintd/data/
   
   sudo scp -r /home/ubuntu/testnet/build/gentxs/node4.json ${hostname}:/home/ubuntu/.ethermintd/config/gentxs/
   
   sudo scp -r /home/ubuntu/testnet/build/node4/ethermintcli/keyring-test-ethermint/ ${hostname}:/home/ubuntu/.ethermintcli/ 

5. Run the nodes for each instance with ethermintd start

   1. If the nodes tries to connect to itself and fails, remove itself from ~/.ethermintd/config/address.json

Final notes

• Evmos has moved from https://github.com/cosmos/ethermint to https://github.com/tharsis/ethermint. However, the official website’s tutorial corresponds to the the old version of Evmos, and so there will be conflicts/command that will not work.

• Looking at Tendermint docs may be more useful than Ethermint’s. There isn’t a 1:1 correlation in the commands/settings, but they are quite similar.

• Tendermint docs on adding non-validator vs validator: https://docs.tendermint.com/master/tendermint-core/using-tendermint.html

  • Adding a non-validator is simple. Just copy the original genesis.json to ~/.tendermint/config on the new machine and start the node, specifying seeds or persistent peers as necessary.

  • The easiest way to add new validators is to do it in the genesis.json, before starting the network.

• node_key.json

  • node_key.json is used to store the node's key. The node-id queried by ethermintd tendermint show-node-id is derived by the key, which is used to indicate the unique identity of the node. It is used in p2p connection.

• priv_validator.json

  • pri_validator.json is the Tendermint Key file that the validator will use to sign Pre-vote/Pre-commit in each round of consensus voting. As the consensus progresses, the tendermint consensus engine will continuously update last_height/last_round/last_step values.

  • Query the associated public key prefixed with icp: ethermintd tendermint show-validator

  • Query the associated bech32 address prefixed with ica: ethermintd tendermint show-address