Fair Token Launches and Semi-Fungible Reputation in Clarity

This tutorial guides Clarity and Stacks developers on building a reputation reward system using Stacks' semi-fungible token (SFT) standard, with insights from BigMarket. It covers implementing the SFT standard, creating soulbound tokens, and integrating these with tokenomics for fair token launches. The tutorial outlines how soulbound tokens, which are managed by a DAO, contribute to a reputation system by rewarding users for on-chain and off-chain activities. It also highlights how these tokens facilitate participation in governance and access to advanced platform features, establishing a model that values contributions and decentralizes influence.

Introduction

This is a technical tutorial aimed at Clarity and Stacks developers that explores how to build a reputation reward system that works seamlessly with your projects tokenomics. See Hiro docs for introductory content.

Based on our experience on BigMarket we delve into the Stacks semi-fungible token standard which provides a great basis for a reputation system. In what follows we discuss; how to implement this standard, how to build a soul bound version of the token and how this can be linked with tokenomics to play a key role in a Fair Token launch for your project.

The SIP-013 SFT Standard

Semi-Fungible Tokens (SFTs) are digital assets that blend characteristics of both fungible and non-fungible tokens (NFTs). They are uniquely suited for representing assets where a quantity is associated with a category or identifier, such as “10 tokens of type A” and “20 tokens of type B”, all within a single contract. Some examples of real world situations where project choose SFTs to model the scenario are;

1. in game assets - eg 500 wands and 30 golden chalices

2. artworks - each artwork has multiple editions

3. reputation systems - hierarchical attainments split over multiple users

The core of the SFT standard in Clarity is summarised by the SFT Trait - a trait in clarity is like a interface or a set of functions an implementing clarity contract must provide - the Clarity Book for details. The SIP-013 SFT trait looks as follows;

(define-trait sip013-semi-fungible-token-trait
    (
        ;; Get a token type balance of the passed principal.
        (get-balance (uint principal) (response uint uint))

        ;; Get the total SFT balance of the passed principal.
        (get-overall-balance (principal) (response uint uint))

        ;; Get the current total supply of a token type.
        (get-total-supply (uint) (response uint uint))

        ;; Get the overall SFT supply.
        (get-overall-supply () (response uint uint))

        ;; Get the number of decimal places of a token type.
        (get-decimals (uint) (response uint uint))

        ;; Get an optional token URI that represents metadata for a specific token.
        (get-token-uri (uint) (response (optional (string-ascii 256)) uint))

        ;; Transfer from one principal to another.
        (transfer (uint uint principal principal) (response bool uint))

        ;; Transfer from one principal to another with a memo.
        (transfer-memo (uint uint principal principal (buff 34)) (response bool uint))
    )
)

which means a clarity contract can meet the standard and provide SFT functionality by implementing these methods.

SoulBound SFTs

The Soulbound Semi-Fungible Tokens in BigMarket (BIGR) are the foundation for the reputation system we are building. These tokens are implemented using the Stacks SIP-013 standard, but with a critical twist: they can only be transferred by the DAO and not by the user. They are in effect non-transferable, or soulbound, meaning they cannot be traded on markets. In BigMarket we decided to allow the DAO to transfer or burn tokens as a way to disincentivise ant-social or other behaviours on the platform.

For example the transfer function in our SFT contract looks like this;

(define-public (transfer (token-id uint) (amount uint) (sender principal) (recipient principal))
  (begin
    (try! (is-dao-or-extension))
    (asserts! (> amount u0) err-zero-amount)
    (let ((sender-balance (default-to u0 (map-get? balances { token-id: token-id, owner: sender }))))
      (asserts! (>= sender-balance amount) err-insufficient-balance)
      (try! (ft-transfer? bigr-token amount sender recipient))
      (try! (tag-nft { token-id: token-id, owner: sender }))
      (try! (tag-nft { token-id: token-id, owner: recipient }))
      (map-set balances { token-id: token-id, owner: sender } (- sender-balance amount))
      (map-set balances { token-id: token-id, owner: recipient }
        (+ amount (default-to u0 (map-get? balances { token-id: token-id, owner: recipient }))))
      (print { type: "sft_transfer", token-id: token-id, amount: amount, sender: sender, recipient: recipient })
      (ok true)
    )
  )
)

