Whitepaper
The Invariant Gravity Model
A decentralization primitive for Soroban tokens
HITZ applies a square-root invariant to every transfer. As total liquidity grows, individual holding limits rise — but always slower than the reserves themselves, permanently bounding concentration.
The Concentration Problem
Most fungible tokens have no mechanism to prevent a single address from accumulating an unbounded fraction of supply. Whales can silently dominate governance, markets, and liquidity without triggering any on-chain constraint.
Existing approaches — vesting schedules, transfer limits, blacklists — are either static, admin-dependent, or trivially circumvented. None of them self-adjust as the ecosystem grows.
HITZ solves this with a dynamic, self-adjusting holding limit rooted in the amount of real liquidity the protocol has attracted. The more value the ecosystem holds in trusted pools, the more any individual can hold. But the relationship is a square root — perpetually sub-linear.
The Gravity Model
Define S as the Total Mass — the sum of HITZ balances held across all admin-approved liquidity pools. S is an O(1) accumulator updated on every transfer in or out of a pool.
The Safety Limit L — displayed in the interface as the Event Horizon — is computed as:
where d= 7 (Stellar's standard decimal precision). Any account whose balance exceeds L is vaulted — outbound transfers are blocked until the account reduces its balance below L, or until the ecosystem grows enough that Lrises above the account's balance.
| Pool Reserves (S) | Event Horizon (L) | Max single holder |
|---|---|---|
| 100 HITZ | 10 HITZ | 10% |
| 10,000 HITZ | 100 HITZ | 1% |
| 1,000,000 HITZ | 1,000 HITZ | 0.1% |
| 100,000,000 HITZ | 10,000 HITZ | 0.01% |
Two-Tier Identity
Not all contract addresses are equal. HITZ distinguishes two classes of trusted infrastructure, each with distinct physics:
Pools
register_pool_address
- Affect Total Mass S
- Vaulted users can send to them
- Sacrifice to pool can release vault
- Never vaulted themselves
- Balance reconciled into S on registration
Routers
register_router_address
- Never affect Total Mass S
- Pass-through only (DEX aggregators)
- Vaulted users CANNOT send to them
- Never vaulted themselves
- No mass reconciliation needed
Both tiers are registered by the admin on a per-address basis. Earlier versions of HITZ used WASM hash detection — automatically treating any contract whose bytecode matched an approved hash as a pool. This was abandoned because DEX factories allow anyone to deploy a contract with any WASM hash, enabling laundering via fake pools. Strict address whitelisting is the only secure approach.
Transfer Physics
The Roach Motel (Silent Trap)
Incoming transfers neverrevert due to vault logic. If a recipient's new balance exceeds L, they are silently vaulted — but the transfer succeeds and returns a clean SEP-41 void. This is essential for DEX router compatibility: Aqua, Soroswap, and similar protocols depend on the output leg of a swap never throwing.
The Sender Gate
Outbound transfers enforce the vault constraint. A sender is blocked if all four conditions hold:
!is_pool(from)
&& !is_router(from)
&& is_vaulted(from)
&& !is_pool(to)
→ panic("Account is vaulted: transfers locked.")Pools and routers are always exempt as senders. Vaulted users can only send to an approved pool — not to a router, not to any other address. Sending to a pool (sacrifice) reduces the sender's balance and increases S, potentially releasing the vault if the new balance falls below the updated L.
Vault Release
An account is released when its balance ≤ L. This can happen three ways:
- Sacrifice tokens to a pool (instant, on-chain)
- The ecosystem grows: S increases, Lrises past the account's balance
- Anyone calls
check_release(address)to trigger a re-evaluation
On-Chain Implementation
HITZ is a Soroban smart contract on the Stellar network, fully implementing the SEP-41 token interface.
O(1) Accumulator
TotalMass is a stateful i128 updated on every pool transfer — no iteration required.
Checked Arithmetic
Every arithmetic operation uses checked_add / checked_sub / checked_neg to prevent overflow.
TTL Management
Balance and Vault keys are always extended together (~30 days) to prevent silent expiry.
Infallible Limit
current_limit_safe() returns i128::MAX on overflow so no address is spuriously vaulted.
SEP-41 Compliant
transfer, transfer_from, approve, allowance, burn, burn_from, name, symbol, decimals, balance.
Typed Events
PoolRegisteredEvent, RouterRegisteredEvent, TransferEvent, VaultedEvent, MintEvent, BurnEvent.
Security Properties
No WASM Hash Laundering
Pool status is tied to a specific address, not a bytecode fingerprint. A malicious actor cannot deploy a fake pool to inflate S.
No Burn Escape
Vaulted accounts cannot burn their tokens — burn is treated as an exit route and blocked.
No Router Escape
Vaulted accounts cannot route tokens through a DEX router. Only a direct sacrifice to an approved pool releases the vault.
No Silent Expiry
Vault flags and balance keys share TTL extension calls. An expired vault key would silently free a trapped whale; we prevent this by always extending both together.
No Mass Underflow
TotalMass is guarded against underflow. Pool removal subtracts the current balance; adjust_total_mass panics before going negative.
Deployed Contract
Stellar Testnet