Evidenced capability brief · Passive recon only · Unlisted · Not affiliated
Sylvera's own open standard already has a field for what we do. Nobody's filled it in yet.
In one plain sentence: Sylvera rates and prices carbon credits that already exist: it doesn't verify the on-the-ground labor that has to happen before a credit can be retired, and its own open data standard (CDOP) has a field built for exactly that receipt. This page shows the field, shows our receipt fitting it, and proves the fit by actually running Sylvera's own validator against it, not just claiming it would work.
Not affiliated: read this firstEcoWealth has no relationship, contact, or communication with Sylvera. This package is independent, unsolicited, passive-recon work: not requested, produced, reviewed, or endorsed by Sylvera in any way. Nothing here is sent to Sylvera or posted publicly; it is staged locally, noindex, and reviewed internally only.
Who Sylvera is, in one line. Sylvera is the market-leading independent carbon credit ratings agency (AAA–D scale, four-pillar methodology) now expanding into a full carbon/commodity data utility: a >400M-tCO2e credit marketplace, an Article 6/CORSIA compliance hub, a Bloomberg Terminal feed, while co-chairing the Carbon Data Open Protocol (CDOP) with RMI and S&P Global, an open-source data schema with 52 participating organizations including many of its peers across the ratings field.
Read this first. Independent recon by EcoWealth Corporation. Not requested, produced, reviewed, or endorsed by Sylvera in any capacity, and no prior relationship of any kind exists. Every claim below is either a passive read of a public page, a public GitHub API/schema call, or a plain HTTP GET against a standard well-known path (with a nonsense-path control to catch soft-404s), no scanning, fuzzing, auth bypass, sign-up, or state-changing call. Captured 2026-07-16; every claim is independently re-runnable.
The whole thing, plainly
We found that Sylvera's own open data standard already has a field built for the exact kind of receipt we produce, and we proved the fit by running our own record through Sylvera's real validator, not just claiming it. This is a courtesy technical note, not sent to Sylvera. The one next step, if any, is entirely ours: file a mapping PR against the open standard's own repo.
Five facts from the public record
Credit-first, because the credit is real. Each fact is reproducible with one command: the capability brief has the exact curl lines and outputs.
CDOP's Unit_Description schema already has our field
Field id 141, retirement_beneficiary: "Entity name on behalf of which the retirement occurred", matches EcoWealth's own "beneficiary ≠ sender" law almost verbatim.
We proved the fit, not just claimed it
Built a real EWP settlement record, ran it through check-jsonschema against CDOP's own live repo schema. First attempt failed one real rule; fixed it; second attempt: ok, validation done.
Sylvera's own site has no agent-discovery layer
llms.txt (the file AI assistants read first), agent-card.json, ai-plugin.json, security.txt, .well-known/x402 all true 404 (credit due): these are honest 404s, not soft-200 traps.
The Assessment API's own docs don't render without JS
docs.sylvera.com is a client-only Vite SPA shell; no public OpenAPI spec or machine-readable schema was found for it.
Pricing is "contact sales" above the free tier
Freemium/Essentials/Enterprise: zero public numeric price anywhere. Gentle contrast, not a knock: our own x402 endpoints publish exact USD-per-call prices, no signup.
The brief, in three pages
Capability brief
An agent's-eye read of Sylvera's data stack
Five evidenced findings: the CDOP field match, our own live validation run, the honest-404 agent-discovery gap, the unrendered API docs, and the pricing-opacity contrast, each with the exact URL, status, and re-check command.
An EWP work receipt, expressed as a valid CDOP record
Act One: the real on-chain shape of a settled, retired EWP work packet. Act Two: that same packet mapped field-for-field into CDOP's Unit_Description schema and validated against Sylvera's own open-source repo tooling, with the real terminal output.
Concept drafts: a field-by-field EWP→CDOP mapping table, a draft /work-cdop-export endpoint concept, an MCP tool schema (the standard AI apps call for live actions), and a short concierge persona for an agent that needs a CDOP-shaped receipt.
EWP contract 0x76c17C…A14B settles real-world ecological labor on Base mainnet: funded work packet → claimed → proof (photo + GPS + signature) → approved → on-chain settlement → carbon retirement through the Klima/Regen rails. Every retirement already carries a beneficiary distinct from the sender, a quantity, and a status: the substance of CDOP's Unit_Description schema, just not yet expressed in CDOP's own field names.
What this brief asks for, and what it doesn't
Not a partnership pitch, not a sales ask. EcoWealth has no relationship with Sylvera and isn't proposing one here: this is a courtesy technical note, shaped as evidence, in case it's ever useful.
If anything moves: the smallest next step is entirely on our own side: publish the EWP→CDOP mapping doc as a real PR against CDOP's open, contribution-welcome GitHub repo (fortnightly maintainer review, per its own governance doc). No Sylvera action required at all.
What's explicitly not being asked: no partnership announcement, no co-marketing, no request that Sylvera change its ratings, pricing, or marketplace mechanics.
Sylvera helped co-author the open standard that already has a home for our kind of receipt. The gap isn't ambition or the standard: it's that nobody has filed the PR yet. We just proved, with their own validator, that we could.