Capability + traffic-readiness brief · Warm relationship · Evidence-first

ecoBridge built the retirement rail and the Regen relationship for real. It never built the front door an agent needs to use either.

bridge.eco / ecoToken ships a genuinely capable cross-chain retirement bridge with a deep, technical Regen Network relationship — credited below in detail. The gaps sit in two places: what makes it legible to an autonomous agent, and what makes the live site itself ready for real traffic. Every finding below carries the exact URL, HTTP status, or rendered observation, and a one-line re-check.

Method + relationship. Passive HTTP/API recon (curl, standard browser UA) plus headless-rendered (Playwright) page loads of bridge.eco, ecotoken.earth, app.ecotoken.earth, and scan.ecotoken.earth, each captured for console errors, page errors, failed requests, and total transferred bytes — the same thing any visitor's browser does. One read-only MCP (the interface an AI assistant calls to use a service correctly) call (browse_ecobridge_tokens) was made against Regen's public regen-compute server; the state-changing retire_via_ecobridge tool was never called. Captured 2026-07-16. This is not a cold audit: EcoWealth's regen-compute MCP integration already ships both ecoBridge tools, and the operator holds a warm contact for bridge.eco. Full reproduction commands: evidence.json.

The landscape, mapped

ecoTokenThe company. Team page (ecotoken.earth/about/): James Bettauer (CEO/Founder), Alexander Paredes (CTO), Forrest Rohr (COO/Sales), Kerstin Butzelaar (Marketing).
ecoBridgeThe one consumer-facing brand across two live domains: ecotoken.earth (WordPress marketing/blog, <title> "ecoBridge – Cross-Chain Environmental Credits") and bridge.eco (the live app, <title> "bridge.eco - Powering Regeneration").
CCEP / ecoLedgerTwo names, same protocol layer, both in live use today: scan.ecotoken.earth is titled "CCEP Scanner"; ecotoken.earth's own homepage names the identical concept "ecoLedger."
Front-endsbridge.eco (Swap/Impact/Stake/AI) · app.ecotoken.earth (Solana) · eclipse.ecotoken.earth (Eclipse) · aptos.ecotoken.earth (Aptos) · regenatlas.xyz (CELO) · scan.ecotoken.earth (cross-chain proof scanner).
Regen tie$REGEN adopted as CCEP/ecoLedger's governance token (Oct 2024); all ecoLedger data posted to Regen Ledger; a live ecoBridge-run validator on Regen Network; ecoBridge's CEO has a direct commit on regen-network/regen-compute.

Baseline — credited first, in detail

ecoBridge is genuinely capable infrastructure, and the Regen relationship is real and deep. bridge.eco routes any-asset swaps through Squid Router across 70+ chains (confirmed in its own bundled JS), then funds a specific Regen project retirement through api.bridge.eco/registry — a live, open, no-auth, CORS-unrestricted API whose per-project data includes an unusually sophisticated LLM-ready quality rubric and sales-copy object. ecoBridge doesn't just integrate with Regen: it adopted $REGEN as its own protocol's governance token, posts its ledger data to Regen Ledger, and runs an actual validator on Regen Network. This is not a "you're behind" brief.

The bottom line, in plain English

Publish a real front door → the agents and developers already trying to use your rail can actually reach it

Your registry API is genuinely agent-ready, but nothing tells a machine it exists and your standard discovery paths hand back a fake shell — so a buyer's assistant sizing up ecoBridge reverse-engineers your JS or gives up; a one-page front door turns that interest into completed retirements.

Fix the mislabeled credit and the empty payment wallet → a buyer doesn't mis-report or dead-end mid-purchase

One project is tagged the wrong credit class and another has no address for EVM payers, so an agent could retire the wrong thing or a customer could hit a dead payment at checkout — two small data fixes protect the trust and the transaction at the exact moment money moves.

Clear the readiness bugs and give shared links a preview → the social traffic ReFi runs on stops arriving to a blank

A broken wallet import, a heavy first paint, and no social-preview tags mean every link posted to X, Discord, or Telegram renders bare and some visitors land on something sluggish — cheap fixes that keep the person who already clicked through, on the channel your growth depends on.

