Technical Architecture & Specification

Compressed Soulbound Tokens (cSBT) for Event Attendance

The architecture and implementation of state-compressed credentials for verified event attendance, alongside ONTON's native credential engine.

Part 1: The Concept, Technology, and History of cSBT

1. Soulbound Tokens in General Terms

A Soulbound Token (SBT) is a non-transferable digital token permanently bound to a single cryptographic wallet address. Standard non-fungible tokens (NFTs) are designed for financial exchange and secondary trade on marketplaces like OpenSea or Getgems. An SBT strips out the transfer mechanism entirely. Once a wallet receives an SBT, the token cannot be sold, transferred to another wallet, or pledged as loan collateral.

This constraint makes SBTs useful for credentials that must reflect individual history rather than purchasing power: event attendance records, hackathon achievement badges, professional certifications, DAO voting rights, and verified community memberships.

2. The Cost Bottleneck of On-Chain Storage

On blockchains like Ethereum and TON, data storage is expensive because every validator node must store the blockchain state indefinitely.

On the TON blockchain, the architecture follows an actor model. Every standard NFT collection and every individual NFT item is an independent smart contract with its own address, code cell, data cell, and storage rent balance. Minting 10,000 standard TEP-85 Soulbound Tokens for an event requires deploying 10,000 distinct smart contracts. At roughly 0.05 to 0.08 TON per deployed contract, minting 10,000 attendee badges costs between 500 and 800 TON (equivalent to $2,500 to $4,000 at $5/TON). For large conferences, free community meetups, or repeated side events, this cost structure makes mass credentialing economically impractical.

3. How State Compression Works

State compression solves the storage cost problem by moving individual token records off-chain while keeping mathematical proof of their validity on-chain.

The mechanism relies on a binary Merkle tree:

  • Leaves: Each credential record contains the recipient wallet address, token index, event identifier, and metadata hash. This data is hashed into a 32-byte cryptographic leaf: hash = SHA256(index + owner + event_uuid + metadata_hash).
  • Nodes and Root: Pairs of leaf hashes are combined and hashed up the tree until a single 32-byte value remains: the Merkle root.
  • On-Chain Anchor Contract: The event organizer deploys a single contract on TON that stores only the 32-byte Merkle root. A tree of depth 20 can reference up to 1,048,576 individual badges, yet the on-chain contract stores only 32 bytes of state.
  • Cryptographic Inclusion Proofs: To verify that a specific wallet owns a badge, the verifier does not read an individual smart contract. Instead, the user provides a Merkle proof: the path of 20 sibling hashes connecting their leaf to the on-chain root. Any contract or client can recompute the root from this proof in milliseconds. If the computed root matches the on-chain root, the credential is mathematically proven without the blockchain ever storing the badge data.

Standard TEP-85 vs. Compressed SBT (cSBT)

ParameterStandard TEP-85 SBTCompressed SBT (cSBT)
On-Chain Footprint (10k items)10,001 smart contracts1 anchor contract (32-byte root)
Minting Cost (10k items)~500 - 800 TON~0.1 - 0.5 TON
Storage RentPaid per item contractSingle root contract rent
Verification MechanismContract getter methodMerkle inclusion proof
TransferabilityRejects transfers (error 413)Immutable leaf bound to address

Part 2: What We Built for ONTON and What We Are Replacing

By implementing native state compression and cryptographic proofs on our own TEP-85 and cSBT engines, ONTON provides verifiable, low-cost attendance credentials that attendees own and carry across platforms.