Note the (try! (is-dao-or-extension)) prevents users and market places from transferring these tokens - only another DAO extension is able to do this.

Note also that SFTs work differently from NFT/FT token contracts in the tag-nft method which looks like;

(define-private (tag-nft (nft-token-id { token-id: uint, owner: principal }))
  (begin
    (if (is-some (nft-get-owner? bigr-id nft-token-id))
      (try! (nft-burn? bigr-id nft-token-id (get owner nft-token-id)))
      true)
    (nft-mint? bigr-id nft-token-id (get owner nft-token-id))
  )
)

transferring an NFT is not as simple as transferring an FT/NFT because we cannot simply adjust the token levels - instead we use a mint and burn technique - burning the users full amount and then reminting the balance - why?

The reason for this requires an appreciation of a key feature that is unique to Stacks and Clarity. Post conditions. Post conditions are one of the most interesting and unique aspects of Stacks as they provide safety and security at the heart of the Stacks ethos. In the context of SFTs we need to put some thought in to making the process work to protect users - here’s how;

Semi-fungible token contracts can achieve complete post condition coverage by using both define-fungible-token and define-non-fungible-token.

this allows the token transfer events to be tracked by wallets to provide equivalent protections for end users as have been established for FT/NFT operations.

Why Soulbound?

Soulbound tokens can ONLY be earned through genuine contributions to the platform.

Reputation Rewards in BigMarket

In BigMarket we reward users with reputation via both on-chain and off-chain actions. On chain rewards come directly by interacting with the platform - e.g. users earn BIGR tokens simply by staking in a market or concluding a market vote (the full list is below). Off chain rewards are awarded via a DAO Proposal.

• Each token-id in the SFT contract represents a different type of contribution (e.g., resolving a market accurately, staking in a valid market, proposing disputes).

• When users perform valuable actions, the DAO mints SFTs to their wallet via a DAO-controlled function like sft_mint.

• These tokens accumulate over time, forming a reputation profile.

• Reputation (measured via SFT balances) can then be used to:

  • Access advanced features

  • Vote in governance

  • Qualify for rewards or roles in the DAO

This design decouples governance and influence from capital, anchoring it instead in trust, consistency, and contribution — the core ethos of BigMarket’s vision for a more fair and transparent predictive platform.

Tokenomics: Rewards and Prizes

In BigMarket DAO, the process for converting BIGR (reputation tokens) into BIG (governance tokens) is governed by a claim mechanism — a novel approach designed to align token distribution with utility and contribution rather than speculation or early access.

1. Earning BIGR

   • Users participate in meaningful actions (e.g., resolving markets, staking, governance) and are rewarded with soulbound BIGR tokens.

   • These SFTs cannot be transferred, only earned.

2. Claiming BIG Tokens

   • At defined intervals or through a DAO function, users can claim BIG tokens from a capped claim pool.

   • The claim amount is proportional to their BIGR balance relative to the total circulating BIGR supply.

   • Example:
     If Alice holds 10% of all BIGR, she can claim 10% of the unlocked BIG reward pool.

3. No Burn or Trade of BIGR

   • BIGR remains soulbound. Claiming does not burn BIGR; it acts as proof of merit.

   • This creates a sustainable feedback loop between activity and influence.

Innovation in Tokenomics

Traditional token launches often reward Whales who buy early and Users who speculate rather than contribute.

Our model flips this around. It creates a proof-of-contribution or "reputation mining" which isn’t a one-time airdrop or IDO. It’s a living mechanism that adjusts over time as the community grows and contributes.