Finding 1 — a real, rich API that ecoBridge's own docs don't mention

Provable · CREDIT, with a documentation gap

api.bridge.eco/registry embeds agent-ready sales/quality data most institutional APIs don't bother with.

The live endpoint bridge.eco's own SPA calls at runtime (confirmed in its bundled JS: `${API_BASE_URL}/registry`) returns schema v2.0, CORS-open, no auth, 11 projects. Each one carries an 8-dimension quality rubric (MRV, additionality, permanence, leakage, safeguards, governance, vintage, controversy), a computed quality/impact score, risk flags, AND a salesEnablement block — elevator pitch, key facts, objections-and-responses, explicit claims-allowed / claims-not-allowed guardrails, next-step CTA — structured exactly the way an LLM would want to relay it to a buyer. ecoBridge's own GitBook developer guide never mentions this endpoint; it points integrators at a different, older one instead (Finding 6).

$ curl -s https://api.bridge.eco/registry | python3 -c \ "import json,sys; d=json.load(sys.stdin); p=d['projects'][10]; \ print(list(p['assessment']['salesEnablement'].keys()))" ['elevatorPitch', 'keyFacts', 'recommendedFor', 'objectionsAndResponses', 'claimsAllowed', 'claimsNotAllowed', 'buyerNextStepCTA', 'evidenceLinks']
Why it matters: this is more agent-forward than most institutional API surfaces we've reviewed — it's built to be read and relayed by an LLM. The gap is discoverability, not capability: nobody publishes that this endpoint exists, so an agent (or a developer) has to reverse-engineer it from the JS bundle, the same pattern we've seen on other app-domain SPA-shell surfaces.
Re-check: curl -s https://api.bridge.eco/registry | python3 -c "import json,sys; d=json.load(sys.stdin); print(d['version'], len(d['projects']))"

Finding 2 — the Regen relationship is infrastructure-deep, and personally close to us

Provable · CREDIT + relationship context

ecoBridge runs a validator on Regen Network and adopted $REGEN as its own governance token — and its CEO has a commit on the same MCP repo our own operator does.

ecoBridge's October 2024 announcement states, verbatim: "ecoBridge is decentralizing the governance of its Cross-Chain Ecological Communication Protocol (CCEP) and ecoLedger core protocol by adopting the $REGEN token as its governance token and posting all ecoLedger data to the Regen Ledger," quoting CEO James Bettauer calling Regen "our longest-standing partner." Independently confirmed live: bridge.eco's own Stake tab lists "ecoBridge on Regen Network" ($77,266 TVL, REGEN token, 5% commission, 16.02% APR) as one of three validators ecoBridge operates (the other two on the 0G/Zero Gravity chain, $4.29M combined TVL). Deepest tie: the public GitHub API shows ecoBridge's own CEO (github.com/ecoTokenJames) has a direct commit on regen-network/regen-compute — the identical public MCP server this brief's agent-readiness findings depend on, and the same repo EcoWealth's own operator (github.com/brawlaphant) independently has 5 commits on.

$ curl -s https://api.github.com/repos/regen-network/regen-compute/contributors | \ python3 -c "import json,sys; [print(c['login'],c['contributions']) for c in json.load(sys.stdin)]" CShear 21 ToknWrks 8 brawlaphant 5 Copilot 3 DarrenZal 1 ecoTokenJames 1
Why it matters: this isn't a cold read of a stranger's stack. Regen and ecoBridge are already technically entangled at the code level, and so are we — through the same repo. A warm handoff here has more standing than a generic "we found your site" pitch.
Re-check: curl -s https://ecotoken.earth/ecotoken-partners-with-regen-network-to-bring-ecocredits-to-all-web3-ecosystems/ | grep -o "REGEN.*governance token"

Finding 3 — ecoBridge's own "AI" tab isn't an agent's front door

Provable · UI-observed + documentation search

"Hi, I'm ecoAgent" is a real, credit-due chat feature — and a dead end for any headless agent.

