# Check every claim on this site yourself, without being a developer

> Canonical: https://blazephoenix.xyz/learn/check-it-yourself
> License: CC BY 4.0 (attribution + link) · © 2026 BlazePhoenix
> Updated: 2026-08-13

Five claims from this site and the exact browser steps that confirm or refute each, needing no programming: take the address from the canonical source and compare it character by character, understand what explorer verification does and does not prove, call PROTOCOL_FEE_BPS on the Read tab and see 28, and prove the fee cannot be raised by finding no function anywhere that writes it — each step ends in a number you either see or do not.

Everything in the previous articles is a claim. Some are arithmetic you can redo on paper, and those you have already checked. The rest are claims about what particular contracts do, and those you should not take from us.

This article is a procedure. It needs a browser, a block explorer, and no programming. Each step ends with a number you either see or do not see, which means each step can fail — that is what makes it a check rather than a reassurance.

## Step zero: the address is the whole problem

Every check below reads a contract. If you read the wrong contract, every answer will be beautifully consistent and completely irrelevant, because someone can deploy a copy of any contract with one line changed and it will pass every test you run against it.

So the address is not a detail; it is the entire trust decision, and the rest is mechanical. Take it from the project's own site or its public repository, and compare it character by character — attackers generate addresses that match at the start and the end.

One rule follows from how this project publishes. Neither the whitepaper nor the litepaper contains a contract address, on purpose, and both are Version 2 authored by Mitra. A PDF circulating with an address in it and this project's name on it is therefore not ours, and that single fact makes an entire category of phishing document identifiable at a glance.

## Step one: what "verified" on an explorer means

Paste the address into a block explorer and open the Contract tab. If it shows source code with a verification mark, it means the published source compiles to exactly the bytecode running at that address. You are reading the real code.

Be precise about what that does not mean. It does not mean the code is safe, audited, or well written. It does not mean it is the contract you wanted. Verification is an identity check on the source, and nothing more.

One thing to look for while you are there: whether the address is a proxy, which is a contract that forwards its calls to another one that can be swapped later. If it is, then the code you are reading is today's code, and your check has a shelf life.

## Claim 1: the protocol fee is 28 basis points

On the Contract tab, choose Read. Find PROTOCOL_FEE_BPS and call it. It takes no arguments and costs nothing.

It must return 28. A basis point is one part in ten thousand, so 28 bps is 28 / 10,000 = 0.0028, which is 0.28%. Apply it to the worked trade from the earlier articles: a gross output of 90.6611 pays 90.6611 x 0.0028 = 0.2539, leaving 90.4072 — which is the net quote used throughout this series.

If it returns anything else, every fee number in these articles is wrong and you should say so publicly.

## Claim 2: the fee cannot be raised later

This one is proved by absence, which is a different skill, so here is how to look for nothing.

On the same source page, use your browser's find function for PROTOCOL_FEE. It should appear as a constant — a value fixed at compile time, which cannot be written to at any point in the contract's life. Then search for the ways a value like that is normally changed: setFee, setProtocolFee, updateFee, onlyOwner. If there is no function that assigns to it, no one can raise it: not the deployer, not a governance vote, not us.

The limits of this check are worth stating. It proves the claim for the address you are reading and today's code at it, which is why step one asked about proxies. And it is a claim about this fee only — it says nothing about the fees charged by the third-party pools your trade routes through.

## Claim 3: the supply is one billion tokens

Open the token contract, Read tab, and call totalSupply(). You will get something that looks unreadable:

```
1000000000000000000000000000

That is 1 followed by 27 zeros.
Tokens use 18 decimal places, so divide by 10^18
(move the decimal point 18 places left):

  1,000,000,000 tokens
```

While you are there, call decimals() and confirm it returns 18, because that is the number you just divided by. Then check the staking budget against it: 180,000,000 of 1,000,000,000 is 18.0%, and of that budget the halving curve pays out 179,296,875, leaving a tail of 703,125.

