Skip to main content

Create FT using Contract Tools

In this tutorial, we will create a fungible token (FT) using Contract Tools package. This package is a collection of common tools and patterns in NEAR smart contract development:

  • Storage fee management.
  • Escrow pattern and derive macro.
  • Owner pattern and derive macro.
  • Pause pattern and derive macro.
  • Role-based access control.
  • Derive macros for NEP standards:
    • NEP-141 (fungible token), extension NEP-148.
    • NEP-145 (storage management), and integrations for the fungible token and non-fungible token standards.
    • NEP-171 (non-fungible token), extensions NEP-177, NEP-178, NEP-181.
    • NEP-297 (events).

Introduction​

The difference of this example from the FT contract based on near_contract_standards package is the approach of using deriving macros to implement NEP standards and common patterns.

When we use deriving macros, we can bring near_contract_standards implementations into our contract without writing boilerplate code for the each method. That allows us to focus on the unique logic of our contract like minting/burning logic, access control, other custom features. So, this collection of common tools and patterns (mostly in the form of derive macros) is as a sort of OpenZeppelin for NEAR.

Basic FT Methods​

To derive basic FT methods to our contract, we need to derive FungibleToken macro to our contract struct:

This will bring all the basic FT methods defined in NEP-141 standard to our contract:

  • new
  • contract_source_metadata
  • ft_balance_of
  • ft_metadata
  • ft_total_supply
  • storage_balance_bounds
  • storage_balance_of
  • ft_resolve_transfer
  • ft_transfer
  • ft_transfer_call
  • storage_deposit
  • storage_unregister
  • storage_withdraw

To bring basic owner methods to our contract, we derived also Owner macro which adds the following methods:

  • own_get_owner
  • own_get_proposed_owner
  • own_accept_owner
  • own_propose_owner
  • own_renounce_owner

Initialization​

To initialize the basic FT contract with custom owner, metadata and storage bounds implement new method:

Transfer Hook​

To add custom logic on transfer method, we need to implement a hook. Hooks are a way to wrap (inject code before and after) component functions:

Then derive it to our contract struct:

Minting​

To mint additional supply of tokens to the owner implement mint method and restrict access only to the owner of the contract:

tip

You can modify this method as you need, for example, to allow minting only when the contract is not paused (requires deriving Pausable hook), or to allow minting only to specific accounts with a certain role or from whitelist with custom limitations.

Burning​

To burn tokens from the owner's account, we implement burn method and also restrict access:

Conclusion​

Using near-sdk-contract-tools is very simple and flexible way to create FT contract with minimal boilerplate code and focusing on business logic. You can further extend this contract with more features like pausing, role-based access control, escrow pattern, and more by deriving corresponding macros from the package.

Looking for Support?

If you have any questions, connect with us on Telegram or Discord .

Happy coding! 🚀