bridge.eco's SPA has a fourth nav tab literally labeled "AI." Clicking it opens: "Hi, I'm ecoAgent — Your AI guide to ecological impact. I can help you find carbon credit projects, swap tokens across chains, or start staking," with canned prompts and a free-text box, footed "Powered by Bridge.eco AI." That's a genuine, credit-due signal ecoBridge has already invested in AI-facing UX. But it's a proprietary widget inside the same closed SPA already shown to have zero machine-discoverable manifest (Finding 4) — and a full 28,592-byte export of ecoBridge's own GitBook documentation contains zero occurrences of the words "agent" or "MCP."

$ curl -s https://ecotoken-2.gitbook.io/ecotoken-docs/llms-full.txt | grep -ci "mcp\|agent\|x402" 0
Why it matters: the ONLY agent-callable interface to ecoBridge that exists anywhere — browse_ecobridge_tokens / retire_via_ecobridge — lives in Regen Network's own regen-compute MCP server, built and maintained by Regen (with a commit from ecoBridge's own CEO), not published or referenced by ecoBridge itself.
Re-check: load https://bridge.eco/, click "AI" in the top nav — the ecoAgent panel renders with no wallet connection required.

Finding 4 — the standard discovery paths are a soft-200 / true-404 split

Provable · soft-200 blind wall (bridge.eco) / true-404 desert (ecotoken.earth)

Every agent-shaped path on bridge.eco returns the identical 465-byte SPA shell; every one on ecotoken.earth true-404s.

These are the standard files an AI agent checks first — llms.txt is the file AI assistants read first, agent-card.json is the file that lets an AI assistant use a service correctly. /llms.txt, /ai.txt, /sitemap.xml, /.well-known/agent-card.json, /.well-known/ai-plugin.json, /.well-known/security.txt, /.well-known/x402, /.well-known/agent.json, /.well-known/agents.json, /.well-known/mcp/server-card.json, and a nonsense-path control ALL return HTTP 200 with the SAME 465 bytes on bridge.eco — the bare React shell, not real files. bridge.eco/robots.txt IS real and unusually thoughtful (an IETF Content-Signal policy, explicit GPTBot/ClaudeBot/Google-Extended rules) — credit due — but it's a crawler-permissions file, not a discovery manifest. ecotoken.earth shows the opposite shape: the same agent paths all TRUE-404 (89,492 B, byte-identical to a nonsense control), while its /robots.txt is real but generic WordPress boilerplate.

$ for p in llms.txt .well-known/agent-card.json .well-known/x402 \ this-is-a-control-xyz123abc.txt; do curl -s -o /dev/null \ -w "$p %{http_code} %{size_download}B\n" https://bridge.eco/$p; done llms.txt 200 465B .well-known/agent-card.json 200 465B .well-known/x402 200 465B control 200 465B # identical shell, every path
Why it matters: a naive agent checking "is this 200?" is told an agent-card.json exists on bridge.eco when it doesn't — and a stricter agent checking ecotoken.earth gets an honest 404, but still finds nothing.
Re-check: curl -s -o /dev/null -w '%{http_code} %{size_download}\n' https://bridge.eco/.well-known/agent-card.json

Finding 5 — the credit-type claim doesn't match the live inventory

Provable · batch-code verified against Regen's own project URIs

"All Regen credit types" in practice = Carbon, one correctly-labeled Terrasos project, and one mislabeled KSH01 project. Zero Marine Biodiversity, zero Umbrella Species.

Regen's own regen-compute MCP instructions state ecoBridge "enables cross-chain payment for all Regen credit types" (Carbon, Terrasos/Biodiversity, KSH, Marine Biodiversity, Umbrella Species). Checking the live registry's 11 projects against Regen's own project URIs: 8 are genuinely Carbon (batch prefixes C02/C03), 1 is correctly Biodiversity/Terrasos (El Globo Habitat Bank, batch BT01-001), and 1 — Grgich Hills — carries batch code KSH01-001 (Regen's own Kilo-Sheep-Hour class) but is labeled by ecoBridge's OWN registry as type:"Carbon", category:"soil_carbon", unit:"tCO2e". No Marine Biodiversity (MBS01) or Umbrella Species (USS01) project exists in the registry at all.

