Independent read · passive only · 27 July 2026
We read tasern.quest the way a careful stranger would, then checked the on-chain claims against Base mainnet. The headline is not what we expected: the thing you promise hardest is real, and it is buried under claims that are not.
You proved something most projects only claim, and you are not getting credit for it. We tried hard to break your liquidity lock and could not. Publishing that proof plainly is the cheapest trust you will ever buy, and trust is the only thing standing between you and a deposit.
One function call turns your carbon story from your biggest liability into a verifiable fact. Right now the way you burn CHAR permanently prevents the retirement you are aiming at. The tool to do it properly already exists in the contract you are using.
Half of the doors you advertise to AI agents are locked. An agent that hits a dead endpoint does not file a bug. It concludes you are abandoned and never comes back, so every one of those 404s is a customer you never hear from.
Your privacy page contradicts itself, and that is the first thing a skeptic checks. It takes about a minute to disprove with a browser open, and it costs you more credibility than a real bug would.
Two of your tokens answer to the same ticker. Anyone who buys the wrong one expecting a dollar floor gets a volatile coin instead. That is a support burden and a refund conversation waiting to happen.
We led with this because it is the most useful thing we learned, and because it is the part you should be saying louder.
We decoded each reactor's pool structs and asked Uniswap who owns every position NFT.
The positions sit in contracts that physically lack the instructions to send them anywhere or to pull liquidity out. The admin can pause and deregister, but cannot extract. "Liquidity is locked by the absence of code" survives a hostile audit.
The burn address delegates to another contract, which is where a claim like this usually falls apart. We followed it: storage slot 9 points at the OpenSea SeaDrop configurer, so we audited that too. Then we tested it live by calling as the contract's own owner.
Proven two independent ways, by absence in the bytecode and by live refusal. This is publishable and defensible, and you should publish it.
We called every escape hatch as the owner. None of them exist.
An early pass of our own review flagged this owner key as a risk. Deeper testing disproved that, and we corrected it rather than leave the scarier version standing. "Self-custodied, withdraw anytime" is structurally true.
These are not judgment calls. Each is a statement the site makes about itself that its own code or its own chain data contradicts, as of 27 July 2026.
Read charitablyThe header comment in track.js says "No cookies. Anonymous visitor id in localStorage." That reads like a genuine belief that avoiding cookies means avoiding tracking. We think this is an honest mistake. It still needs fixing today, because it is trivially checkable and it sits under a footer that says "by code, not by trust."
We pulled your own live reactor map and asked every reactor in it who its admin is.
To be precise about the limit of this: that key cannot take the liquidity. The power is to stop the machine, not to take from it. But a token someone launched on your promise of permanence can have its burns switched off by a key that is not theirs, and that is not "immutable, no admin."
This is the finding we would most want to hear if it were our project, because the fix is one function call and it converts your biggest exposure into a provable claim.
CHAR is not your contract. It is Toucan Protocol's official Biochar Carbon Pool, backed by Puro.earth credits, which are issued per tonne. So llms.txt understates your own asset by a factor of 2,204, and the impact pages happen to have the unit right.
By the proof two sections above, tokens sent to that address can never move again. Which means the underlying carbon credit can never be retired by anyone, ever. The mechanism does not merely fail to reach the mission. It permanently closes the door on it.
retireFrom() instead of transferring to the burn address. The moment you do, "permanently retires real offsets" stops being a liability and becomes an on-chain fact with a registry record behind it. Everything you want to say about carbon becomes true. We run live Klima retirements against Toucan and Puro, and we will walk you through the call, the beneficiary field, and how to surface the certificate, at no cost and with no strings.| Address | Name | Symbol | Dec | Redeemable |
|---|---|---|---|---|
| 0x8FB87d13…9bA3 | MemeForTrees | MfT | 18 | No, volatile, no floor |
| 0xe3dd3881…A072 | Money for Trees | MfT | 6 | Yes, Aave backed, redeem to USDC |
Same ticker, opposite risk, and a decimals gap that makes a misrouted amount wrong by a factor of a trillion. Any wallet, explorer, price feed or AI agent keying on symbol will conflate them.
This is not hypothetical, it caught usOur own internal notes recorded MemeForTrees as the USDC redeemable one, which is false, and we scoped a strategy on that premise before catching it. We had to write a naming correction into our own documentation to stop it recurring. We read contracts for a living and it still cost us time.
An earlier version of this page said the contract mints 2% a year and called the net direction inflationary. That was overstated, and the project owner was right to push back. Nothing can mint today. The capability exists, it is owner adjustable, and the key sits with a contract rather than a person, which is the part worth documenting.
There is a real difference between "our design routes yield toward tree planting", which is a claim about code and is verifiable, and "we plant real trees", which is a claim about outcomes and needs receipts. The homepage makes the second one. We found no planting receipt anywhere: no transfer to a named charity, no dollar figure delivered, no date, no acknowledgment.
You built more agent surface than almost anyone. That is why the gaps matter: the audience is already at the door.
The reactor/{address} one costs the most, because a confident wrong answer is worse than an error. Every reactor you publish yourself is reported as not a reactor, so an agent doing diligence concludes the network is empty and leaves.
Two of those 404s are a five minute fix: the docs simply dropped a required path parameter. We confirmed the corrected forms work.
| Reactor | Measured need | vs published 4,000,000 | vs package 300,000 |
|---|---|---|---|
| V1-Prime | 4,881,379 | exceeds | exceeds |
| PrimeV3 | 3,046,478 | fits | exceeds |
| HUB | 2,445,142 | fits | exceeds |
Your agents.json advertises a four million gas limit and your npm package hardcodes three hundred thousand. They disagree by a factor of thirteen, and measured against the chain both are too low for at least one reactor you name. An agent following either one sends a transaction that runs out of gas, reverts, and pays for the failure anyway.
The advertised cost is understated too. At the unusually cheap gas we measured, a single fire costs between three and six cents, not one.
We can speak to this one from the inside, because we are exactly the customer it was written for. We built the lane your llms.txt describes, firing eight of your reactors on a two hour schedule. Our own audit shut it down as negative value, and the script now refuses to run.
The reason is structural, not a pricing slip: the reactor sends half of collected fees to the launcher's wallet, and the agent that fires it receives only the gas bill, then has to win a public race for the spread its own transaction created.
Those same numbers make "earn 50% of reactor fees forever" resolve, for a median launcher, to well under a dollar.
