SWT
SWT
Current price —
Accumulated fee —

Security model

This page is a public, engineering-style summary of SWT security decisions: what is enforced by immutable code, what is constrained by locks, and what risks still exist. It is not a formal third-party audit.

Network Polygon
Contract -
LP lock (until UTC) -
Last update (UTC) -
Threat model Self-audit Whitepaper (PDF)

Security claims should be backed by evidence: contract source, on-chain locks, and verifiable on-chain activity.

Threat model

What we defend against (and what we don’t)

A concise threat model: common token failure modes and SWT mitigations.
Some risks are systemic (DEX liquidity, MEV, user mistakes) and cannot be fully eliminated.

Rug pull (liquidity removal)
Mitigated

LP positions are locked using locker contracts (NFT-based positions).

Notes
Time-locked LP NFTs (Uniswap V3 + QuickSwap), verifiable on-chain and via /api/stats.
Supply inflation (mint)
Impossible

There is no mint function and no upgradeable proxy.

Notes
Total supply fixed at 1,000,000 SWT; verified source on Polygonscan.
Fee increase
Impossible

The fee is fixed by immutable contract rules and cannot be increased.

Notes
Fee cap is 0.1%; reduction allowed only down to 0.05%.
Admin drain
Limited

No privileged function can withdraw user SWT. Charity admin can only release USDT already swapped and held on-contract.

Notes
Limited to USDT balance held by the token contract after the trigger swap. All actions are on-chain and traceable via events.
Price manipulation
Possible

Like any DEX asset, SWT price can be moved in low-liquidity conditions.

Notes
Locked liquidity reduces “sudden removal” risk, but does not prevent manipulation in thin pools. Use small trade sizes and verify pool depth.

Threat model is intentionally explicit: it reduces vague “security marketing” and makes assumptions reviewable.

Security assumptions

System boundaries

Some safety properties depend on user behaviour and external infrastructure. These assumptions define the boundaries of SWT security guarantees.

  • Users verify the official contract address before interacting
  • DEX trading risks (price impact, MEV, liquidity) are inherent to on-chain markets
  • Wallet and private key security remains the user's responsibility
  • Smart contract risk can be reduced but never fully eliminated

These assumptions are standard for public blockchain systems.

What is enforced (guarantees)

Immutable contract properties

SWT is intended to behave as infrastructure: fixed parameters and no hidden admin levers.

  • No proxy / no upgradeability
  • No mint function (fixed supply)
  • Fee cap cannot increase
  • No privileged “drain user funds” function
Operational constraints

Constraints that reduce common trust failures: liquidity removal and early-wallet surprises.

  • LP NFTs locked until 2027-01-01
  • Owner & reserve wallets time-locked until 2027-01-01
  • Some operational wallets have enforced transfer limits
  • Lock status is verifiable on-chain and in /api/stats

Known risks & limitations

DEX / market risks

These are not “bugs”. They are normal market properties of on-chain trading.

  • Low liquidity can amplify price impact
  • Primary/secondary pools may diverge temporarily
  • MEV / sandwiching is possible on public mempools

Mitigation: trade small, verify pool depth, avoid rushing large market orders.

User-side risks

The most common losses are operational: wrong network, fake tokens, wrong approvals.

  • Wrong token address / phishing links
  • Wrong network (non-Polygon)
  • Over-approving allowances to unknown contracts

See How to buy for a safety checklist.

Transparency log

A minimal list of verifiable security facts and disclosures..

EventProof
LP positions locked LP locker contract
Public self-audit & security disclosure AUDIT-SELF.md
LP NFT lockers security note LP-LOCKERS-SECURITY.md

Frequently asked questions

Is SWT upgradeable?
No upgradeable proxy architecture is assumed in this design. The page is written around the deployed contract as a fixed on-chain system, which reduces governance ambiguity and narrows the surface for hidden logic changes after launch.
Can the team change the fee?
No. The fee is described as a fixed rule enforced by contract logic. From a security perspective, that matters because it removes one common admin-risk vector: post-deployment tax changes.
What is the main remaining risk?
The main remaining risks are not hidden minting or silent fee edits, but ordinary operational and ecosystem risks: wallet security, admin key handling for permitted roles, interface mistakes, pool behavior, and user interaction with external infrastructure. Immutable code reduces one class of risk; it does not eliminate all risk.

This FAQ focuses on upgradeability, fee immutability, and residual risk. For general project design and governance structure, see About and Policy.

References & verification

Public documents

Primary sources for verification and review.

Self-audit AUDIT-SELF.md
LP lockers note LP-LOCKERS-SECURITY.md
Transparency API spec docs/STATS_API.md
Disclosure policy SECURITY.md
Whitepaper STOPWARTOKEN_Whitepaper.pdf

SWT is built for humanitarian transparency — not investment speculation. If you see an issue, use the disclosure process in SECURITY.md.