A digital engagement · rewritten 30 July 2026 · unlisted

Four doors your agents
walk into and bounce off.

No scoring and no opinions about your copy. We knocked on every door you advertise to agents, measured what the chain actually charges to fire a reactor, and rebuilt the files that were wrong. Everything here is yours to keep and paste, whether or not we ever work together.

Reading this with an agent?

The complete engagement, every finding and all the evidence, is one fetch. Nothing is held back for the human version.

vealth.net/tasern.md

01 · Broken doors

Seven of the fourteen endpoints you advertise are dead or wrong

You built more agent surface than almost anyone on Base. That is exactly why these cost you: the audience is already knocking.

/api/unrugable/signals 404 (Allow:'d in your robots.txt) /api/unrugable/performance 404 (Allow:'d in your robots.txt) /api/unrugable/gallery 404 /api/baseling/agent/ 404 .../economy/phase 404 (docs dropped /:wallet) .../economy/feeding 404 (docs dropped /:job) /api/unrugable/reactor/{addr} 200 but ALWAYS WRONG also 404, both listed in your own sitemap.xml: /agents/ /reactor-explainer.html as of 27 July 2026

The reactor/{address} one costs the most, because a confident wrong answer is worse than an error. Every reactor you publish yourself comes back isReactor:false, so an agent doing diligence concludes the network is empty and leaves without filing a bug.

Two of those 404s are a five minute fix. The docs simply dropped a required path parameter, and we confirmed the corrected forms return 200.

Paste thisAdd the two missing path parameters to llms.txt, delete the three routes that do not exist, and back the reactor lookup with your own reactor-map.json. That file is live, fresh, regenerated hours before we read it, and already correct. It is the answer to two of these on its own. Generating agents.html from the shipped tool list stops the drift recurring; it currently documents seven tool names that are not in the package.

02 · Broken doors

Both published gas numbers are too low, so agents pay for failures

ReactorMeasured needvs agents.json 4,000,000vs package 300,000
V1-Prime4,881,379exceedsexceeds
PrimeV33,046,478fitsexceeds
HUB2,445,142fitsexceeds

Your agents.json advertises a four million gas limit. 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 yourself. An agent that follows either number sends a transaction, runs out of gas, reverts, and pays for the failure anyway.

The advertised cost is understated with it. At the unusually cheap gas we measured, a single fire lands between three and six cents, not one.

Paste thisDelete both hardcoded numbers and tell agents to estimate, then add a buffer. Gas here scales with accrued fees, so any fixed published limit is wrong by design. It will drift again the moment fees accumulate.

03 · Broken doors

Your install line hands a private key to an unpinned package

Your instructions ask an agent to put a raw private key in an environment variable for an npx package with no version pin, and mcp.json puts that key on the command line, where it lands in shell history.

To be clear about what we did and did not find: we read your v1.4.0 source and it is clean. The key never leaves the process, there are no install scripts, there is one dependency, and the provenance signature is present. This is a design risk, not an accusation. But unpinned npx resolves latest on every single run, so one future compromised publish would reach every agent that ever ran your line.

Paste thisPin the version in the documented command, and move the key out of the mcp.json command line into the env block. One line each, and the tail risk closes entirely.

04 · One call

The carbon claim is one function call away from being a fact

Today CHAR goes to the burn address. By your own design that address can never release a token, which means the underlying credit can never be retired by anyone, ever. The mechanism permanently closes the door on the mission it was built for.

CHAR is Toucan's Biochar Carbon Pool and it already ships the tool you need.

// today: the credit is stranded forever char.transfer(BURN_ADDRESS, amount); -> removed from circulation -> NOT retired on any registry -> can never be retired, by anyone, ever // what makes the claim true char.retireFrom(beneficiary, amount); // 0x6b24ffd6 -> a real Toucan and Puro retirement record -> a certificate you can link from carbon.html -> "permanently retires real offsets" becomes a FACT

The same contract exposes redeemAndBurn(address,uint256) at 0x89022e2e. Pick whichever matches how you want the beneficiary recorded. We run these live against Toucan and Puro, and the offer to walk you through the beneficiary field and the certificate surface stands at no cost.

While you are in thereYour llms.txt says 1 CHAR equals 1 lb. Your impact pages say 1 tonne. Toucan issues per tonne, so the impact pages are right and llms.txt is understating your own asset by a factor of 2,204.

The files

Rebuilt, not described

A corrected llms.txt, an agent card that matches the package you actually shipped, honest tool schemas, and every advertised door with its tested result next to it. Nothing here is a mockup of work we would do later. It is the work.

A correction, because you caught one. An earlier version of this page said the MfT contract "mints 2% a year." That was overstated and you were right to push back.

Rechecked on Base on 30 July 2026: yearlyMintRate is 2e16 and mintInflation() is in the bytecode, but currentYearStart is 0, lastMintTimestamp is 0, isPoolUnlocked is false, and totalSupply is still exactly 100,000,000,000. The inflation clock has never been started, so nothing can mint today. We also never said who holds the key, which was the real omission: owner() is 0x660eaa…8d12, and it is a contract, not your wallet.

The capability is worth a line in your own docs so nobody else has to guess at it. It is not the thing we should have led with, and it is not a finding.

Provisioned by EcoWealth · Digital Provisioning Protocol · provenance‑sealed