Governance & Transparency Policy
How SWT governs humanitarian funds. This page is written as an engineering policy: statements should be verifiable via on-chain data, published docs, and the read-only /api/stats endpoint.
Scope: governance of humanitarian USDT, multisig policy, and verification references. This page does not market SWT — it defines how one narrow humanitarian flow should be structured and checked.
System facts
- Total supply: 1,000,000 SWT (fixed; no mint function).
- Upgradeability: no proxy; immutable contract.
- On-chain verification: Polygonscan verified source.
- Liquidity allocation: 500,000 SWT deployed across DEX pools.
- LP lock: LP NFT positions locked until 2027-01-01.
- Verification: locker contracts + /api/stats mirror.
Locks are designed to mitigate rug-pull style liquidity removal.
Governance model
All USDT produced by the humanitarian swap is governed by the humanitarian multisig. Today it is configured as 1/1 (Founder-only). This is the only centralisation point.
The address remains the same. Governance strengthens by adding signers, not by migrating funds.
Long-term governance is oriented toward reduced founder dependence.
Humanitarian execution should become increasingly shared, reviewable, and multisig-controlled rather than reliant on one ongoing actor.
The multisig is intended to become 2/2: Founder + a representative of a recognised humanitarian organisation. This preserves the same address and changes only the signer set.
- No single signer can move humanitarian funds.
- All transfers remain on-chain and traceable.
Partner intent (scope statement)
SWT intends to seek cooperation with recognised international humanitarian organisations (for example, UNICEF or similar entities).
This section is a governance intent statement, not a claim of active partnership.
Humanitarian flow
Live state can be verified via /api/stats and on-chain events.
Donation address vs rules-based token flow
- Useful for receiving and holding funds
- Depends on separate manual donation decisions
- Does not embed an accrual rule into system behaviour
- Operational stages are often blended together
- Transparency depends more heavily on reporting discipline
- Accrual is embedded in token behaviour
- Threshold condition is public and inspectable
- Trigger path is explicit and callable by any user
- Custody can be governed separately from collection
- Verification can rely on on-chain events, not only on statements
A donation address can collect funds, but it does not define how funds should accumulate, when a conversion path becomes active, who can trigger it, or how custody should be separated from collection. SWT is designed to make those stages explicit.
The goal is not to replace charity. The goal is to make one narrow charity-related flow more structured, more observable, and less dependent on narrative alone.
Transparency commitments
- Verified contract source on Polygonscan.
- Security & self-audit documents on GitHub.
- Read-only JSON endpoint: /api/stats.
- Humanitarian transfers should be accompanied by transaction hashes.
- Reports should be factual and verifiable (no “impact marketing” without proof).
- No guarantee of financial returns; SWT is not an investment product.
For threat model and known limitations, see Security.
Website analytics
This website uses first-party analytics to understand basic site usage, page flow, engagement, errors, and automated traffic patterns.
The analytics system may collect page views, referrer information, browser and viewport metadata, scroll depth, click events, session duration, timezone information, and lightweight interaction events. This data is used only to improve the website, detect automated traffic, and understand whether public project information is being reached and read.
Raw IP addresses are not stored in the analytics database. IP addresses may be processed by the server at request time and stored only as salted hashes for abuse detection and repeat-visit analysis. Analytics data is not sold, not used for advertising, and not shared with third-party ad networks.
Analytics records are intended to be retained for a limited period and may be deleted during maintenance or database resets.
Frequently asked questions
This FAQ covers custody, governance, and documentation standards. For general questions about supply, fee design, and chain choice, see the About page.