ASSET LAYER

Totem Exchange

Shamwari's native digital asset infrastructure — issue, regulate, trade, and distribute dividends on any financial instrument at the consensus layer. No ERC-20. No smart contract risk. Regulatory approval enforced by the blockchain itself.

3 ASSET TYPESTOTEMAPPROVALON-CHAIN DIVIDENDSTAX WITHHOLDINGNO SMART CONTRACTS
3
Totem asset types: Non-Fungible / Non-Splittable / Splittable
6
Regulatory approval states in TotemApproval lifecycle
$3.8B+
Lost to Ethereum smart contract exploits since 2020
0
Smart contracts required
01
ASSET ARCHITECTURE
Three asset types. One protocol.

The TotemType bitmask encodes all asset properties in a single field. Mutual exclusivity is enforced by the protocol — not developer discipline. Each type imposes specific issuance rules and capabilities that cannot be changed after issuance.

NON_FUNGIBLE (0x01)
Unique, non-divisible assets. Quantity forced to 1, decimals forced to 0. Represents deeds, licences, identity tokens, or collectibles. Cannot be split, combined, or have supply altered after issuance. Protocol rejects any supply-increase transaction for NON_FUNGIBLE totems.
NON_SPLITTABLE (0x02)
Fixed-supply fungible assets. Initial quantity must equal maximum quantity — no further issuance allowed after creation. Ideal for corporate shares with fixed capital structures, fixed-supply bonds, or membership units where dilution is structurally prohibited.
SPLITTABLE (0x04)
Growth-capable assets. Issuer can increase supply up to a preset maximum quantity via TOTEM_SUPPLY_INCREASE transactions. New units are distributed proportionally to existing holders. Suited for equity with future capital raises or revenue-sharing tokens.

Type Bitmask Enforcement

The TotemType is encoded as a bitmask in the TOTEM_ISSUANCE attachment. The consensus engine reads this bitmask at every subsequent transaction and enforces the type-specific rules. There is no application code path that bypasses these rules — they are evaluated at attachment validation (gate 5) before any state change.

  • NON_FUNGIBLE: rejects all TOTEM_SUPPLY_INCREASE attempts
  • NON_SPLITTABLE: rejects all supply changes after genesis issuance
  • SPLITTABLE: permits supply increases up to maxQuantity only
  • All types: require TotemApproval APPROVED status for transfers

Why No ERC-20?

ERC-20 and similar standards rely on smart contract code to define token behaviour. Every deployment is a new codebase, a new attack surface, and a new audit requirement. Shamwari Totems have their behaviour defined at the protocol layer — audited once, enforced everywhere, with $0 smart contract exploit risk.

  • No re-entrancy: no external contract calls during token operations
  • No upgrade proxies: type is immutable after issuance
  • No approval/allowance bugs: protocol handles custody directly
  • No infinite mint: supply cap enforced at consensus
02
TOTEMAPPROVAL LIFECYCLE
Regulatory compliance at consensus

Every Totem asset passes through a regulator-controlled approval workflow enforced by the blockchain. Each jurisdiction chain has designated Securities Regulator accounts that control asset validity. The 6-state lifecycle creates an immutable compliance record for every asset.

PENDING
Issuer submits TOTEM_ISSUANCE. On-chain but not tradeable.
UNDER_REVIEW
Regulator actively reviewing documentation.
APPROVED
Listed and tradeable. May have expirationHeight.
SUSPENDED
All transfers rejected. Reversible by regulator.
COMPLIANCE_HOLD
Investigation mode. Frozen without permanent revocation.
REJECTED
Permanent denial. Cannot list on this chain.

  Each transition requires a signed transaction from the Securities Regulator authority account — immutable, court-admissible, verifiable by any node.

Protocol-Enforced Approval

Only the Securities Regulator account (hardcoded at genesis) can execute TotemApproval transitions. No application-layer operator and no other participant can change approval status, regardless of what front-end software they use.

Expiring Approvals

APPROVED status can carry an expirationHeight. AFTER_BLOCK_APPLY automatically transitions to PENDING when this height is reached, forcing periodic re-approval without manual regulator action.

TotemHistory Provenance

Every supply change, transfer, dividend, and approval event is recorded in the immutable TotemHistory table. Complete provenance for every unit of every asset from issuance to present holder.

03
ORDER BOOK DEX
Price-time priority, no front-running

The Shamwari DEX implements a full price-time priority order book at the consensus layer. Orders are matched deterministically — best price first, then submission order within the same block. Front-running is structurally impossible: order inclusion in a block is atomic and non-modifiable.

