Tokenomics
Fixed-supply ERC-20 on Polygon. This page describes allocation buckets, the humanitarian fee flow,
liquidity constraints, and verifiable limits — without forecasts or marketing claims.
All parameters are enforced by immutable contract code and verifiable on-chain.
Data references will be wired to /api/stats. Until then, the page remains valid as a static specification.
Fee mechanics
SWT is not a donation shortcut.
It is a persistent on-chain mechanism where economic activity and humanitarian routing coexist under fixed rules.
Unlike a one-time transfer, the system can accumulate, operate, and remain publicly auditable over time.
Mechanical sequence enforced by contract rules. Funds remain on-chain and are independently verifiable.
Edge-case: if nobody calls the trigger function, the accumulated fee remains on-chain.
Constraints that define the fee behavior. No reflections, no extra taxes, no hidden charges.
- Fee accrues on contract — verifiable on-chain.
- Trigger batching reduces noise and micro-drain.
- Bounty incentivizes execution (when enabled).
Ongoing dilution
SWT has no airdrop emissions, no farming emissions, and no recurring reward schedule.
The only continuing dilution path is the trigger bounty used to activate humanitarian routing.
At current settings, this is operational in scale and designed to compensate execution rather than create a yield layer.
Bounty design
The trigger bounty exists to keep the mechanism executable in practice.
Its design direction is operational rather than extractive: covering execution effort, not creating meaningful ongoing inflation.
Supply & liquidity
Fixed supply with explicit allocation buckets. Values are intended to be verifiable via explorers and the public API.
| Purpose | Amount | Share |
|---|---|---|
| Liquidity | 500,000 | 50% |
| Reserve | 200,000 | 20% |
| Developer | 100,000 | 10% |
| Airdrop | 100,000 | 10% |
| Marketing | 50,000 | 5% |
| Owner | 50,000 | 5% |
Starting reference price: 0.01 USDT per SWT (initial pool ratio).
Liquidity is deployed across Uniswap V3 and QuickSwap pools using concentrated ranges, and locked via NFT-based lockers. The goal is predictable constraints: no silent liquidity removal and no “editable” pool behavior.
concentrated liquidity
We intentionally do not list every range here. The full set of LP positions is available in /api/stats. For user-facing “trade size” examples, the right place is How to buy.
Economic behaviour over time
This section is descriptive, not predictive. It summarizes mechanical effects implied by fixed supply, fee rules, and liquidity constraints.
If no one triggers execution, the accumulated fee remains on-chain and unchanged. The system does not “self-execute” off-chain.
Why transparency can retain attention and capital
SWT does not promise returns. Its economic logic is narrower: stable rules, visible constraints, and low narrative ambiguity may reduce some of the reasons participants usually leave early-stage tokens.
This is not a claim that capital will stay. It is a claim that SWT is built to be inspected, not reinterpreted every month.
Wallet structure
Wallets below represent explicit buckets used for liquidity operations and long-term constraints. Addresses are shown for verification; behavioral guarantees come from locks and contract rules.
Frequently asked questions
This FAQ is limited to supply and fee mechanics. For broader project context, governance rules, and security assumptions, see About, Policy, and Security.
Smart contract
Verify: immutable code, fixed supply, liquidity locks, and fee constraints. This page describes mechanics; verification is on-chain.