## Claim 4: the staking contract cannot pay what it does not hold

Rewards have to come from tokens the staking contract actually has. On the token contract, Read tab, call balanceOf() with the staking contract's address as the argument. Divide by 10^18 as before.

That number is a hard ceiling on everything the staking contract can ever pay, no matter what any interface reports as a rate. Compare it against the remaining schedule from the halving article. If the balance is far below what the schedule still owes, that is a real question to ask publicly, and it is exactly the kind of question this procedure is for.

## Claim 5: the floor is 80% per leg

On the router, look for the per-leg minimum: 8,000 basis points, which is 8,000 / 10,000 = 80%. Every leg of a route must return at least that fraction of what the chain itself quoted for that leg, measured before the protocol fee, and the aggregate floor is clamped so that it can never sit below 80% either.

Having checked it, read it correctly. Eighty percent is a catastrophe stop, not a good fill — a route returning 81% of its own quote is a disaster the contract would still execute. The number that protects you on an ordinary trade is the tolerance you set yourself.

## What our own checks prove, and what they do not

Beyond reading constants, you can ask what verification stands behind the code. Here is the honest inventory.

The trading contracts carry two symbolic proofs that must pass before any change is merged, static analysis that fails the build on any high-severity finding, and a deployed-size guard set at 24,000 bytes against the chain's own limit of 24,576 — deliberately tighter than required, so that the build fails before the chain would reject it. A third specification exists and times out rather than finishing, and a specification that times out proves nothing at all. It is listed here because omitting it would make the two that do pass sound like a completeness they are not.

The staking contract has no prover and no static analyser in the pipeline today. That is a gap, stated as a gap.

Seven findings have been disclosed in staking and one in the router. Three external researchers were involved — NetGakarot, Amit kumar and AmanDara1 — with one of the seven found internally. Five of the seven are the same relational error repeated, and two are a clock advanced without writing its counterpart. Six of the seven were invisible to the conservation check that watches the books, which is the most useful sentence in this article: a passing invariant proves the thing it measures, and is silent about every dimension it does not.

## Where our own numbers are known to be optimistic

A verification article that only lists strengths is an advertisement. So, the current state of venue support, as measured rather than as advertised.

Five pool families work end to end, and four of them have been demonstrated in fork tests against real chain state. One family, Cryptoswap, is not reachable by the discovery process at all. One pool kind is handled as an ordinary constant-product pair even though the mathematics for weighted pools is not implemented, so quotes for it rest on an assumption about its shape. And Algebra pools are quoted with a fee of zero, which means quotes involving them are systematically optimistic: the price you are shown is better than the price such a pool will give you.

That last one is exactly the sort of thing a project is not supposed to print. It is here because the alternative is that you find it yourself, at your own expense, and conclude correctly that nothing else we wrote can be trusted either.

## The habit, rather than the checklist

Three questions generalise everything above, and they work on any protocol, not just this one. Where does this number come from, and can I read it at its source? What exactly does the check that supposedly protects me measure, and what is it blind to? And what would have to be true for this claim to be false — can I look at that?

Apply them here. Apply them to the article you are reading, which asserts several things about contracts and asks you to go and confirm them. A claim you cannot check is a claim you should discount, and that includes ours.

**Verify it yourself:** cast call 0x4cEF0615614B212895F45Aa1D4833B16666E18d3 "PROTOCOL_FEE_BPS()(uint256)" --rpc-url https://mainnet.base.org — or, with no tools at all, the explorer Read tab on the same address. It must return 28.

Related: https://blazephoenix.xyz/learn/how-to-verify-a-contract · https://blazephoenix.xyz/learn/what-is-a-block-explorer · https://blazephoenix.xyz/learn/three-prices · https://blazephoenix.xyz/learn/minimum-output-explained · https://blazephoenix.xyz/learn/signing-vs-sending