Footprint and measurement
Declaring the on-chain identifiers this project owns, resolving them on chain, measuring the activity they account for, and proving no reward or fee sponsoring code exists.
Three commands make the product's on-chain presence checkable by anyone: footprint, measure
and integrity.
The declared footprint
footprint.<network>.json names, per network, everything that identifies this product on chain.
cardano-swap footprint build --network preprod| Section | What it holds |
|---|---|
scripts | Every script this project deployed, with its hash, address, deployment transaction and reference script. |
assets | The asset policies the product moves, with fingerprints and whether each is a verified stablecoin. |
messageTag | The CIP-20 label and project name every transaction carries. |
ownWallets | The project's own wallets, by purpose, address and stake key. |
routedVenues | Third party contracts the product routes across, recorded for transparency. |
Two rules shape it, and both are enforced in code rather than described.
A declared identifier must be newly deployed for this work. Anything that carried traffic before is not eligible, so the generator records each script's deployment transaction and the checker proves the script's first appearance on chain is that transaction.
The project's own wallets never count as usage. They are declared so they can be excluded, which only works if the declaration is complete.
Venue scripts are deliberately not declared as this project's own. They are third party contracts the product routes across, not identifiers it owns, and every trader on those venues spends them.
When no script of this project is deployed on a network, the command says so rather than writing an empty entry that would read as a value.
Checking it resolves
cardano-swap footprint check --network preprodPrints one line per entry, ok or FAIL, with the detail, then a count. Exits 1 when any entry
fails to resolve.
Measuring what the footprint accounts for
cardano-swap measure --network preprodTwo questions are answered, both from public chain data alone.
How much activity does the declared footprint account for?
The report prints, for the transactions carrying the declared tag:
- The scan sources, each with its credential, how many transactions were seen, and whether its window saturated.
- Distinct candidates, and how many of them carry the tag.
- Total fees, split into fees paid by external wallets, by own wallets, on mixed payer sets, and with no wallet input at all.
- Distinct external stake keys, external payers without a stake key, and transactions with more than one payer.
- A per day distribution of transactions and fees.
- A per wallet concentration table, with the largest single wallet's share and the largest external wallet's share.
Wallets are identified by stake key, never by payment address. One stake key signs from many payment addresses, so counting addresses would report one wallet as several and inflate every distinctness figure in the report.
Did any declared script carry traffic before deployment?
The earliest transaction that ever referenced each declared script must be its own deployment transaction, or later. This is checked against the chain, per script, and where the check fails the earlier transactions are listed as evidence.
Routed venue scripts are printed separately with the reason they are excluded from this rule.
What the report says it cannot see
Both limits are printed in the report rather than left implicit.
No provider answers "every transaction on chain carrying metadata label N." The scan therefore starts from the credentials the footprint declares: the project's own scripts and wallets in full, and a bounded newest-first window over each routed venue, which carries third party traffic in volumes that cannot be read end to end. A tagged transaction that touched none of those credentials is outside the scan, and the report says so along with the window it used and whether that window saturated.
The ledger records one fee per transaction and does not say which input paid it. Attribution is therefore per transaction: external when every paying wallet is outside the declared own set, own when every one is inside, and mixed when both appear. A mixed fee is reported as its own figure and never split by a guess.
Where a figure has no meaning, the report prints not computable and the reason rather than a
zero that would read like a measurement.
Proving what the product does not do
cardano-swap integrityTwo rules the product is built under, proved by inspecting the code rather than by asserting them.
Nobody is paid, rewarded or rebated to transact
No per-transaction reward, no points redeemable for value, no referral payout, no market maker compensation.
The wallet that signs is the wallet that pays
No fee sponsoring from any project wallet, enforced by not building the capability.
The scanner walks every .ts, .tsx, .js, .mjs, .cjs and .ak file outside build output
and dependencies, and tests six pattern groups: per-transaction reward, rebate, points or
transact-to-earn, referral payout, fee sponsoring, and market maker compensation.
It strips comments and string literals before testing, because a rule cannot be written down
without naming what it forbids. payRebate(user) is a finding; the sentence "no rebate is ever
paid" is not.
The report prints the number of files scanned, the number of mentions inside comments, which is the rule being stated rather than broken, and the number of violations in code. It reports every match it finds rather than only a verdict, so a reader can judge the evidence instead of trusting a boolean. It exits 1 when any violation is found.
Why the counts differ from audit
measure counts every kind of product transaction. audit counts only Kernel class swaps,
because those are the ones a swap can be rebuilt from.
The two are reconciled in detail, reason by reason, in Reproducing the saving claim.