SourceMint: project overview

A fixed-supply ERC-20 on Base whose treasury accounting is enforced by continuous integration.

Version 1.0 · 5 September 2026 · Khalid Saidi · srcmnt.xyz

1. Summary

SourceMint (SRCMNT) is an open-source, fixed-supply ERC-20 token deployed on Base mainnet. One million tokens were minted once at deployment; no further minting is possible, and the contract has no owner, administrator, pause switch or transfer fee.

There was no ICO and no token sale. Supply enters circulation as rewards for merged contributions to the project's public repository. The distinguishing feature is not the token, which is deliberately ordinary, but the accounting around it: every transfer out of a project-controlled wallet must be recorded in a public ledger with a stated reason, and continuous integration re-verifies that ledger against the blockchain on every change and weekly. An unaccounted movement turns the repository's build red in public.

2. The problem

Token projects routinely make claims about their treasuries — that allocations are locked, that supply is reserved for a community, that nothing will be sold. These claims are published as prose on a website. The wallets are usually public, so the claims are checkable in principle, but almost nobody checks them in practice, and projects know this.

The gap is not cryptographic. It is that no one has connected the claim to the evidence in a way that fails loudly when the two diverge.

3. What SourceMint is

SourceMint is a small, deliberately unambitious experiment in closing that gap. It has two parts:

• A reference deployment. A complete, reproducible path from a Foundry project to a verified contract on Base mainnet — tests, gas snapshots, CI, deployment scripts and recorded deployment artifacts, all public.
• An enforced accounting discipline. A public ledger of every project-wallet movement, and a program that checks the ledger against the chain automatically.

The token is the unit that makes the second part meaningful: something has to move for the accounting to be about anything.

4. The contract

The implementation is OpenZeppelin's audited ERC-20 base plus the Burnable and Permit extensions. The constructor mints the entire supply to the deployer and grants no privileges; there is no Ownable, no upgrade proxy and no post-deployment authority of any kind. Supply can therefore only decrease, and only when a holder chooses to burn.

The project's own contract code is public and verified on-chain. It has not been subject to an independent third-party security audit.

5. Supply and distribution

All 1,000,000 SRCMNT were minted in the deployment transaction on 10 February 2026. There was no sale of any kind — no public sale, private sale, seed round or airdrop. Current allocation:

There is no vesting schedule, because there are no investors, founders' allocations or team tokens to vest — the entire supply sits in the two project wallets and the liquidity pool listed above. Every movement between them is recorded in the ledger described in the next section.

6. The accounting invariant

The project's central claim is narrow enough to be testable:

Every transfer of SRCMNT out of a project wallet is recorded in a public ledger, with a stated reason.

The ledger is rewards/ledger.json in the repository. Each entry records the transaction hash, sender, recipient, amount and — the part a blockchain cannot supply — the reason for the movement.

The verifier, script/verify_ledger.py, reads the token's complete transfer history from a public indexer and compares it to the ledger in both directions: an on-chain movement out of a project wallet with no ledger entry is a failure, and a ledger entry with no on-chain counterpart is equally a failure. Transfers between third parties are outside project accounting and are ignored.

A GitHub Actions workflow runs the verifier on every push, on every pull request, and weekly on a schedule. The weekly run matters most: the claim is re-tested even when no one is committing code. The verifier distinguishes an accounting violation (build fails) from an unreachable data source (build warns), so an indexer outage is never reported as a discrepancy. Because each run re-checks the entire transfer history rather than a delta, a deferred check loses nothing.

Anyone can run the same check independently: python3 script/verify_ledger.py against a clone of the repository. It reads public chain data and produces the same answer for a stranger as it does for CI.

7. How rewards work

Rewards are paid for merged contributions to the repository — code, documentation, test coverage, tooling improvements, or reproducible bug reports with fixes — at the maintainer's discretion, under a published policy.

A contributor opens a pull request and includes a Base address if they wish to be rewarded. If the work is merged and a reward is assigned, payment is sent from the rewards wallet and the transaction is added to the ledger with the pull request as its stated reason. Reward sizes are set per contribution; there is no fixed price list. Spam, cosmetic churn and contributions made solely to farm rewards are not rewarded.

SRCMNT has no established market value. Rewards are recognition within the project, not payment for work and not an investment.

8. Liquidity

On 28 August 2026 the treasury seeded a public ETH/SRCMNT pool on Aerodrome (basic volatile, 0.3%) with 10,000 SRCMNT and 0.012 ETH, so that a reward can be exchanged rather than being purely symbolic. That deposit is recorded in the ledger like any other project-wallet movement, and the LP position was held by the treasury wallet until 15 September 2026, when 100% of the LP tokens were burned to 0x000000000000000000000000000000000000dEaD (transaction). The liquidity is therefore permanently locked: it can be traded against but never withdrawn, by the project or anyone else.

The pool is permissionless: anyone may trade against it or add liquidity. Its price is set by the market, not by the project. The pool is small, and the project makes no commitment to maintain, deepen or withdraw it beyond recording whatever it does in the ledger.

9. Governance and control

There is no on-chain governance, no DAO and no voting token. The contract grants no one any authority over it — including its author — because it has no privileged functions at all.

What remains discretionary is off-chain: which contributions are rewarded, and what the treasury does with the tokens it holds. That discretion belongs to the maintainer, and the accounting invariant is what constrains it: any exercise of it is visible, reasoned and machine-checked. Reward decisions and treasury activity are discussed in the open on GitHub.

10. Roadmap

11. Risks and limitations

Stated plainly, because a document that lists only strengths is not informative:

• The invariant proves accounting, not honesty. The "reason" field is free text. It proves that every project-wallet movement is disclosed and reasoned, not that the reason given is truthful.
• It covers only declared wallets. Like any self-reported scheme, it cannot cover a wallet nobody declared.
• Concentrated supply. 89% of supply sits in a single treasury wallet controlled by one person. Movements are constrained by disclosure, not by code.
• Single maintainer. This is a one-person project. It carries the continuity risk that implies.
• Thin liquidity. The pool is small, so the market price is easily moved and may not reflect anything meaningful.
• No third-party audit. The contract uses audited OpenZeppelin components but has not itself been audited.
• No guarantee of value. SRCMNT is not offered as an investment, carries no claim on anything, and nothing in this document is financial advice.

12. References

• Website: srcmnt.xyz
• Repository: github.com/khalidsaidi/sourcemint
• Reward policy: REWARDS.md
• Public ledger: rewards/ledger.json
• Method write-up: Make the build fail when the treasury moves
• Contract on BaseScan: verified source
• Maintainer: Khalid Saidi — LinkedIn · GitHub · khalidsaidi.com
• X: @srcmnt
• Contact: contact@srcmnt.xyz