About SWT

STOPWARTOKEN is a fixed-supply ERC-20 on Polygon designed as public on-chain infrastructure: verifiable rules, locked liquidity, and an automated humanitarian fee mechanism.

Network Polygon

Contract -

Live price (USD) -

Last update (UTC) -

Tokenomics Security model Governance policy

What SWT is

A rules-based token

SWT is deployed with fixed parameters and is intended to remain stable as infrastructure: no changing supply, no hidden admin levers, no “growth hacks”.

A transparent mechanism

On-chain activity can be verified independently. The project also publishes a read-only stats endpoint that aggregates verifiable on-chain data for convenience.

Stats endpoint /api/stats

Last update -

SWT is designed as infrastructure, not as a promise of profit.

Design principles

No private sales

No VC rounds, no preferential allocations, no hidden early access.

No mint

Supply is fixed. The contract is intended to remain immutable.

Liquidity locked

Liquidity positions are locked using locker contracts. This is intended to reduce rug-pull risk.

Charity on-chain

A small humanitarian fee accumulates on-chain and can be triggered by anyone under defined conditions.

Public stats endpoint

A read-only JSON endpoint mirrors key verifiable on-chain metrics for explorers and researchers.

Evidence over marketing

Claims should be backed by on-chain data, contract source, and explicit limitations.

Why SWT exists as a token

SWT is not structured as a donation wrapper. It exists as a public on-chain system with visible rules, visible constraints, and a visible humanitarian path. A donation address can receive funds, but it does not create a shared mechanism that others can inspect over time. SWT does.

Observing a system explains how it works. Participating shows that it can exist.

A public system

A donation address is mainly a receiving endpoint. SWT is broader: fixed supply, liquidity structure, fee routing, trigger conditions, and public market references all exist as part of one observable system.

Embedded humanitarian logic

A normal donation wallet depends on separate manual transfers. SWT embeds a small humanitarian path directly into token behaviour, making accumulation and trigger conditions visible on-chain instead of relying only on reporting.

Attention through inspectability

SWT does not try to hold attention through promises. It tries to hold attention through legibility: locked liquidity, fixed rules, public stats, and verifiable evolution over time.

The goal is not to replace charity with speculation. The goal is to make one narrow humanitarian mechanism more structured, more observable, and less dependent on narrative alone.

What SWT is not

SWT is intentionally minimal. If you are looking for complex incentives or governance, this is not it.

Not a yield farm
Not a governance token
Not a DAO
Not VC-backed
Not a promise of profit

If you want a “community with announcements”, SWT is probably not for you. If you want verifiable rules, visible constraints, and a system that can be inspected instead of constantly reinterpreted — it might be relevant.

Who SWT is for

SWT may fit you if

You prefer fixed, verifiable rules over narratives
You value liquidity lock constraints
You want transparent on-chain charity mechanics
You are comfortable verifying data via explorers and APIs

SWT is likely not for you if

You expect high-yield programs or emissions
You want governance voting and proposals
You want aggressive marketing and rapid “growth” cycles
You want a product that can change rules frequently

Transparency log

Key verifiable facts about the SWT contract and its initial deployment.

Event	Proof
Deployment transaction	TX ↗
Contract verification	Verified source
Initial liquidity created	Uniswap pool

Frequently asked questions

Who controls the contract?

SWT is governed by immutable on-chain contract code. Core token rules are enforced by the deployed contract itself, not by an upgradeable admin layer. Operational roles may exist for specific functions such as humanitarian fund handling, but token parameters are not controlled through a hidden backdoor.

Can the team change the fee?

No. The humanitarian fee is defined in contract logic and presented as a fixed parameter of the deployed system. This page describes the live design as a verifiable specification, not as a promise that depends on future team discretion.

Why Polygon?

Polygon allows public on-chain verification with relatively low transaction costs and broad wallet and explorer support. For SWT, that makes transparency features more practical: transfers, liquidity state, fee collection, and related contract activity can be inspected without requiring a high-cost chain environment.

Why fixed supply?

Fixed supply removes minting uncertainty from the system. It gives observers a stable base for verifying allocation, liquidity, and circulating behavior over time. The goal is narrower scope and clearer auditability, not monetary experimentation.

Why 0.1%?

The 0.1% rate is intentionally small. It keeps the humanitarian mechanism present on every transaction while avoiding a large transfer-tax model. The design goal is traceable infrastructure with low friction, not aggressive fee extraction.

This FAQ covers general SWT design choices. For fee mechanics, governance, and operational risk, see the dedicated Tokenomics, Policy, and Security pages.