$ curl -s https://api.bridge.eco/registry | python3 -c \ "import json,sys; d=json.load(sys.stdin); \ [print(p['id'],p['name'],p['batch'],p['type']) for p in d['projects']]" | tail -2 10 Grgich Hills KSH01-001-20230101-20230501-001 Carbon # mislabeled — it's KSH 11 Kasigau Corridor REDD C03-004-... Carbon
Why it matters: an agent trusting either the MCP maintainer's claim or ecoBridge's own type field would misreport what credit class it actually retired for the one KSH01 project that IS available — and would incorrectly believe Marine Biodiversity or Umbrella Species retirement is possible through this rail when it isn't, today.
Re-check: curl -s https://api.bridge.eco/registry | python3 -c "import json,sys; [print(p['batch']) for p in json.load(sys.stdin)['projects']]"

Finding 6 — smaller data-integrity gaps in the same registry

Provable (wallet field) · screenshot-observed (price, timestamped)

An empty EVM wallet on a listed project, plus a live price mismatch between the API and the rendered marketplace UI.

Kasigau Corridor REDD (id 11) has evmWallet: "" — empty. Anyone or any agent paying from Base, Ethereum, Polygon, or any EVM chain for this specific project has no destination address; only its Solana wallet is populated, and nothing in the UI discloses this before selection. Separately: app.ecotoken.earth's live marketplace card for "Inner Mongolia Forest" displayed "Price (USDC): 2.00 USDC" at capture, while api.bridge.eco/registry's price field for the same project read 1.5 in the same session — possibly an undisclosed $2 minimum-transaction floor rather than an error, but neither surface states that rule where the two numbers are visible together.

$ curl -s https://api.bridge.eco/registry | python3 -c \ "import json,sys; d=json.load(sys.stdin); \ p=[x for x in d['projects'] if x['id']==11][0]; print(repr(p['evmWallet']))" ''
Why it matters: both are small, concrete, fixable data issues — not architecture problems. They're exactly the kind of thing a second set of eyes (or an agent doing a pre-flight check) catches before a real user hits it mid-transaction.
Re-check: curl -s https://api.bridge.eco/registry | python3 -c "import json,sys; print([p['evmWallet'] for p in json.load(sys.stdin)['projects'] if p['id']==11])"

Finding 7 — three chain-count claims, none matching

Provable · cross-referenced across three of ecoBridge's own live properties

"70+ chains," "10 chains," and two different "8 chains" lists — all from ecoBridge itself, all different.

bridge.eco's homepage: "bridge.eco powers any-asset DeFi swaps across 70+ blockchains… enables direct retirement of verified ecocredits and project funding on 10 chains." The GitBook dev doc: "We currently offer 9 projects spanning 8 blockchains… Solana, Celo, Eclipse, Base, Polygon, Aptos, Arbitrum, and Optimism." The live api.bridge.eco/registry (and the MCP's own browse_ecobridge_tokens, which reads the same data): 0g, arbitrum, base, celo, ethereum, optimism, polygon, solana — a DIFFERENT set of 8 (includes 0G and Ethereum, excludes Eclipse and Aptos).

$ curl -s https://api.bridge.eco/registry | python3 -c \ "import json,sys; print(sorted(json.load(sys.stdin)['supportedTokens'].keys()))" ['0g', 'arbitrum', 'base', 'celo', 'ethereum', 'optimism', 'polygon', 'solana']
Why it matters: none of these numbers is wrong on its own (10 total retirement chains vs. 8 with live token pricing today is plausible), but stated side by side with no reconciling context, they read as inconsistent — the kind of small thing a real buyer or integrator notices and asks about.
Re-check: curl -s https://ecotoken-2.gitbook.io/ecotoken-docs/regen-cross-chain-retirements.md | grep -i "blockchains include"

Finding 8 — traffic-readiness: page weight, real JS errors, and dead link previews

Provable · headless-rendered, 2026-07-16

