Skip to content

Latest commit

 

History

History
96 lines (66 loc) · 4.85 KB

README.md

File metadata and controls

96 lines (66 loc) · 4.85 KB
Raw

Proof of concept for Community SBT

Based on SBT NEP: near/NEPs#393. Early Design: https://hackmd.io/ZvgUeoF4SMGM4InswH0Dsg

This is a permissioned version of the Community Open contract: only contract admins can acquire a new class and designate minters.

See root README for deployed smart contract addresses.

Usage

Community SBT contract is designed for a communities with authority. The contract is an SBT issuer and allows admins to acquire new classes and set minters to mint new SBTs. The class restriction is implemented in the sbt_mint function.

The SBT minting and revoking can be only executed by an account which has Minting Authority, hence ideally, minter should be a DAO. Minting Authorities are set per class ID. Each class ID can has one more minter.

Only contract admin can add or revoke minting authority.

TTL

Time To Live (TTL) is a duration in milliseconds used to define token expire time: expires_at = now + ttl. Every token class has its own MAX_TTL value which is being set when enabling new class for minting. The max_ttl value can be changed by an admin by calling the set_max_ttl method.

SBT classes

SBT contract supports multiple token classes: one issuer can mint tokens of many classes. The community-sbt contract requires an admin to enable a token class and set if minting of SBT of that class requires IAH humanity check. Moreover, admin must assign a minting authority (an address which is authorized to mint).

near call CTR_ADDRESS enable_next_class \
  '{"requires_iah": true, "minter": MINTER_ADDRESS}' --accountId ADMIN

Contract admin should set the class metadata using:

near call CTR_ADDRESS set_class_metadata \
  '{"class": ClassId, "metadata": "Metadata JSON"}' --accountId ADMIN

And anyone can query the class metadata:

near view CTR_ADDRESS class_metadata '{"class": ClassId}'

Minting

The mint function requires a deposit which is computed by the required_sbt_mint_deposit function. The whole deposit is passed to the registry to cover the storage costs. Metadata attributes:

  • expires_at is be overwritten to now + ttl.
  • issued_at is be overwritten to "now".
  • reference and reference_hash are optional - it should be related to token characteristics. See memo and metadata guidelines.
near call CTR_ADDRESS sbt_mint \
  '{"receiver": "receipient.near",
    "metadata": {"class": 1, "reference": "link to token characteristics"},
    "memo": "optional operation info"}'  \
  --deposit 0.01 --accountId MINTER

It is also possible to mint few tokens at once. In the example below, recipient1 will get 1 token, recipient2 will get 3 tokens. Note that one account can have at most one token of a give class (SBT standard doesn't allow one account to hold more than one token of the same class).

near call CTR_ADDRESS sbt_mint_many \
  '{"token_spec": [
       ["receipient1.near",
        [{"class": 1, "reference": "token1 ref"}]],
       ["receipient2.near",
        [{"class": 1, "reference": "token2 ref"}, {"class": 2, "reference": "token3 ref"}, {"class": 3, "reference": "token4 ref"}]]
    ],
    "memo": "optional operation info"}'  \
  --deposit 0.04 --gas 100000000000000 --accountId MINTER

To query minting authorities of a given class call:

near view CTR_ADDRESS minting_authorities \
  '{"class": CLASS_ID}'

Memo and Metadata

Guidelines for using metadata and minting memo field.

Both sbt_mint and sbt_mint_many provide an optional memo argument which should be used as a reference for minting (operation data), usually a justification for a minting or a link to a Near Social post for justification. memo is not going to be recorded in the token.

If you want to record extra data to the token, then you should set it as a token metadata.reference (usually a JSON or a link to a JSON document). That should be related to a token, hence be a part of the token characteristic rather then the mint operation.

There is also contract metadata and class metadata - both are managed by the contract admin.

  • Contract Metadata should describe the contract and the issuer as well as common data to all token classes.
  • Class Metadata should describe the class and all common data for all tokens of that class. For example, token characteristics shared by all tokens of a given class should be set in the class metadata, rather than copied over all token metadata. Examples include icon, symbol etc...