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

4. History in Web3 and on the TON Blockchain

May 2022: The Conceptual Foundation
Vitalik Buterin, Glen Weyl, and Puja Ohlhaver published "Decentralized Society: Finding Web3's Soul". The paper argued that Web3 was overly financialized and lacked native primitives to represent trust, creditworthiness, affiliations, and provenance. They proposed Soulbound Tokens as non-transferable, identity-anchored credentials.

Late 2022 – Early 2023: Solana Pioneers State Compression
Solana Labs and Metaplex introduced concurrent Merkle trees through the SPL Account Compression program and the Bubblegum standard. This cut the cost of minting 1,000,000 NFTs on Solana from roughly $250,000 down to $100 (approximately 5 SOL). This deployment proved that Merkle compression was the only viable path for mass token issuance.

2022 – 2023: TON Establishes TEP-85
The TON Community approved the TEP-85 standard ("Soulbound NFT Standard"). TEP-85 extended the basic TEP-62 NFT standard by removing transfer operations and adding interfaces for proving ownership (proveOwnership, opcode 0x04ded148), requesting owner info (requestOwner, opcode 0xd0c3bfea), and handling revocation by designated authorities (revoke, opcode 0x6f89f5e3). Attempted transfers return exit code 413.

2023 – 2024: Legacy Web3 Credentialing and the API Bottleneck
Early community credentialing bodies on TON issued badges for hackathons, regional hubs, and ecosystem activities, introducing early cSBT campaigns for event organizers.

However, legacy systems operated through centralized, hosted backend APIs. Event organizers and platforms could not interact directly with an on-chain protocol; they had to authenticate through API keys, submit payloads to centralized servers, and rely on external providers to sign and batch transactions.

When external API providers shut down, the endpoints stopped resolving (NXDOMAIN). External applications that depended on their API experienced immediate outages: event creation transactions rolled back, ticket check-in workflows stalled, and attendee reward queues jammed.


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

1. The Problem We Addressed

ONTON originally integrated with external hosted APIs for event activity registration, badge creation, and attendee rewards. When those legacy endpoints went offline, background workers threw uncaught connection exceptions during ticket order completion and post-event reward processing.

This operational failure confirmed that core event operations cannot depend on third-party SaaS backends. We resolved to eliminate external dependencies and implement our own credential system directly on the TON blockchain.

2. Phase 1: Native In-House TEP-85 Engine (Shipped & Live)

We developed and deployed a native TEP-85 Soulbound Token engine directly within ONTON. This system is fully independent of any external service:

  • FunC Smart Contract Wrappers: In mini-app/src/lib/sbt.ts and sbtOpcodes.ts, we implemented full TEP-85 compliance. The system handles collection deployment, badge minting messages with custom authority addresses, revocation, and ownership verification.
  • Deterministic Address Derivation: The TypeScript implementation uses TON cell hashing to derive the exact contract address of every badge before it is deployed on-chain. When an attendee buys or claims a ticket, ONTON can display their badge contract address immediately.
  • Self-Healing Database Architecture: The PostgreSQL module (sbt.db.ts) manages sbt_collections and sbt_items tables with automatic, idempotent schema creation (ensureSbtTables()). If migrations are missing during container startup, the database creates the necessary schemas and indexes on the first query without throwing 500 errors.
  • Worker Pipeline Decoupling: We removed all defunct external API calls inside ONTON's ticket processing and reward workers (TsCsbtTicketOrder.ts, createRewards.helpers.ts, rewardsService.ts). Badges are minted directly through ONTON's dedicated minter wallet to the recipient's TON address.
  • tRPC API Integration: We exposed sbt.getEventCollection, sbt.getWalletBadges, and sbt.verifyOwnership endpoints directly in the API router for use by the Telegram Mini App and third-party verifiers.

3. Phase 2: The ONTON cSBT State Compression Engine (Next Generation)

Our native TEP-85 engine solved autonomy and eliminated external failure points. However, deploying individual contracts for each attendee still costs approximately 0.08 TON per mint.

To scale to hundreds of thousands of attendees across conferences, hacker houses, and meetups, we are expanding our native architecture into a full Merkle state compression engine (cSBT):

  1. The On-Chain Anchor Contract: Instead of deploying a new contract for every badge, each event collection deploys a single Merkle anchor contract on TON. The contract holds the current 32-byte Merkle root and accepts batch root updates signed by the authorized organizer or ONTON minter wallet.
  2. Indexed Leaf Storage: All badge leaves are computed and indexed in ONTON's PostgreSQL cluster. When an organizer finishes check-in for a 5,000-person summit, the leaf hashes are combined into a Merkle tree, and a single root transaction is committed to the blockchain.
  3. Zero-Gas Claim Flow via Telegram Mini App: Attendees do not need crypto or a wallet to receive credentials. When their QR code is scanned at the door, their credential is recorded immediately. Inside the Telegram Mini App, their profile displays their verified badge.
  4. Cryptographic Verification API: Any third party (a partner event, a DAO voting portal, or a gated chat) can verify an attendee's badge by requesting a Merkle proof from ONTON's public API and checking it against the on-chain root stored on the TON blockchain.
  5. On-Demand Materialization: If an attendee requires a standalone on-chain TEP-85 contract (for instance, to interact with an external contract that does not support Merkle proof verification), they can trigger an on-chain extraction. The user submits their Merkle proof to the anchor contract, pays the isolated deployment fee, and the anchor contract deploys an individual TEP-85 token instance while marking the leaf as materialized.

Summary

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.