The operator's read holds up: bridge.eco and ecotoken.earth both carry real, fixable readiness problems — credited where the readiness is genuinely fine.

bridge.eco: 28,628,150 bytes transferred (17.2 MB JS bundle) to render a swap widget, plus a real console error every load — Failed to initialize stellar wallets: TypeError: Failed to resolve module specifier "@stellar/stellar-base" — a broken import, not noise; Stellar wallet support is non-functional. ecotoken.earth: an actual uncaught page error on the flagship marketing/blog homepage — Uncaught TypeError: Bootstrap's JavaScript requires jQuery — meaning Bootstrap-dependent interactive elements are broken by script load order. app.ecotoken.earth: 11.5 second load time and 35.7 MB transferred (zero console/page errors — clean code, just heavy). Neither domain ships a single Open Graph or Twitter Card tag — every link shared on X/Discord/Slack/Telegram renders bare, no title, no image. Credit where due: scan.ecotoken.earth is clean and light (3.9s, 1.9 MB, zero errors); the core Swap/Impact/Stake/AI flows on bridge.eco and all of scan.ecotoken.earth throw no uncaught exceptions beyond the two quoted above.

Playwright, networkidle, 2026-07-16: bridge.eco 28.6 MB · 43 req · 1 console error (stellar-base) ecotoken.earth 10.3 MB · 49 req · 1 page error (Bootstrap/jQuery) app.ecotoken.earth 35.7 MB · 11.5s load · 0 errors (heavy, clean) scan.ecotoken.earth 1.9 MB · 3.9s load · 0 errors
Why it matters: this is the "is the site ready for real traffic" question, answered with evidence rather than a hunch. Two are genuine bugs (Stellar import, Bootstrap load order), one is a weight/speed risk on a slow connection, and the OG-tag gap silences every social share — the exact channel a ReFi/crypto project depends on. None of it is expensive to fix.
Re-check: curl -s https://bridge.eco/ | grep -c 'og:' (0) then load either domain in a browser with devtools console open.

Finding 9 — the 5-second test: split result

Provable · UI-observed

ecotoken.earth passes cold. bridge.eco — the app people actually transact through — doesn't, yet.

ecotoken.earth's hero reads "Blockchain Powered Environmental Credit Solutions" with a plain-language subhead, then two short paragraphs explaining Bridge.eco and ecoLedger — a stranger understands the pitch in one screen. bridge.eco's actual first screen, before connecting a wallet, is "Pay : Connect wallet / ETH / 0" and "Receive : Select recipient / REGEN / 0" with a green Connect button and one small line ("0.2% fee funds eco projects") — no sentence anywhere states this is a carbon-credit retirement tool or what REGEN is.

Why it matters: the marketing site sells the vision well; the actual product, where value moves, assumes the visitor already knows what they're looking at. That's a one-line copy fix, not a redesign.
Re-check: load https://bridge.eco/ in a private window and time how long it takes to state in one sentence what the page does.

The ask

Fund one EWP field-work packet tied to a real ecoBridge/Regen project — plus three small, named fixes.

Fund one EWP work packet — an MRV visit, a planting-verification walk — near one of the 11 projects already in ecoBridge's own registry, paid by any x402-aware agent (x402: a web-native way for AI agents to pay per use) for a few cents to a few dollars, settled on Base independent of ecoBridge's liquidity or wallet requirements. Deliverable: an on-chain settlement receipt, citable alongside the project's existing MRV record.

Separately, three small, technical, in-character fixes: publish a real llms.txt at the standard path on bridge.eco; correct the KSH01 project's type label; populate Kasigau's empty EVM wallet or remove it from EVM-payment listings until it's fixed.

Why this and not a cold pitch: EcoWealth's regen-compute MCP integration already ships both ecoBridge tools, the operator holds a warm contact for bridge.eco, and ecoBridge's own CEO already has a commit on the exact repo our operator contributes to. Proof first, ask second.

← Hub · Run the demo · Agent Kit →

Provisioned by EcoWealth · Digital Provisioning Protocol · provenance‑sealed ↗