Price-Time Priority Matching
Orders are matched by best price first, then by time of submission (block height). Within the same block, all orders at the same price are considered simultaneous — no intra-block ordering manipulation. This is the same matching algorithm used by institutional trading venues.
Capital Gains Tax at Execution
When a trade executes, capital gains tax is automatically calculated on the profit portion and withheld in the same atomic operation. The net proceeds after CGT reach the seller. Zero off-chain reporting required. Tax rate set by the Tax Collector authority account.
PLACE_ASK_ORDER / PLACE_BID_ORDER
Limit orders are placed on-chain and remain in the order book until filled, cancelled, or expired. No partial fills at worse prices than specified. The order book state is part of the blockchain state — queryable by any participant at any block height.
CANCEL_ASK_ORDER / CANCEL_BID_ORDER
Outstanding orders can be cancelled at any time via consensus transaction. Cancellation is final at the next block. No partial fills after cancellation. Unfilled orders do not expire automatically — they remain valid until explicitly cancelled.
EXAMPLE ORDER BOOK (TOTEM/ZWG)
PRICE (ZWG)QUANTITYTOTAL
142.508,5001,211,250
142.2012,0001,706,400
142.005,200738,400
141.80 — Mid Price
141.609,8001,387,680
141.4015,5002,191,700
141.207,3001,030,760
04
DIVIDENDS & GOVERNANCE
On-chain distributions with automatic tax withholding

Totem snapshot dividends capture holder balances at a specific block height and distribute proportionally in a single DIVIDEND_PAYMENT transaction. Dividend withholding tax is applied automatically at distribution. Zero off-chain calculation, zero manual withholding.

Snapshot Distribution
DIVIDEND_PAYMENT transaction specifies a snapshot block height. The protocol calculates each holder's proportional entitlement from the TotemHistory snapshot at that height — distributing in a single atomic operation. One transaction pays all holders.
Dividend Withholding Tax
Dividend withholding tax (0–3500 bps) is deducted before distribution reaches holders. The Tax Collector account is credited in the same transaction. No holder self-reporting, no remittance process — withholding is structural and atomic.
SPLITTABLE Supply Growth
Issuers of SPLITTABLE assets can increase supply up to the preset maximum via TOTEM_SUPPLY_INCREASE. New units are distributed proportionally to existing holders using the same snapshot mechanism — transparent, on-chain, and immutable.
TotemControl Multi-Party Governance
Multi-party phasing controls allow issuers to require approval from multiple signatories before any supply change, dividend, or governance action executes. Corporate-grade governance enforced at consensus — no multi-sig smart contract required.

Dividend Distribution Flow

  • Step 1: Issuer submits TOTEM_SNAPSHOT transaction at desired record date block height
  • Step 2: Protocol captures all holder balances at that height in the TotemSnapshot table
  • Step 3: Issuer submits DIVIDEND_PAYMENT specifying per-unit payment amount and currency
  • Step 4: Protocol calculates entitlements, deducts withholding tax, credits all holders and Tax Collector in one atomic block
  • Step 5: Immutable CurrencyTaxRecord created for the withholding event; dividend records created per holder

Comparison: Totem vs ERC-20 Dividends

  • Totem: Protocol-native snapshot — no custom contract, no off-chain calculation
  • ERC-20: Custom dividend contract required; each implementation is a new audit surface
  • Totem: Tax withheld atomically at distribution — built-in compliance
  • ERC-20: No tax infrastructure; off-chain reporting obligation falls on operator
  • Totem: TotemHistory provides immutable provenance for every distribution
05
COMPLIANCE ADVANTAGES
Protocol native vs smart contract infrastructure

The fundamental security advantage of Shamwari Totems over ERC-20 and similar standards is not just the regulatory approval workflow — it is the complete elimination of smart contract attack surface for digital asset operations.

SHAMWARI TOTEMS
  • Regulatory approval enforced at protocol — no smart contract to exploit
  • Dividend distribution built-in — no custom dividend contract required
  • Tax withholding automatic — zero off-chain reporting
  • TotemHistory provides complete immutable provenance from genesis
  • 3 distinct asset types in type bitmask — not developer-defined logic
  • Capital gains tax at execution — not deferred to off-chain calculation
  • Multi-party governance via phasing — no multi-sig contract
  • Single audit: the Shamwari protocol codebase
ERC-20 / SMART CONTRACT TOKENS
  • No regulatory approval primitive — compliance is application-layer only
  • $3.8B+ lost to smart contract exploits — each contract is a new attack surface
  • Dividend distribution requires custom contract — new audit per deployment
  • No tax infrastructure — off-chain reporting relies on operator integrity
  • Token behaviour defined by developer code — unlimited variability and risk
  • Capital gains tracking entirely off-chain — evasion structurally possible
  • Multi-sig requires additional contract layer — composable risk
  • Unlimited audit surface: every new contract deployment
ISSUE DIGITAL ASSETS

Regulated digital assets. Protocol-native compliance.

Issue and trade Totem assets with built-in regulatory approval, dividend distribution, and capital gains tax — from a single TOTEM_ISSUANCE transaction.