# Carrot Documentation Machine Access
Preferred machine access: connect to the public read-only Carrot Docs MCP server at https://docs.carrot.eco/mcp.
MCP setup guide: https://docs.carrot.eco/en/docs/integrations/getting-started/connect-ai-agent
If MCP is unavailable, use this file as the full machine-readable fallback for published Carrot documentation.
---
# Locale: en
# FAQ
Use this page for quick answers and navigation. For implementation details, continue to
[Integrations](/docs/integrations), [API Reference](/docs/integrations/api), or [Methodologies](/docs/methodologies).
## General [#general]
### What is the Carrot Network? [#what-is-the-carrot-network]
The [Carrot Network](/docs/network) is digital public infrastructure for the resource-efficient, low-carbon circular economy. It encompasses a [standard](/docs/standard), a public credit [registry](/docs/registry), digital Measurement, Reporting and Verification (digital MRV) infrastructure for independent, third-party verification, the [Circular Economy Protocol](/docs/protocol), and a [governance](/docs/network/governance) layer for transparent and traceable decision-making and sharing of network proceeds. Learn more about why Carrot is built as [digital public infrastructure](/docs/network/digital-public-infrastructure).
### How is recycling verified on the Carrot Network? [#how-is-recycling-verified-on-the-carrot-network]
Every batch of waste is tracked as a [MassID](/docs/protocol/mass-ids) — a digital twin that records what the material is, where it came from, and who handled it. At each transfer point, validators confirm the material, creating an unbroken chain of custody from waste generation to certified recycling. This is the digital MRV ([dMRV](/docs/protocol/dmrv)) process.
### Who can participate? [#who-can-participate]
Anyone involved in the recycling supply chain: [Waste Generators, Bin Custodians, Haulers, Processors, and Recyclers](/docs/protocol/supply-chain), and [Network Integrators](/docs/protocol/network-integrators). Each participant earns [rewards](/docs/protocol/rewards-distribution) for their verified contribution.
## Network Governance [#network-governance]
### Is Carrot a company, foundation, or network? [#is-carrot-a-company-foundation-or-network]
The network is stewarded by Carrot Fndn, a Swiss foundation. The Foundation provides institutional stewardship for the standard, registry, methodology compliance, and operational continuity of the network.
### Who governs the network today? [#who-governs-the-network-today]
The Foundation Council governs the network today, with support from advisors and domain contributors. Participation is expected to expand over time through engagement, consultative, and deliberative phases.
### Where do credit purchase proceeds go? [#where-do-credit-purchase-proceeds-go]
Credit purchase proceeds are distributed according to the published [Rewards Distribution Policy](/docs/standard/policies/rewards-distribution). The policy defines participant categories and distribution percentages for each supported waste type.
### What does the Foundation steward? [#what-does-the-foundation-steward]
The Foundation stewards the governance framework for the network, including the standard, registry, methodology compliance, protocol direction, and operational continuity.
### How is Carrot different from a private measurement, reporting, and verification (MRV) platform? [#how-is-carrot-different-from-a-private-measurement-reporting-and-verification-mrv-platform]
Such a private platform usually records and reports data inside one company's product environment. The network is designed as shared market infrastructure: methodology logic, credit traceability, public records, and rewards distribution are organized through a foundation-led model.
## Credits [#credits]
### What are `C-BIOW` and `C-CARB.CH4`? [#what-are-c-biow-and-c-carbch4]
A [`C-BIOW` credit](/docs/protocol/credits#tokenized-recycling-credits-trc) is a Tokenized Recycling Credit (TRC) representing 1 metric ton of certified recycled biowaste. A [`C-CARB.CH4` credit](/docs/protocol/credits#tokenized-carbon-credits-tcc) is a Tokenized Carbon Credit (TCC) representing 1 metric ton of CO₂-equivalent emission reductions through waste diversion. Both are fungible digital credits backed by verified [certificates](/docs/protocol/certificates); TRC and TCC are the broader categories, while `C-BIOW` and `C-CARB.CH4` are the specific registry symbols.
### How are credits purchased? [#how-are-credits-purchased]
Credits are purchased only through Carrot interfaces — buyers do not purchase directly through the underlying registry infrastructure. Individuals can buy environmental impact through the [Carrot Store](https://store.carrot.eco) (store.carrot.eco), which offers intention-based packages that result in retired credits. Organizations use Carrot-provided interfaces that accept Pix and credit/debit card; settlement on the public registry always occurs in USDC, a traceable digital currency, and Carrot handles the conversion. In the current implementation, purchase and [retirement](/docs/protocol/credit-retirement) happen in a single registry transaction: every purchased credit is retired at purchase, so buyers receive a Credit Purchase Receipt and a Credit Retirement Receipt as permanent proof of environmental action rather than a transferable credit balance. Both receipts are viewable through the [Carrot Registry](/docs/protocol/registry) (registry.carrot.eco) or — independently of Carrot's systems — on the underlying public blockchain. See [Credit Purchase](/docs/protocol/credit-purchase) for details.
### Can credits be used for EPR compliance? [#can-credits-be-used-for-epr-compliance]
Yes. Because MassIDs record the geographic origin of waste, credits can be traced to specific municipalities. This makes them suitable for demonstrating compliance with location-specific Extended Producer Responsibility (EPR) mandates.
{/* Prices must match src/data/pricing.ts (canonical source). Update both pricing.ts and hardcoded values here when prices change. */}
## Buying Credits [#buying-credits]
### Is there a minimum purchase volume? [#is-there-a-minimum-purchase-volume]
There is no minimum tonnage or volume commitment. On the [Carrot Store](https://store.carrot.eco) you choose an impact package or collection and contribute any amount at or above its price — the entry package sets the smallest purchase — and the credits retired on your behalf scale with your contribution. For enterprise volume agreements or annual minimum commitments (AMC), contact the Carrot sales team.
### How are `C-CARB.CH4` and `C-BIOW` priced? [#how-are-c-carbch4-and-c-biow-priced]
In the paired sale, each `C-CARB.CH4` is valued at US$ 120.00 and the `C-BIOW` value leg adds US$ 33.53 per `C-CARB.CH4` sold, for a combined reference value of US$ 153.53.
The US$ 33.53 amount is not multiplied by the physical `C-BIOW` quantity; the emission coefficient determines the effective value per `C-BIOW`. See the [Credit Calculator](/docs/standard/guides/credit-calculator) for the open calculation and comparison table.
### What payment methods are accepted? [#what-payment-methods-are-accepted]
Pix and credit/debit card. Settlement on the public registry always occurs in USDC — Carrot handles the conversion, so buyers do not need to hold or send a stablecoin.
### Do I need a blockchain wallet to buy credits? [#do-i-need-a-blockchain-wallet-to-buy-credits]
You don't need to set up or manage a wallet yourself. [MyCarrot](https://my.carrot.eco) is a portal with an intuitive interface — the platform handles the technical steps for you, whichever payment method you choose. Through MyCarrot you can view your impact dashboard, purchase history with certificate details, and audit trails — all in one place.
### How do I use retirement certificates in my ESG report? [#how-do-i-use-retirement-certificates-in-my-esg-report]
Each [credit retirement](/docs/protocol/credit-retirement) generates a permanent, independently verifiable certificate with a complete audit trail that can support ESG reporting. See [Credit Retirement](/docs/protocol/credit-retirement) for details.
## Integration [#integration]
### How do Network Integrators connect? [#how-do-network-integrators-connect]
Network Integrators are third-party software applications that connect to the Carrot Network through the [Carrot API](/docs/integrations/api) after completing the [accreditation](/docs/protocol/network-integrators) process. They submit supply chain data on behalf of their customers and receive a portion of credit purchase rewards. See the [integration guide](/docs/integrations/getting-started/quick-start) to get started.
### What data does the API accept? [#what-data-does-the-api-accept]
Network Integrators submit supply chain event data covering pick-ups, drop-offs, material validations, and other supply chain events. This data creates and updates MassIDs that track waste through the system. See the [event specification](/docs/integrations/reference/event-specification) for details.
### Is there a deadline to submit mass data? [#is-there-a-deadline-to-submit-mass-data]
Yes, and it depends on when the material was recycled: the [methodology framework](/docs/standard/concepts/mvf) only accepts a batch whose Recycled event occurred on or after 1 January of the previous calendar year, in UTC, so the last cycle that can analyze a batch is the one in the year after it was recycled, and data has to reach the network by the end of November of that year. Data can be submitted as the operation happens, and should be. The exact cut-off, what happens between the cut-off and the close of the cycle, and how late submissions are handled are described in [Submission window](/docs/protocol/mass-ids#submission-window).
## Methodologies [#methodologies]
### What is BOLD? [#what-is-bold]
BOLD (Breakthrough in Organics Landfill Diversion) is the family of [methodologies](/docs/methodologies) on the Carrot Network for verifying organic waste diversion. [BOLD Recycling](/docs/methodologies/bold-recycling) verifies organic waste diversion to aerobic composting; [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) verifies methane prevention from composting.
### Can anyone create a methodology? [#can-anyone-create-a-methodology]
The ecosystem accepts methodology proposals, methodology verification frameworks, and third-party dMRV applications for review and approval under the [Carrot dMRV Standard](/docs/standard).
# Glossary
{/* This file is generated by pnpm glossary:sync from .docs/glossary/terms/*.md. Do not edit directly. */}
Key terms used throughout the Carrot Network documentation.
## A [#a]
**Accreditation** — The formal process that verifies a [Recycler](/docs/protocol/supply-chain#the-role-of-the-recycler), [Network Integrator](/docs/protocol/network-integrators), or other participant meets Carrot Network standards.
**Additionality** — A project activity that reduces net GHG emissions below the level that would have occurred without the project (the baseline scenario).
**Advance Market Commitment (AMC)** — A commitment, made before the supply exists, to purchase a defined volume of a verified outcome at a defined price — turning future demand into the certainty that lets suppliers and their financiers invest. The Carrot Network provides the verification, unique recording, and settlement such commitments require; it does not itself run market commitments or act as a buyer. See the [White Paper](/docs/network/white-paper#shaping-markets-not-only-recording-them) and the [RFP Process](/docs/standard/policies/rfp-process).
**Aerobic composting** — A process for producing nutrient-rich compost through aerobic (oxygen-present) decomposition of organic matter. Produces little to no methane compared to anaerobic decomposition in landfills.
**AMS-III.F** — A UNFCCC Clean Development Mechanism methodology for methane reductions from composting (official title: "Avoidance of methane emissions through composting"). The external, validated methodology behind the [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) framework.
**Attribute** — See [Metadata](#metadata). The terms *attribute* and *metadata* are used interchangeably in Carrot documentation to refer to the key-value pairs attached to events.
**Auditor** — An independent, third-party business, organization, or consultant who audits and accredits participants and facilities for the Carrot Network. See [Third-Party Verification](/docs/protocol/third-party-verification).
## B [#b]
**Baseline emissions** — The GHG emissions that would occur if waste were disposed of through standard methods (landfill, dump site) rather than recycled or biologically treated. Used to calculate [emission reductions](/docs/protocol/certificates).
**Bin Custodian** — A supply chain participant (BC) who manages collection bins or drop-off points where Waste Generators deposit recyclable materials. See [supply chain](/docs/protocol/supply-chain).
**Biological treatment** — The processing of organic waste through controlled biological processes that prevent methane emissions from landfill disposal. Includes composting, anaerobic digestion, black soldier fly processing, microbial processing, and other methods. See also [Aerobic composting](#aerobic-composting).
**Biowaste** — Organic waste — food scraps, agricultural residue, and other biodegradable material — diverted from landfill to recycling or [biological treatment](#biological-treatment). Recycled biowaste is the feedstock for Carrot Network recycling credits (see [C-BIOW](#c-biow)); biologically treated biowaste generates [carbon credits](#carbon-credits) from methane reductions. Always written as a single word: *biowaste*.
**Blockchain block explorer** — A third-party web interface for viewing raw on-chain data (transactions, contract calls, event logs) on a public blockchain. Carrot Network transactions can be verified via any blockchain block explorer (e.g. [PolygonScan](https://polygonscan.com/) for Polygon PoS, which Carrot currently uses) without relying on Carrot's infrastructure. Distinct from the Carrot Registry, which combines that on-chain data with platform data (methodology definitions, rule execution, accreditations) for a domain-focused view.
**BOLD (Breakthrough in Organics Landfill Diversion)** — Carrot's product line for organic waste landfill-diversion credits, spanning both families: the carbon unit BOLD Carbon (CH4) Credit (methane-derived — e.g. small-scale composting) + the recycling unit BOLD Recycling Credit. Butterfly symbol = transformation, nods to circular economy's biological + technical cycles. Sorting organic waste at the source unlocks the low-carbon circular economy.
## C [#c]
**C-BIOW** — The credit symbol for [Tokenized Recycling Credit (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc) issued by the [BOLD Recycling](/docs/methodologies/bold-recycling) methodology. 1 credit = 1 metric ton of certified recycled biowaste. Other recycling methodologies may issue TRCs with different symbols.
**C-CARB.CH4** — The credit symbol for [Tokenized Carbon Credit (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc) issued by the [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) methodology (methane reductions through composting). 1 credit = 1 metric ton of CO₂-equivalent emission reductions. Other carbon methodologies may issue TCCs with different symbols.
**CaA** — Carrot Agentic Advisor. An AI layer that identifies opportunities for methodology, data quality, and process improvements across the ecosystem. See [Methodology Ecosystem](/docs/standard/concepts/ecosystem#platform-intelligence-layers).
**CaE** — Carrot Analytic Engine. The evaluation layer of the verification stack — a machine-learning layer designed to analyze dMRV data and verification results, detecting anomalies, inconsistencies, and suspicious patterns. It enhances audit quality but does not certify credits. See [Methodology Ecosystem](/docs/standard/concepts/ecosystem#platform-intelligence-layers).
**Carbon Credits** — Commoditized environmental credits for verified decarbonization work. Traded on voluntary + regulated markets. Carrot's are methane-derived (tCO2e), from diverting biowaste to biological treatment — the "white swans" of waste-derived carbon (vs landfill-gas capture, the "ugly ducklings").
**Carrot dMRV Standard** — The five core principles that every methodology on the Carrot Network must follow: integrity & traceability, additionality & verifiability, standardization & comparability, interoperability & automation, and transparency & auditability. See [Carrot dMRV Standard](/docs/standard).
**Carrot Foundation** — A foundation in Switzerland building the Carrot Network. Mission: to accelerate the transition to a resource-efficient, low-carbon, and inclusive circular economy.
**Carrot Network** — Carrot's digital public infrastructure for the resource-efficient, low-carbon circular economy: shared market rails encompassing the [standard](/docs/standard), the public credit [registry](/docs/registry), [dMRV](/docs/protocol/dmrv) infrastructure for [third-party verification](/docs/protocol/third-party-verification), the [Circular Economy Protocol](/docs/protocol), and Foundation-stewarded [governance](/docs/network/governance). "The Carrot Network" names the whole; the governance layer within it is labelled Governance. Smart contracts support its credit records, reward distribution, and decision traceability.
**Carrot Registry** — The [public interface](/docs/protocol/registry) of Carrot's verification platform at [registry.carrot.eco](https://registry.carrot.eco). Provides a transparent, user-friendly view of environmental data and audit trails — both registry data (MassIDs, certificates, credits, retirement records) and platform data (methodology definitions, rule execution, accreditations). Registry data is also verifiable by anyone via any [blockchain block explorer](#blockchain-block-explorer), without relying on Carrot's infrastructure. The registry function of the Carrot Network is described as the "public credit registry" (lowercase); "Carrot Registry" is the surface itself. Record browsing and verification within it is the Explorer section.
**Carrot Store** — A consumer experience at [store.carrot.eco](https://store.carrot.eco) for purchasing environmental impact. Offers a small set of intention-based contribution packages that result in retired credits — a simple way for individuals to take action without choosing methodologies or tonnage.
**Catalytic Buyer** — Purpose-driven organization or individual willing to act before systems are fully proven; uses purchasing power to catalyze systemic change, unlock supply, and accelerate markets. See [Credit Purchase](/docs/protocol/credit-purchase).
**Category** — The broadest classification level for a document in the [Carrot API](/docs/integrations/api). For supply chain integrations, the category is typically `MassID`. See [Waste Classification](/docs/integrations/reference/waste-classification).
**CDM** — Clean Development Mechanism. A [UNFCCC](/docs/methodologies/ams-iii-f/bold-carbon#scientific-basis) framework that allows emission-reduction projects in developing countries to earn certified emission reduction credits. BOLD Carbon uses CDM Tool 04 v08.1 waste categories to classify waste types for emission factor assignment. See [Supported waste codes](/docs/methodologies/ams-iii-f/bold-carbon#supported-waste-codes).
**Certificate** — A permanent, non-transferable digital record representing a single MassID that has passed methodology verification. Two types: [GasID](/docs/protocol/certificates#gasid) (emission reductions) and [RecycledID](/docs/protocol/certificates#recycledid) (recycled material).
**Chain of custody** — The complete record of every participant who has handled a batch of waste material, from source to certified recycling. Recorded in each [MassID](/docs/protocol/mass-ids).
**Circular economy** — A system where materials never become waste and nature is regenerated. Products and materials are kept in circulation through reuse, refurbishment, remanufacture, recycling, and biological treatment.
**Circularity Credits** — An umbrella term for credits issued across the Carrot Network — all generated credits represent *circularity* (materials kept in use; biowaste diverted from landfill to biological treatment), never "waste management." Two families: **Recycling Credits** (verified recycling work, in tonnes — biowaste + plastic) and **Carbon Credits** (methane-derived, in tCO2e — biowaste biological treatment: composting, biogas/anaerobic digestion, black soldier flies). The biological-treatment carbon credits are the "white swans" of waste-derived carbon — higher value than landfill-gas capture credits ("ugly ducklings") because they turn waste into resource (compost, green power, protein), not just prevent methane.
**CO₂e** — Carbon dioxide equivalent. A standard unit converting all greenhouse gases to carbon dioxide equivalents using Global Warming Potential (GWP). Measured in metric tons (t-CO₂e).
**Cold Start** — A credit collection representing network effect unlocking in a specific geographic location. Named after Andrew Chen's book on network effects. Used in buyer-facing contexts to describe location-specific impact.
**Community Pool** — A discretionary fund (CP), held in USDC, that reinvests value into open-network growth — participant onboarding and expansion, marketing, events, competitive grants, and ecosystem support. It is not a donation fund. The Community Pool is funded by the network's own integrity and incentive mechanisms: the supply chain digitization discount, unredeemed rewards, self-policing penalties, and forfeited collateral. See [Rewards Distribution Policy](/docs/standard/policies/rewards-distribution).
**community-built** — Describes Carrot's infrastructure and platform — built by and for the community. Default usage when describing the system, platform, or differentiation. Distinct from [community-led](#community-led) (governance). Do not use "community-led" when referring to infrastructure.
**community-led** — Describes governance and stewardship — decisions led by the community. Use only for governance contexts (progressive community participation, Foundation stewardship). Distinct from [community-built](#community-built) (infrastructure).
**Credit** — A fungible digital unit representing 1 metric ton of verified environmental impact. Two categories: [TRC](/docs/protocol/credits) (tokenized recycling credits, e.g. `C-BIOW` from BOLD Recycling) and [TCC](/docs/protocol/credits) (tokenized carbon credits, e.g. `C-CARB.CH4` from BOLD Carbon (CH₄)). Each methodology issues credits under its own registry symbol.
**Credit buyer** — An organization or individual that purchases and retires credits to claim verified environmental impact. Credit buyers rely on the registry, certificates, and retirement records to support reporting or compliance claims. See [Credit Retirement](/docs/protocol/credit-retirement).
**Credit retirement** — The permanent removal of credits from circulation. When a buyer retires credits, the credits are irreversibly consumed and a `CreditRetirementReceipt` is issued as permanent, tamper-evident proof. Retired credits cannot be re-sold or re-used. See [Purchasing Credits](/docs/protocol/credit-purchase).
**Crediting system** — The circular economy crediting system encompassing a [standard](/docs/standard) (methodology governance), a public credit [registry](/docs/registry), and [dMRV](/docs/protocol/dmrv) infrastructure for [third-party verification](/docs/protocol/third-party-verification). For a role-by-role map, see [Credit Ecosystem Roles](/docs/protocol/credit-ecosystem-roles).
## D [#d]
**Digital evidence package** — An organized set of data, documents, logs, versions, and validation results produced during dMRV execution; supports audit and governance.
**Digital public goods** — Open-source software, open standards, open data, and open content that are freely reusable and adaptable — the term used by the UN and the Digital Public Goods Alliance. The infrastructure is the rail; digital public goods are the open parts it is made of. The Carrot Network's methodology frameworks, its public credit registry, and its open-source verification code are digital public goods. See [Digital Public Infrastructure](/docs/network/digital-public-infrastructure).
**Digital Public Infrastructure (DPI)** — Digital systems that work as shared, society-wide rails rather than proprietary platforms: foundational, interoperable, inclusive, and publicly accountable. The term is used across the UCL Institute for Innovation and Public Purpose, the UNDP, the World Bank, and the G20; reference cases include India's Aadhaar and UPI, Brazil's Pix, and Estonia's X-Road. The Carrot Network is digital public infrastructure for the resource-efficient, low-carbon circular economy. See [Digital Public Infrastructure](/docs/network/digital-public-infrastructure).
**dMRV** — digital Measurement, Reporting and Verification. The digital execution and evidence layer that runs methodology rules against real-world supply chain data, produces auditable results, and supports independent assurance. See [dMRV](/docs/protocol/dmrv).
**Document** — The root data structure in the [Carrot API](/docs/integrations/api) representing a traceability record. A document stores identity and classification fields ([category, type, subtype](/docs/integrations/reference/waste-classification)); state changes are recorded as appended events on its [timeline](#timeline). Each document receives a unique identifier. See [Core Concepts](/docs/integrations/getting-started/core-concepts).
## E [#e]
**EPR** — Extended Producer Responsibility. An environmental policy that holds producers responsible for managing their products through the entire lifecycle, including post-consumer disposal and recycling.
**ESG** — Environmental, Social, and Governance. A corporate reporting and compliance framework measuring an organization's sustainability practices. Organizations and individuals purchase TRCs and TCCs to meet ESG commitments.
**Event (dMRV)** — An operational occurrence in the methodology flow that requires defined inputs and validations per the [MvF](/docs/standard/concepts/mvf)/[MvA](/docs/standard/concepts/mva).
## F [#f]
**FIFO** — First-In-First-Out. The inventory management method used at processing facilities — the earliest [MassIDs](/docs/protocol/mass-ids) in a facility's inventory are processed and credited first.
**Foundation Treasury** — The Carrot Foundation's operational resources (Foundation Treasury), funded by the digital MRV and Integrity Component of each credit sale. It supports the Foundation's stewardship of the network. See [Rewards Distribution Policy](/docs/standard/policies/rewards-distribution).
## G [#g]
**GasID** — A [certificate](/docs/protocol/certificates) type issued under a carbon methodology that quantifies greenhouse gas emission reductions through waste diversion. Under [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon), GasIDs generate `C-CARB.CH4` credits at issuance; other carbon methodologies may use different symbols.
**Geographic Annex** — A companion document that provides the local specification for every territorial element in a [Methodology Verification Framework (MvF)](/docs/standard/concepts/mvf). Maps local regulations, material classification codes, required documentation, emission factors, and eligibility criteria to the functional requirements declared in the framework. The MvF plus a Geographic Annex forms a complete, implementable specification for a given market. See [MvF — Geographic adaptability](/docs/standard/concepts/mvf#geographic-adaptability).
**Green Premium** — The cost difference between a conventional product or process and its sustainable alternative. Carrot aims to drive down the green premium through incentive alignment and scaled supply.
**GWP** — Global Warming Potential. A measure of how much heat a greenhouse gas traps relative to CO₂. Methane (CH₄) has a GWP of 28 over 100 years.
## H [#h]
**Hauler** — A supply chain participant (H) who transports waste between locations — from collection points to processors or recyclers. May include both local and long-distance haulers. See [supply chain](/docs/protocol/supply-chain).
## I [#i]
**Ibama** — Instituto Brasileiro do Meio Ambiente e dos Recursos Naturais Renováveis (Brazilian Institute of Environment and Renewable Natural Resources). Publishes the [Brazilian List of Solid Waste](https://www.gov.br/ibama/pt-br/assuntos/emissoes-e-residuos/residuos/arquivos/ibama-lista-brasileira-de-residuos-solidos.doc) (Lista Brasileira de Resíduos Sólidos, per IN nº 13/2012), which assigns 6-digit classification codes to waste materials. BOLD Carbon uses these codes for waste classification. See [Supported waste codes](/docs/methodologies/ams-iii-f/bold-carbon#supported-waste-codes).
**Impact Pool** — A fund (IP) that makes pure donations to socio-environmental and circular economy projects in the country where the recycling took place. Its main source is the reward share redirected from Large Business Waste Generators and the discounted half from generators that have not completed onboarding, ensuring credit buyers are not funding rewards to large corporations. See [Rewards Distribution Policy](/docs/standard/policies/rewards-distribution).
## K [#k]
**KYC** — Know Your Customer/Client. The mandatory process of verifying participant identity before network participation.
## M [#m]
**MassID** — A unique, non-transferable digital record created when waste is identified and measured. Records material type, weight, and chain of custody. The foundation of the Carrot Network's verification system. See [MassIDs](/docs/protocol/mass-ids).
**Merkle proof** — A cryptographic method used for privacy-preserving [rewards distribution](/docs/protocol/rewards-distribution), allowing participants to claim rewards without exposing full distribution details in public records.
**Metadata** — Key-value pairs attached to events that provide contextual information about an operational action — for example, date, location, vehicle, operator, or weight measurement. Also called *attributes*. See [Data Formats](/docs/integrations/reference/data-formats).
**Metadata Viewer** — The public tool at [viewer.carrot.eco](https://viewer.carrot.eco) that opens the provenance document behind a MassID, Certificate or receipt record and renders it in the reader's browser. It reads the token's metadata URI from the [smart contract](/docs/protocol/smart-contracts) and fetches the document from IPFS. Its checks are deliberately narrow: schema validation runs only when the viewer build carries the version the record declares, and the on-chain round-trip only when a record is opened by its IPFS reference, pasted or uploaded. Narrower than the [Carrot Registry](/docs/protocol/registry): it shows what one record says, not what the record means in environmental context. See [Metadata Viewer](/docs/protocol/metadata-viewer).
**methodology** — The scientific basis for measuring a specific environmental claim. A methodology is translated into an operational [methodology framework (MvF)](/docs/standard/concepts/mvf), then implemented as an [MvA](/docs/standard/concepts/mva) for digital execution. See [Methodologies](/docs/methodologies).
**methodology execution** — The platform's process of running methodology verification: the [MvA](/docs/standard/concepts/mva) executes the [methodology framework's](/docs/standard/concepts/mvf) rules on supply chain data to produce verified outcomes (MassIDs, certificates). See [Methodology Execution](/docs/protocol/methodology-execution).
**methodology framework** — The operational specification (MvF) that turns a methodology into testable verification requirements, evidence rules, formulas, and outputs. See [MvF](/docs/standard/concepts/mvf).
**methodology rules** — The verification rules defined in a [methodology framework (MvF)](/docs/standard/concepts/mvf) and implemented/executed by the [MvA](/docs/standard/concepts/mva). See [Methodology Execution](/docs/protocol/methodology-execution) and [MvF](/docs/standard/concepts/mvf).
**MvA** — Methodology Verification Application. The deterministic software implementation of a [methodology framework (MvF)](/docs/standard/concepts/mvf) that evaluates submitted data and returns traceable verification results. See [MvA](/docs/standard/concepts/mva).
**MvA Developer** — The engineer who implements methodology frameworks in code (the MvA). See [MvA](/docs/standard/concepts/mva) and the [MvA Developer Guide](/docs/standard/guides/mva-developer-guide).
**MvF** — Methodology Verification Framework. The specification document that defines the rules, calculations, evidence requirements, and verification criteria for a methodology. See [MvF](/docs/standard/concepts/mvf).
**MvF Author** — The specialist who creates methodology frameworks. See [MvF](/docs/standard/concepts/mvf) and the [MvF Author Guide](/docs/standard/guides/mvf-author-guide).
**MyCarrot** — The buyer's portal in the Carrot ecosystem, available at [my.carrot.eco](https://my.carrot.eco). Provides an impact dashboard with accumulated metrics, purchase history with certificate details, and audit trails linked to the [Carrot Registry](/docs/protocol/registry). Requires no blockchain knowledge. See [Purchasing Credits](/docs/protocol/credit-purchase).
## N [#n]
**Network Developer** — An ecosystem role that fosters credit and traceability projects by recruiting and onboarding participants, coordinating their accreditation process, and submitting supporting data to Carrot. A Network Developer does not approve participants and receives no protocol rewards. See [Credit Ecosystem Roles](/docs/protocol/credit-ecosystem-roles#network-developer).
**Network Integrator** — A third-party software application or platform that connects real-world operations to the Carrot Network by submitting supply chain data through the API. Network Integrators are the data bridge between operational systems and Carrot's dMRV layer; they are distinct from the physical supply chain participants who handle material. See [Network Integrators](/docs/protocol/network-integrators).
## P [#p]
**PAYT** — Pay-As-You-Throw. A waste management pricing model where households and businesses pay for waste collection based on the amount they generate — incentivizing source sorting and recycling. See [The Solution](/docs/protocol/the-solution).
**Processor** — A supply chain participant (P) who sorts, accumulates, or pre-processes waste materials before they reach a certified Recycler. See [supply chain](/docs/protocol/supply-chain).
**Program Owner** — An ecosystem role that leads the development of a credit program by coordinating its methodology, [Methodology Verification Framework (MvF)](/docs/standard/concepts/mvf), [Methodology Verification Application (MvA)](/docs/standard/concepts/mva), and proposed rewards policy. A Program Owner does not approve its own program, hold its credits, or receive protocol rewards. See [Credit Ecosystem Roles](/docs/protocol/credit-ecosystem-roles#program-owner).
**Progressive community participation** — The Carrot Foundation's approach to gradually expanding community participation in ecosystem governance as the network matures, through three phases: engagement, consultative, and deliberative. See [Governance](/docs/network/governance).
**Proof-of-Authority (PoA)** — The trust mechanism in the Carrot Network that ensures data integrity through three layers: self-policing via economic incentives (participants lose rewards if data is fraudulent), facility accreditation conducted by independent third-party auditors, and network oversight by the [Carrot Foundation](/docs/network/the-foundation) which can suspend or disqualify bad actors. See [dMRV](/docs/protocol/dmrv#proof-of-authority-details).
**Proof-of-Physical-Work (PoPW)** — Evidence that real-world recycling work was performed, recorded through supply chain events and validated at each transfer point in the supply chain.
**Proof-of-Provenance (PoP)** — Evidence that tracks the origin and journey of waste materials from source to certified recycling, recorded in [MassIDs](/docs/protocol/mass-ids).
**Protocol** — A domain-specific set of technological and financial rules that groups related methodologies and their economics within the Carrot Network. The first protocol covers circular economy (reverse logistics, recycling, biological treatment).
## R [#r]
**Recycle-to-Earn** — The incentive model in which every verified [supply chain](/docs/protocol/supply-chain) participant earns a share of the [credit](/docs/protocol/credits) sale proceeds for their role in the recycling process. Proceeds from credit purchases are [distributed](/docs/protocol/rewards-distribution) across the underlying MassIDs proportional to the value of the credits drawn from each, then split by participant role.
**RecycledID** — A [certificate](/docs/protocol/certificates#recycledid) type issued under a recycling methodology that verifies a specific quantity of waste was certified recycled. Under [BOLD Recycling](/docs/methodologies/bold-recycling), RecycledIDs generate `C-BIOW` credit tokens; other recycling methodologies may use different symbols.
**Recycler** — A processor that has been accredited to perform certified recycling for a specific waste type. Only accredited Recyclers can trigger credit generation. See [supply chain](/docs/protocol/supply-chain#the-role-of-the-recycler).
**Registry (Carrot's role)** — The registry issues, records, and retires environmental credits and maintains durable public records of their lifecycle. The registry infrastructure provides public, permanent, and independently verifiable records, distinct from the [Standard](/docs/standard) role — Carrot holds both. See [The Registry](/docs/registry)
**RFP** — Request for Proposals. The formal mechanism through which Carrot sources new contributions to the ecosystem — from methodology development (MvF + MvA) to infrastructure projects and technology solutions. Each RFP defines scope, eligibility criteria, evaluation matrix, timeline, and deliverables. Six types (A--F) cover different contribution needs: problem-solving, AMC projects, MvF builds, MvA builds, technology solutions, and open calls. See the [RFP Process](/docs/standard/policies/rfp-process) for the full lifecycle and type descriptions, and the [RFP Participation Guide](/docs/standard/guides/rfp-participation-guide) for evaluation criteria and submission instructions
## S [#s]
**Smart contracts** — Self-executing blockchain programs that record and automate Carrot Network operations such as registry record creation, reward distribution, credit purchases, and credit retirement. See [Smart Contracts](/docs/protocol/smart-contracts).
**Soulbound** — A technical property of some blockchain records meaning they cannot be transferred between accounts. The Carrot Network uses non-transferable registry records for MassIDs, certificates, and receipts so their audit trail remains permanent.
**Standard (Carrot's role)** — Carrot acts as a standards body for domains where no established global standard exists — for [BOLD Recycling](/docs/methodologies/bold-recycling), Carrot is the standard. For domains with established standards (e.g. carbon under UNFCCC AMS-III.F), Carrot provides dMRV infrastructure and registry while the methodology framework references the external standard. The [Carrot dMRV Standard](/docs/standard) applies to all methodologies on the network. Distinct from the [Registry](/docs/registry) role — Carrot holds both. See [The Standard](/docs/standard).
**Subtype** — The most specific classification level for a [document](#document), refining the [type](#type). For example, within type `Organic`, subtypes include `Food, Food Waste and Beverages`, `Garden, Yard and Park Waste`, `Industrial Sludge`. Accepted subtypes depend on the methodology. See [Waste Classification](/docs/integrations/reference/waste-classification).
**Supply chain** — The network of participants and handoffs that moves material from waste generation through collection, transport, processing, and certified recycling, with each transfer recorded for traceability and verification. See [supply chain](/docs/protocol/supply-chain).
## T [#t]
**TCC (`C-CARB.CH4`)** — Tokenized Carbon Credit. A fungible credit representing 1 metric ton of CO₂-equivalent emission reductions through waste diversion. The registry symbol `C-CARB.CH4` is used for TCCs issued by the [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) methodology (methane); other carbon methodologies may issue TCCs with different symbols. See [credits](/docs/protocol/credits#tokenized-carbon-credits-tcc).
**Third-Party Verification** — The practice of using independent third-party entities (VVBs, auditors) to validate methodology compliance, facility accreditation, dMRV evidence packages, and credit integrity. Third-party verification is independent from Carrot's platform operations and uses Carrot's dMRV records as auditable evidence.
**Timeline** — The chronologically ordered sequence of events recorded on a [document](#document), representing the full operational history of a mass from origin to final destination. Visible in the [Carrot Registry](/docs/protocol/registry).
**Tracking ID** — The unique public identifier assigned to each [document](#document) in the Carrot platform, used to look up the record in the [Carrot Registry](/docs/protocol/registry).
**TRC (`C-BIOW`)** — Tokenized Recycling Credit. A fungible credit representing 1 metric ton of certified recycled material. The registry symbol `C-BIOW` is used for TRCs issued by the [BOLD Recycling](/docs/methodologies/bold-recycling) methodology; other recycling methodologies may issue TRCs with different symbols. See [credits](/docs/protocol/credits#tokenized-recycling-credits-trc).
**Type** — The mid-level classification for a [document](#document), identifying the primary material or process class (e.g. `Organic`, `Plastic`, `Paper`, `Glass`). See [Waste Classification](/docs/integrations/reference/waste-classification).
## U [#u]
**USDC** — USD Coin. A traceable digital currency pegged 1:1 to the US dollar, used in the Carrot Network for credit purchases and [rewards distribution](/docs/protocol/rewards-distribution). Provides participants with stable value without market price volatility.
## V [#v]
**Validator** — The receiving party in a material transfer who confirms the content (weight, quality, source) and updates the [MassID](/docs/protocol/mass-ids). In most supply chain events, the receiver acts as the Validator. See [dMRV](/docs/protocol/dmrv#validators-and-supply-chain-events).
**Vault** — The smart contract that holds all non-transferable records (MassIDs, certificates, receipts) and credit inventory on behalf of the network. See [Smart Contracts](/docs/protocol/smart-contracts).
**VVB** — Validation/Verification Body. An independent, third-party entity that provides external assurance for the Carrot ecosystem — from methodology validation to evidence review. See [Third-Party Verification](/docs/protocol/third-party-verification) for full scope and responsibilities.
## W [#w]
**Waste Generator** — A supply chain participant (G) — the person or business that produces waste. Identifying the Waste Generator in the [chain of custody](#chain-of-custody) is critical: when it is absent, discounted [payouts](/docs/protocol/rewards-distribution) apply to the chain. When it is present, its own share is still halved if it is a large business or has not completed onboarding, and the discounted half goes to the Impact Pool. See [supply chain](/docs/protocol/supply-chain).
**Waste Manager** — A supply chain participant (WM) contracted by a [Waste Generator](#waste-generator) to coordinate waste destination without taking physical custody of the material. For organic waste, a Waste Manager becomes eligible for its 4% share only after both parties confirm their relationship. See [supply chain](/docs/protocol/supply-chain#waste-manager).
## Z [#z]
**Zero Waste** — The conservation of all resources by means of responsible production, consumption, reuse, and recovery of products, packaging, and materials without burning and with no discharges to land, water, or air that threaten the environment or human health. Goal: reduce waste to landfills by more than 90%.
# Registry
## What is a registry? [#what-is-a-registry]
A registry is the system that issues [environmental credits](/docs/protocol/credits), assigns each credit a unique identifier, tracks ownership changes, and records retirements. Its core function is preventing double counting — ensuring the same environmental benefit cannot be claimed by more than one buyer.
For how the registry relates to standards, methodologies, digital Measurement, Reporting and Verification ([dMRV](/docs/protocol/dmrv)), independent assurance, and buyers,
see [Credit Ecosystem Roles](/docs/protocol/credit-ecosystem-roles).
## How Carrot's registry works [#how-carrots-registry-works]
Credits on Carrot are issued as digital assets in the public registry. Each credit carries a tamper-evident record that links the physical event that originated it — a verified mass of material collected, sorted, or processed — through issuance and purchase to its eventual retirement.
This record is publicly accessible: anyone can confirm a credit's issuance, ownership history, and retirement on the public ledger without Carrot's cooperation. Participant identities in the provenance record are published as hashes rather than names, and the verification results behind a credit are held by the platform — see [Carrot Registry](/docs/protocol/registry) for what is on-chain and what is platform-held.
## What the registry covers [#what-the-registry-covers]
The registry is the home for the credit lifecycle once verified environmental outcomes are ready to become market-facing assets. It covers:
* **Credit issuance** — RecycledID and GasID certificates back fungible credits such as Recycling Credits and Carbon Credits, respectively.
* **Fungible credit tracking** — Credit balances are tracked by certificate so available, purchased, and retired amounts cannot exceed the verified backing amount.
* **Purchase records** — Credit purchases create permanent records that connect buyers, payment, certificates, and purchased amounts.
* **Retirement records** — Credit retirement permanently removes the claimed credit amount from circulation and creates a permanent receipt for the environmental claim.
* **Account and custody flows** — Buyer and participant accounts interact with credit balances, receipts, and settlement flows while non-transferable evidence remains permanently anchored to the registry infrastructure.
* **Settlement layer** — Purchase and retirement flows connect payment, inventory allocation, rewards distribution, and permanent audit records.
The registry does not decide whether a physical activity qualifies for credit issuance. That decision comes from approved methodology framework criteria executed through dMRV. The registry records the resulting credit lifecycle: issuance, ownership-related activity, purchase, retirement, and the receipts that make those actions auditable.
## Why is the registry built this way? [#why-is-the-registry-built-this-way]
The registry runs on blockchain infrastructure. Three properties of that design matter directly to credit buyers:
* **Public and permanent** — Credit records exist on a public ledger, not a private database controlled by a single organization. The data persists regardless of what happens to any individual company or service.
* **Independently verifiable** — Any auditor, regulator, or buyer can confirm the integrity of a credit — its issuance, ownership history, and retirement status — without requiring Carrot's cooperation or access to proprietary systems.
* **Programmable** — [Smart contracts](/docs/protocol/smart-contracts) hold credit sale proceeds and release each [supply chain](/docs/protocol/supply-chain) participant's share against a cryptographic proof of their committed allocation. What each participant is owed is fixed on-chain at the moment of sale, not decided afterwards.
For why Carrot builds this as [digital public infrastructure](/docs/network/digital-public-infrastructure), see the Network section.
## Registry, Standard, and Third-Party Verification [#registry-standard-and-third-party-verification]
Carrot fulfills three distinct functions within its ecosystem. The **registry** issues and tracks credits. [The **standard**](/docs/standard) governs the program and [methodologies](/docs/methodologies) that determine how environmental benefits are measured and which activities qualify for credit issuance. [**Third-party verification**](/docs/protocol/third-party-verification) ensures that every level of the ecosystem — from facility audits to automated dMRV execution — is validated by third parties.
These functions are complementary but separate. The registry is infrastructure — it must be reliable, transparent, and tamper-resistant. The standard is governance — it must be scientifically rigorous and operationally enforceable. Third-party verification is assurance — it must be performed by parties independent from Carrot's operations. Carrot operates the registry and governs methodology quality through the [Carrot dMRV Standard](/docs/standard); third-party verification is conducted by external, independent auditors and [Validation/Verification Bodies (VVBs)](/docs/glossary#vvb).
The registry is powered by a set of smart contracts that manage the full credit lifecycle — from issuance to retirement. Each step in the lifecycle is recorded on-chain, creating a complete and auditable trail for every credit issued.
For deeper coverage of individual components, see:
* [Credits](/docs/protocol/credits) — credit types and structure
* [Registry Record Creation](/docs/protocol/on-chain-minting) — how verified physical activity becomes a registry credit record
* [Credit Retirement](/docs/protocol/credit-retirement) — how credits are permanently taken out of circulation
* [Smart Contracts](/docs/protocol/smart-contracts) — the contracts that govern issuance, transfer, and retirement
# Methodologies
## Overview [#overview]
Methodologies on the Carrot Network define how environmental impact is measured, reported, and verified through digital Measurement, Reporting and Verification (digital MRV). Each approved methodology entry targets a specific environmental domain and is structured in three layers:
1. **Methodology** — The validated scientific basis approved for use on the network.
2. **[Methodology Verification Framework (MvF)](/docs/standard/concepts/mvf)** — A structured specification that translates the methodology into concrete verification rules, formulas, and data requirements.
3. **[Methodology Verification Application (MvA)](/docs/standard/concepts/mva)** — Open-source software that implements the MvF as executable rule processors. Each rule evaluates [MassID](/docs/protocol/mass-ids) documents and returns a PASSED, FAILED, or REVIEW\_REQUIRED result with an explanation.
This three-layer architecture enables digital MRV ([dMRV](/docs/protocol/dmrv)) at scale: methodologies define *what* to verify, frameworks define *how* to verify it, and applications execute the verification logic automatically.
## Approved methodologies and frameworks [#approved-methodologies-and-frameworks]
Carrot approves methodologies, methodology verification frameworks, and third-party dMRV applications for use on the Carrot Network. The methodology provides the validated scientific basis; the framework translates that basis into operational criteria; and the application executes those criteria in code.
Approval covers the full package: the scientific basis, the operational framework, and the executable application. This keeps responsibility with the contributor while giving Carrot a clear review path for quality, lifecycle, and network fit.
## Active methodologies [#active-methodologies]
| Approved entry | Approved basis | Credit | Registry code | Description |
| -------------------------------------------------------------- | -------------------------------------- | ------------------------------------------------------------- | ------------- | ---------------------------------------------------- |
| [BOLD Recycling](/docs/methodologies/bold-recycling) | Approved methodology/framework | [TRC](/docs/protocol/credits#tokenized-recycling-credits-trc) | `C-BIOW` | Organic waste diversion from landfills to composting |
| [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) | Approved framework backed by AMS-III.F | [TCC](/docs/protocol/credits#tokenized-carbon-credits-tcc) | `C-CARB.CH4` | Methane reductions through composting |
## Open ecosystem [#open-ecosystem]
All methodology rules are open source under the LGPL-3.0 license. Anyone can audit the verification logic, propose improvements, or submit methodology proposals, methodology verification frameworks, and third-party dMRV applications for review and approval under the shared infrastructure.
* **Source code**: [github.com/carrot-foundation/methodology-rules](https://github.com/carrot-foundation/methodology-rules)
* **Governance**: Managed by the [Carrot Foundation](/docs/network/the-foundation) with progressive expansion of community participation.
* **Shared infrastructure**: Methodologies reuse common rule processors. The majority of rules are shared across all active methodologies.
## Learn more [#learn-more]
* **[MvF](/docs/standard/concepts/mvf)** — How Methodology Verification Frameworks are structured.
* **[MvA](/docs/standard/concepts/mva)** — How methodology rules are implemented as executable code.
* **[MvF Author Guide](/docs/standard/guides/mvf-author-guide)** — How to write a Methodology Verification Framework.
* **[MvA Developer Guide](/docs/standard/guides/mva-developer-guide)** — How to implement methodology rules in code.
[Learn about dMRV](/docs/protocol/dmrv) · [Learn about the Carrot dMRV Standard](/docs/standard)
# Governance
## Immutable purpose [#immutable-purpose]
The [Carrot Foundation](/docs/network/the-foundation) exists to build the low-carbon and inclusive circular economy. This purpose is recorded in public Foundation records and is binding under the Foundation's statutes: ordinary governance decisions, leadership transitions, and ecosystem changes cannot override it. The rules, [methodology frameworks (MvFs)](/docs/standard/concepts/mvf), and operational governance of the [Carrot Network](/docs/network) are expected to remain aligned with this commitment.
## Stewardship model [#stewardship-model]
The Foundation acts as steward of the Carrot Network — not as its owner. Ownership implies discretion over the asset; stewardship implies obligation to the mission. The Foundation Council can evolve how the ecosystem operates, but ordinary governance cannot override the purpose the ecosystem exists to serve.
This is the current trust model: a named accountable institution stewards the network today, and that stewardship is constrained by purpose, public records, versioned rules, and auditable system design.
## Governance by architecture [#governance-by-architecture]
Carrot's governance model is designed so accountability does not depend only on trust in current leadership or private system access. Public-value governance cannot rest on values language alone: the network uses Foundation stewardship, public records, versioned rules, inspectable methodology logic, digital MRV ([dMRV](/docs/protocol/dmrv)) evidence, independent assurance, traceable credit data, and published reward mechanics so decisions and outcomes can be reviewed after the fact.
This does not replace institutional governance or independent review. It makes governance more accountable by making Foundation-led decisions, methodology changes, verification outputs, assurance evidence, credit records, and reward mechanics reviewable against the rules that produced them.
This governance architecture is part of why the Carrot Network is built as [digital public infrastructure](/docs/network/digital-public-infrastructure), not as a private measurement platform.
## How the ecosystem is governed today [#how-the-ecosystem-is-governed-today]
The [Carrot Foundation](/docs/network/the-foundation) is responsible for governance of the network and protocol layer — including standard direction, registry stewardship, methodology compliance, protocol development, operational continuity, and resource allocation.
Participants, integrators, methodology contributors, auditors, and applications operate within the network under their own roles and responsibilities. Their participation informs the ecosystem, but it does not mean that control has already moved away from the Foundation.
Decisions are made by the Foundation Council, composed of founding members and advisors with experience in product, technology, operations, environment, legal, and finance. This structure provides a clear accountable body during the current stage of development, while allowing evidence, feedback, and domain expertise from the ecosystem to shape governance decisions.
The Foundation's authority remains bounded by the public purpose and by the inspectable rules, evidence records, and assurance processes that other parties can review.
### Current decision responsibilities [#current-decision-responsibilities]
| Decision area | Current responsibility | Public accountability and participation path |
| ------------------------------------------- | ---------------------- | ----------------------------------------------------------------------------------------------------------- |
| Foundation purpose and stewardship | Foundation Council | Purpose is anchored in public Foundation records; governance can evolve around it |
| Protocol and standard direction | Foundation Council | Structured input from advisors, MvF Authors, MvA Developers, integrators, auditors, and active participants |
| Methodology approval and evolution | Foundation-led process | Evidence and recommendations from MvF Authors, MvA Developers, auditors, and domain experts |
| Operational compliance and evidence quality | Foundation-led process | Data quality review, evidence review, audit trails, and escalation support from qualified participants |
| Participation model | Foundation Council | Current input channels can expand only with documented role criteria, records, and safeguards |
## Progressive community participation [#progressive-community-participation]
As the ecosystem matures and the participant base grows, the Foundation will progressively expand participation mechanisms. This is a participation path, not a claim that control has already moved away from the Foundation. The goal is to move from structured input toward defined responsibilities for qualified contributors, without reducing evidence quality or auditability.
This transition follows three phases:
### Engagement [#engagement]
Open, structured participation in discussions, feedback, documentation review, and technical alignment. Contributors build shared vocabulary and evaluation standards with the existing ecosystem community.
### Consultative [#consultative]
The community produces structured technical analyses and recommendations that support Foundation-led curation and lifecycle decisions. This includes identification of auditability gaps and recommendations for improving methodology frameworks and verification applications.
### Deliberative [#deliberative]
Qualified contributors may take on defined governance responsibilities only when the relevant roles, eligibility criteria, records, and safeguards are documented. This phase should be introduced only with enough evidence quality, auditability, and continuity protections to preserve trust in the network.
The criteria for participation levels and responsibilities will be documented before they are relied on for governance.
## Integrity safeguards [#integrity-safeguards]
Even as community participation grows, the Carrot Foundation maintains a fallback stewardship role to preserve transparency, reliability, and process continuity. This includes:
* Preservation and versioning of governance and methodology records so changes can be reviewed
* Evidence packages that remain intact and queryable regardless of who makes the decision
* Public credit and reward records that remain independently reviewable
* Response mechanisms for integrity risks
Governance evolution and evidence integrity move together. Changes to decision-making processes do not reduce the auditability of outcomes — decisions, methodology changes, and verification results remain explainable and auditable.
## Compliance and auditability [#compliance-and-auditability]
Regardless of the governance structure, the Carrot Network is designed to make the basis for credit outcomes inspectable:
* The verification code ([MvA](/docs/standard/concepts/mva)) is open source (LGPL-3.0) and publicly inspectable
* Public, final records, including [MassIDs](/docs/protocol/mass-ids), [Certificates](/docs/protocol/certificates), credits, and retirement receipts, are recorded on public blockchain infrastructure
* Rule execution and verification outputs remain inspectable through the [Carrot Registry](/docs/protocol/registry) and evidence records
* Independent assurance remains available through [third-party verification](/docs/protocol/third-party-verification) of facilities, frameworks, dMRV evidence, and assurance processes
Transparency does not depend on today's governance structure alone — it is built into the architecture of the system.
The governance model builds on two foundational layers:
* **[The Foundation](/docs/network/the-foundation)** — Mission, founding team, and the council structure that guides ecosystem decisions.
* **[Blockchain security](/docs/protocol/smart-contracts)** — How on-chain records, immutability, and public verifiability provide the infrastructure that makes governance auditable.
Governance defines who decides. Versioned governance and methodology records support decision auditability, while public on-chain records provide verifiability for credit infrastructure records.
# The Network
## Purpose [#purpose]
The Carrot Network exists for a stated purpose, defined in the [Carrot Foundation](/docs/network/the-foundation)'s Deed: **to build the low-carbon and inclusive circular economy**.
Governance decisions, protocol rules, and operational processes within the network are expected to align with this purpose. The network is not a product to be optimized for extraction — it is infrastructure designed to remain focused on its mission across time.
That is what makes the network *public* infrastructure — governed to serve the mission rather than as a private product optimized for extraction. [Why the Carrot Network is digital public infrastructure →](/docs/network/digital-public-infrastructure)
## Accountability by design [#accountability-by-design]
The Carrot Network includes a technology-enabled governance layer for its shared market infrastructure. Deterministic registry software supports durable credit records and reward mechanics, while governance accountability comes from Foundation stewardship, public records, versioned methodology logic, digital Measurement, Reporting and Verification ([dMRV](/docs/protocol/dmrv)) evidence, [independent assurance](/docs/protocol/third-party-verification), and [Carrot Registry](/docs/protocol/registry) traceability. The network is designed to reduce abuse risk through visibility, accountability, and shared rules.
## Why this is infrastructure [#why-this-is-infrastructure]
The network provides shared market rails for environmental credit markets: methodology rules, evidence records, credit traceability, reward distribution, and governance processes that multiple participants can use. It is designed to coordinate a market, not to operate as a single private project.
This infrastructure role matters because recycling and biological treatment involve many independent actors across the [supply chain](/docs/protocol/supply-chain). [Waste Generators](/docs/protocol/supply-chain), [Haulers](/docs/protocol/supply-chain), [Processors](/docs/protocol/supply-chain), [Recyclers](/docs/protocol/supply-chain), [Network Integrators](/docs/protocol/network-integrators), [Methodology Verification Framework (MvF) Authors](/docs/standard/concepts/mvf), [Methodology Verification Application (MvA) Developers](/docs/standard/concepts/mva), auditors, and buyers need shared rules for how environmental work is recorded, evaluated, and rewarded.
## Why a foundation? [#why-a-foundation]
A foundation structure organizes the network around a stated purpose rather than shareholder ownership. This structure supports institutional stewardship for the standard, registry, methodology compliance, and operational continuity of the network as it grows.
## Public-value characteristics [#public-value-characteristics]
This public-value orientation comes from several design choices working together:
* **Foundation stewardship** — the Foundation is organized around the low-carbon, inclusive circular economy and stewards the standard, registry, methodology compliance, and operational continuity.
* **Progressive participation path** — integrators, methodology contributors, auditors, and active network participants can contribute to the network's evolution as governance matures.
* **Inspectable methodology logic** — methodology frameworks and applications define how claims are evaluated and preserve the rule versions behind each outcome.
* **dMRV evidence** — methodology execution creates evidence records that connect physical circular economy work to credit eligibility.
* **Independent assurance** — third-party auditors and [Validation/Verification Bodies (VVBs)](/docs/glossary#vvb) review facilities, frameworks, dMRV evidence, and assurance processes.
* **Durable public records** — final credit records are kept on a public, immutable registry, can be independently verified by anyone, and can be reused by interoperable systems.
* **Reward sharing** — credit purchase proceeds are distributed according to published rewards policies for the relevant supply chain and methodology roles.
Together, these characteristics are what make the Carrot Network [digital public infrastructure](/docs/network/digital-public-infrastructure) for the resource-efficient, low-carbon circular economy.
## Stakeholders and governance [#stakeholders-and-governance]
The network brings together diverse stakeholders — waste management operators, recyclers, credit buyers, methodology authors, auditors, and technology integrators — under a shared governance framework. The [Carrot Foundation](/docs/network/the-foundation) stewards this framework, governing methodology approval, protocol development, operational compliance, and resource allocation.
As the ecosystem matures, the Foundation will progressively expand participation mechanisms, enabling active contributors to have a voice in the protocol's evolution. The network's responsibility extends to governance over domain-specific protocols, starting with the [Circular Economy Protocol](/docs/protocol).
## Why the registry is built this way [#why-the-registry-is-built-this-way]
The registry's final records are anchored to public blockchain infrastructure because that gives them durability, independent verification, auditability, and interoperability. It is not the source of governance authority: methodology rules, independent review, and Foundation-led governance processes remain the authority for what qualifies.
## Learn more [#learn-more]
Why the Carrot Network is digital public infrastructure — and how it is governed for the common
good
How decisions are made within the Carrot Network
The Carrot Foundation's role, structure, and purpose
The full argument: market formation, the public-governance test, funding, and safeguards
# The Foundation
## The Carrot Foundation [#the-carrot-foundation]
The Carrot Foundation is the guardian of the Carrot Network — responsible for the development of the [standard](/docs/standard) and [registry](/docs/registry), methodology compliance, and operational continuity of the network.
The Foundation is governed by a Council that guides strategic direction and ensures the ecosystem evolves responsibly and auditably. As the network grows, participation will be progressively expanded through the [progressive community participation](/docs/network/governance#progressive-community-participation) path described on the governance page.
This purpose-bound stewardship is part of what makes the Carrot Network [digital public infrastructure](/docs/network/digital-public-infrastructure) rather than a private platform.
## Mission [#mission]
To accelerate the transition to a resource-efficient, low-carbon, and inclusive circular economy.
## Vision [#vision]
We believe a low-carbon, circular future can only be achieved through collaboration, supported by shared incentives and transparent systems. The Foundation's target is to help scale global recycling rates from less than 18% to more than 90% by 2040.
## Legal form and purpose [#legal-form-and-purpose]
Carrot Fndn is a Swiss foundation under Article 80 et seq. of the Swiss Civil Code, with its registered seat in Zug, Switzerland. It was constituted in October 2023 and is listed in the Swiss commercial register under UID `CHE-152.448.302` and Handelsregister number `CH-170.7.001.078-2`.
| Field | Public record |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------- |
| Legal form | Swiss foundation |
| Registered seat | Zug, Switzerland |
| Constitution | October 2023 |
| UID | `CHE-152.448.302` |
| Handelsregister number | `CH-170.7.001.078-2` |
| Supervision | Federal foundation supervision in Switzerland; public registry entries list `Eidg. Departement des Innern, in Bern` |
In plain English, the Foundation's public purpose is to develop and support open software architectures that no single party controls, the Carrot Protocol, and applications that use the protocol to support more sustainable resource management.
The public registry records the Foundation's formal purpose in German:
> Der Zweck der Stiftung ist die Entwicklung und Förderung von neuen Technologien und Applikationen, insbesondere in den Bereichen von neuen offenen und dezentralisierten Softwarearchitekturen. Im Vordergrund - aber nicht ausschliesslich - steht dabei die Entwicklung und Förderung des so genannten Carrot Protokolls und der entsprechenden Technologien, sowie die Förderung und Unterstützung von Applikationen unter Anwendung des Carrot Protokolls. Mit der Entwicklung und der Förderung des Carrot Protokoll strebt die Stiftung neben anderen Teilbereichen die Förderung der Nachhaltigkeit der Gesellschaft im Umgang mit den natürlichen Ressourcen an, insbesondere durch eine bessere Ressourcenverwaltung, um die natürlichen Ressourcen zu erhalten, deren Nutzung zu optimieren und Abfall und Verschmutzung zu reduzieren.
This is the original public-record wording; it is not an official legal translation.
Federal foundation supervision is administered by the Eidgenössische Stiftungsaufsicht (ESA) / Federal Supervisory Authority for Foundations, which is attached to the General Secretariat of the Federal Department of Home Affairs.
This legal form matters because the Foundation is organized around a stated purpose rather than shareholder ownership. Its role is to steward the standard, registry, methodology compliance, and operational continuity of the network in service of that purpose.
Public registry and supervisory references: [Moneyhouse](https://www.moneyhouse.ch/de/company/carrot-fndn-13252793071), [Wirtschaftsregister](https://www.wirtschaftsregister.ch/uid.cfm?firma=Carrot-Fndn\&id=CHE-152.448.302), and [ESA](https://www.esa.admin.ch/).
## Council Members [#council-members]
**[Ian McKee](https://www.linkedin.com/in/ianmckee10/) — Founder & President**
Formerly at Goldman Sachs Sales & Trading, 3x Tech Founder with more than 15 years in sustainability. Technology advisor to the Zero Waste International Alliance and an Accredited Professional for TRUE Zero Waste & LEED Certification.
**[Marcelo Doria](https://www.linkedin.com/in/marcelodoria/) — Founder & Vice President**
Serial entrepreneur with experience in media production, sports business, advertising and big data. Built his first company in college. Brought Global X-Games to Brazil, won best film at Rio.
**[Silvan Andermatt](https://www.linkedin.com/in/silvanandermatt/) — Council Member**
Serial entrepreneur and advisor to blockchain and FinTech companies. Expert in Swiss Foundation management with a passion for sustainability. Masters in Law and an MBA with advanced studies in Blockchain and FinTech.
## Advisory committees [#advisory-committees]
The Foundation convenes advisory committees in five key areas to guide ecosystem development:
* **People & Governance** — Inclusion, equity, community building, and engagement
* **Environment** — Closed-loop resource management, ecosystem health, GHG reduction
* **Economics & Finance** — ESG, EPR, capital management, emerging business models
* **Legal** — Environmental law, commodities, policy advocacy
* **Technology** — Security, AI, IoT, blockchain
For the current list of advisors, visit [carrot.eco](https://www.carrot.eco/).
# Integration Overview
Integrations connect your platform to the [Carrot Network](/docs/protocol/how-it-works) so that
[Network Integrators](/docs/protocol/network-integrators) can submit supply chain traceability data through
the [Carrot API](/docs/integrations/api). Each document represents a real-world traceability record — such as a
[MassID](/docs/protocol/mass-ids) tracking a waste batch through the
[supply chain](/docs/protocol/supply-chain) — built as an immutable event timeline verified by the
digital Measurement, Reporting and Verification ([dMRV](/docs/protocol/dmrv)) process.
This section covers the practical onboarding flow, implementation guides, and shared reference data you
need before [methodology](/docs/methodologies)-specific rules are applied.
## For AI agents [#for-ai-agents]
If you use Claude, Cursor, Codex, or another MCP client to answer questions from Carrot Docs, prefer the public read-only Carrot Docs MCP server at `https://docs.carrot.eco/mcp`. It gives agents search, document retrieval, glossary lookup, and related-document navigation over published docs.
Start with [Connect Your AI Agent](/docs/integrations/getting-started/connect-ai-agent). For clients without MCP support, use [/llms.txt](/llms.txt) or [/llms-full.txt](/llms-full.txt) as machine-readable fallbacks.
## Key concepts [#key-concepts]
Before diving into the API, three ideas shape every integration:
* **Documents and events** — A [document](/docs/integrations/api/documents) is the root record for a traceability flow (e.g., a MassID tracking a waste batch). All state changes are represented by [events](/docs/integrations/api/events) appended to the document's timeline — there are no update or delete endpoints.
* **Immutability** — The platform uses an event-sourced model: each submission is appended, and current state is derived from the event log. If you need to correct a mistake, cancel the document with a `CANCEL` event and create a new one. This immutability underpins trust in the [environmental credit](/docs/protocol/credits) market.
* **Idempotency** — Use `deduplicationId` on every create and event call so that retries don't produce duplicates. A replayed id is rejected with `409 CONFLICT_ERROR` rather than replayed — treat that conflict as confirmation the first attempt succeeded. This, combined with ordered `externalCreatedAt` timestamps, makes integrations resilient to transient failures.
For the full explanation, see [Core Concepts](/docs/integrations/getting-started/core-concepts).
## Integration model [#integration-model]
At a high level, every integration follows the same base flow:
1. Authenticate with OAuth 2.0 client credentials.
2. Resolve participants and addresses — retrieve by key or create them (`GET`/`POST /participants`, `POST /participants/{participantId}/addresses`).
3. Create a document (`POST /documents`), referencing `participantId` and `addressId`.
4. Append timeline events (`POST /documents/{documentId}/events`), or submit multiple events at once (`POST /documents/events`).
5. Upload optional files through pre-signed attachment URLs.
6. Retrieve and validate final state (`GET /documents/{id}`).
See [API Reference](/docs/integrations/api) for endpoint-level contract details.
## Prerequisites [#prerequisites]
* Carrot-issued `clientId` and `clientSecret`.
* A stable identifier strategy for `externalId` and `deduplicationId`.
* Event timestamp ordering from your source system.
* Retry and rate-limiting controls in your client.
## Onboarding [#onboarding]
To integrate with the Carrot Network, your platform goes through [accreditation](/docs/protocol/network-integrators): you submit company and address information and sign an agreement. Once the process starts, Carrot issues **test credentials** so you can develop and validate your integration against test data. After accreditation is complete, Carrot issues **production credentials** for live data. See [Environments](/docs/integrations/getting-started/environments) for test vs production behavior and the go-live checklist.
## How this section is organized [#how-this-section-is-organized]
* [Getting Started](/docs/integrations/getting-started/quick-start): first end-to-end flow, core concepts, and environment setup.
* [Guides](/docs/integrations/guides/submitting-a-mass-id): task-focused implementation patterns.
* [Reference](/docs/integrations/reference/event-specification): shared event/data constraints.
* [Methodology Integration](/docs/integrations/guides/methodology-guides): methodology-specific events, attributes, and validation rules.
## Migrating from a previous integration [#migrating-from-a-previous-integration]
If you are upgrading from an older integration or a different API version, note these current requirements:
* **Document category** — Use `MassID` (not `Mass`).
* **Measure unit** — Use `kg` (lowercase) for mass.
* **Metadata keys** — Use Title Case (e.g. `Vehicle License Plate`, `Issue Date`). See [Data Formats](/docs/integrations/reference/data-formats).
* **ACTOR events** — Use the `label` field to identify participant roles (Waste Generator, Recycler, Processor, Hauler, Integrator). Do not send deprecated fields such as `actor-type`.
* **Participants and addresses** — Prefer resolving them first and referencing by `participantId`/`addressId`. Inline `participant`/`address` objects are still supported and find-or-create the record; send exactly one form of each.
* **Event names** — Use the specific event names required by the methodology (e.g. `Pick-up`, `Transport Manifest`, `Weighing`, `Drop-off`, `Sorting`, `Recycled`, `Recycling Manifest`). The `OPEN` event is not used; do not send it.
For the full event sequence and field requirements, see the [methodology integration guides](/docs/integrations/guides/methodology-guides).
# Credit Ecosystem Roles
[Environmental credits](/docs/protocol/credits) depend on several distinct roles. Some define the
rules, some perform the physical work, some turn operational data into auditable evidence, some
provide independent assurance, and some issue, purchase, or retire credits.
This page maps those roles in the Carrot crediting system. It is an orientation guide: each role
links to the page where that topic is explained in depth.
One organization can hold more than one role. For example, Carrot can act as a
[standard](/docs/standard), operate [registry](/docs/registry) infrastructure, and provide
digital MRV ([dMRV](/docs/protocol/dmrv)) infrastructure depending on the methodology context. Independent
assurance must remain separate: [validation and verification bodies (VVBs)](/docs/glossary#vvb) and
independent auditors are not replaced by Carrot's infrastructure.
## The main roles [#the-main-roles]
| Role | What it does | Learn more |
| ------------------------------------------ | ----------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- |
| Standard | Governs the rules, methodology lifecycle, and integrity requirements that credits must follow. | [The Standard](/docs/standard) |
| Methodology | Defines the scientific basis for measuring a specific environmental claim. | [Methodologies](/docs/methodologies) |
| Program Owner | Leads the development of a credit program and coordinates its methodology, MvF, MvA, and proposed rewards policy. | [Program Owner](#program-owner) |
| Methodology Verification Framework (MvF) | Turns a methodology into operational rules, evidence requirements, formulas, and testable verification criteria. | [MvF](/docs/standard/concepts/mvf) |
| Methodology Verification Application (MvA) | Implements MvF rules as deterministic software that can evaluate submitted data. | [MvA](/docs/standard/concepts/mva) |
| dMRV | Runs methodology rules against real-world supply chain data and produces auditable digital evidence. | [dMRV](/docs/protocol/dmrv) |
| Carrot infrastructure | Orchestrates dMRV execution, records evidence, manages credit lifecycle infrastructure, and exposes public views. | [Platform Architecture](/docs/protocol/platform-architecture) |
| VVB or independent auditor | Provides external assurance and review for methodology fidelity, facility accreditation, or evidence packages. | [Third-Party Verification](/docs/protocol/third-party-verification) |
| Registry | Issues, tracks, and retires credits with public records that prevent double counting. | [Registry](/docs/registry) |
| Network Developer | Fosters credit and traceability projects by onboarding participants and coordinating accreditation. | [Network Developer](#network-developer) |
| Network Integrator | Connects operational systems to Carrot by submitting supply chain data through the API. | [Network Integrators](/docs/protocol/network-integrators) |
| Waste Manager | Coordinates waste destination for a Waste Generator without taking physical custody of the material. | [Supply Chain](/docs/protocol/supply-chain#waste-manager) |
| Supply chain participants | Perform the physical work: generating, collecting, transporting, processing, or recycling material. | [Supply Chain](/docs/protocol/supply-chain) |
| Credit buyer | Purchases and retires credits to claim verified environmental impact. | [Credit Purchase](/docs/protocol/credit-purchase) |
## How the roles connect [#how-the-roles-connect]
The roles connect in a sequence from rule-setting to credit retirement:
1. A **standard** governs the requirements for credit integrity.
2. A **methodology** defines how a specific environmental benefit is measured.
3. A **Program Owner** coordinates the construction of a credit program; governance retains approval authority.
4. The methodology is translated into an **MvF** and implemented as an **MvA**.
5. A **Network Developer** can bring participants into the program and coordinate their accreditation process.
6. [**Waste Managers**](/docs/protocol/supply-chain#waste-manager) coordinate destination decisions, while physical participants handle the material.
7. **Network Integrators** submit supply chain data from physical operations.
8. **dMRV** executes methodology rules against that data and produces auditable evidence.
9. **VVBs and independent auditors** provide external assurance where required.
10. Verified outcomes become [certificates](/docs/protocol/certificates) and [credits](/docs/protocol/credits).
11. The **registry** issues, tracks, and retires credits.
12. **Credit buyers** purchase and retire credits.
13. Proceeds flow back to verified contributors through [rewards distribution](/docs/protocol/rewards-distribution).
## Program Owner [#program-owner]
A **Program Owner** leads the development of a credit program with Carrot. It assesses the target
market, coordinates the methodology, Methodology Verification Framework (MvF), and Methodology
Verification Application (MvA), and proposes a program-specific rewards policy within the
requirements of the Carrot dMRV Standard.
The role coordinates construction; it does not approve its own program. Methodology, framework, and
application approval remains with the Community of Experts and Carrot's governance processes. A
Program Owner does not hold the program's credits and never receives protocol rewards. Any separate
commercial services are governed by contract, outside the protocol distribution.
## Network Developer [#network-developer]
A **Network Developer** fosters credit and traceability projects by recruiting participants into the
Carrot Network and specific credit programs. It coordinates the accreditation process defined by the
applicable methodology framework and submits supporting data and documents to Carrot.
The Network Developer does not approve participants. Where third-party assurance is required,
participants must still contract an independent auditor; the Network Developer coordinates the
process but cannot replace that assurance. Because it submits third-party data, it is accountable for
the quality and accuracy of the information submitted and is subject to the network's
[self-policing rules](/docs/standard/policies/rewards-distribution#what-feeds-the-community-pool).
A Network Developer can hold other ecosystem roles when no conflict of interest exists. It never
receives protocol rewards; any remuneration for its services is contractual and outside the rewards
distribution.
## Where Carrot fits [#where-carrot-fits]
Carrot can hold different roles depending on the methodology context.
For [BOLD Recycling](/docs/methodologies/bold-recycling), Carrot acts as the standard because no
established global recycling credit standard covers the use case. Carrot governs the methodology
lifecycle and the integrity requirements for credits issued under that methodology.
For carbon methodologies such as [AMS-III.F](/docs/methodologies/ams-iii-f) and [BOLD Carbon
(CH₄)](/docs/methodologies/ams-iii-f/bold-carbon), the scientific basis references an external
standard. In that context, Carrot provides dMRV infrastructure and registry functions while the
methodology framework references the external standard.
Across the network, Carrot provides infrastructure that records evidence, executes methodology rules,
and makes outcomes publicly verifiable.
## What stays independent [#what-stays-independent]
Carrot infrastructure does not replace independent assurance. VVBs and independent auditors provide
external review according to the applicable governance scope.
Independent assurance can cover methodology fidelity, facility audits, participant accreditation, and
evidence packages. Carrot's dMRV infrastructure produces the digital evidence that makes that review
more continuous, scalable, and auditable.
## Everyday analogies [#everyday-analogies]
These analogies are imperfect, but they help separate the roles:
| Role | Analogy |
| -------------------------- | ---------------------------------------------------------------------------------- |
| Methodology | A recipe for measuring environmental impact |
| dMRV | A digital evidence workflow that checks whether the recipe was followed |
| VVB or independent auditor | Independent assurance that reviews the method, evidence, or operational conditions |
| Registry | The public record that prevents the same credit from being claimed twice |
## Where to go next [#where-to-go-next]
* [How It Works](/docs/protocol/how-it-works) — End-to-end flow from physical work to credits
* [Platform Architecture](/docs/protocol/platform-architecture) — System architecture for verification and credit issuance
* [The Standard](/docs/standard) — How Carrot governs methodology quality
* [Registry](/docs/registry) — How credits are issued, tracked, and retired
* [Third-Party Verification](/docs/protocol/third-party-verification) — What VVBs and auditors do
* [Methodology Ecosystem](/docs/standard/concepts/ecosystem) — How methodologies become executable verification
* [Credit Purchase](/docs/protocol/credit-purchase) — How credit buyers purchase credits
* [Credit Retirement](/docs/protocol/credit-retirement) — How buyers claim verified impact
# How It Works
If you are new to environmental credit markets, start with
[Credit Ecosystem Roles](/docs/protocol/credit-ecosystem-roles) to see how standards, methodologies,
digital MRV ([dMRV](/docs/protocol/dmrv)), registries, VVBs, buyers, and supply chain participants
fit together.
## The recycling supply chain [#the-recycling-supply-chain]
Network Integrators digitize the recycling supply chain by connecting their operations to the Carrot Network — capturing the path that materials take from waste generation through collection, sorting, hauling, and processing at accredited recycling or [biological treatment](/docs/glossary#biological-treatment) facilities. At each stage, the physical work performed by participants is recorded digitally, creating a verifiable chain of custody.
Understanding how waste logistics works is essential to understanding how Carrot creates value. Sorting and cleaning mixed waste after it has been contaminated is too expensive and technically complex for most locations. High-performance recycling requires reaching the **source** of waste creation — the [Waste Generator](/docs/protocol/supply-chain) — because proper sorting must happen before materials are collected, not after.
[Deep dive into the recycling supply chain](/docs/protocol/supply-chain)
## From waste to digital asset [#from-waste-to-digital-asset]
When waste materials are collected and sorted, they are codified into [MassIDs](/docs/protocol/mass-ids) — digital records that capture material type, weight, and chain of custody. MassIDs travel with the physical material through the supply chain, creating a digital twin that tracks every transfer and transformation.
Each MassID records the full chain of custody — built from data submitted by [Network Integrators](/docs/protocol/network-integrators) — enabling end-to-end traceability from waste generation to final processing.
## Verifying environmental impact [#verifying-environmental-impact]
When MassIDs reach an accredited recycling or biological treatment facility, they enter the dMRV process. Automated rule-based validation, backed by third-party auditors, confirms that the claimed environmental work was performed.
This verification step is what separates Carrot from traditional receipt-based systems. Instead of relying on paper receipts that can be duplicated and manipulated, the dMRV process executes [methodology](/docs/methodologies)-specific rules against physical outcomes, producing verifiable and auditable results.
## Generating environmental credits [#generating-environmental-credits]
MassIDs that pass methodology verification generate [Certificates](/docs/protocol/certificates) — unique digital records that each represent a specific verified environmental outcome:
* **[GasID](/docs/protocol/certificates#gasid)** — Represents greenhouse gas emission reductions (e.g., methane reductions achieved by biological treatment of organic waste instead of landfilling)
* **[RecycledID](/docs/protocol/certificates#recycledid)** — Represents certified recycled material processed through an accredited facility
Certificates in turn back the issuance of credits: [Tokenized Carbon Credits (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc) and [Tokenized Recycling Credits (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc). Credits are standardized within the applicable material class or methodology, making them tradable commodities.
[Explore the credit lifecycle](/docs/protocol/credit-lifecycle)
## Creating a market for credits [#creating-a-market-for-credits]
Credits become tradable assets on a transparent, public market. Organizations and individuals purchase and retire credits to meet [Extended Producer Responsibility (EPR)](/docs/protocol/the-solution#epr) mandates and ESG goals.
Credits are purchased through Carrot interfaces that handle pricing and settlement — replacing the opaque, intermediary-heavy over-the-counter markets where most environmental credits are currently traded. The platform establishes prices for each credit type (e.g., 1 ton of diverted organic waste) and provides a transparent market accessible to organizations of any size, with additional credit types expected as new methodologies launch.
[Learn about purchasing credits](/docs/protocol/credit-purchase)
## Distributing rewards [#distributing-rewards]
Proceeds from credit purchases are distributed directly to the verified contributors in the recycling supply chain through an automated, rule-based process. The distribution follows the [Rewards Distribution Policy](/docs/standard/policies/rewards-distribution), ensuring that value reaches every participant who contributed to the environmental outcome — from waste generators who sorted correctly, to haulers and processors.
This creates a self-reinforcing incentive loop:
1. Waste generators are rewarded for sorting, covering their costs and encouraging continued participation
2. [Recyclers](/docs/protocol/supply-chain#the-role-of-the-recycler), [Haulers](/docs/protocol/supply-chain), and [Processors](/docs/protocol/supply-chain) receive new revenue streams, enabling them to invest in expanding operations
3. Non-participants are attracted to join the ecosystem through incentives (Recycle-to-Earn)
[Read about rewards distribution](/docs/protocol/rewards-distribution)
## How the network grows [#how-the-network-grows]
The Carrot Network grows through [Network Integrators](/docs/protocol/network-integrators) — local waste management and logistics providers who connect their existing operations to the Carrot Network. By integrating with Carrot, these providers gain access to a new revenue stream from environmental credits, incentivizing them to onboard their entire recycling customer base.
The network's first use case — organic waste biological treatment under [BOLD Recycling](/docs/methodologies/bold-recycling) and [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) (BOLD: Breakthrough in Organics Landfill Diversion) — was chosen because organic waste represents approximately 50% of global waste volume and almost all of it currently ends up in landfills. Diverting organic waste to biological treatment generates both carbon credits (methane reductions) and recycling credits, while also removing the food contamination that degrades the quality of other recyclable materials.
From this initial use case, the network expands by introducing new [methodologies](/docs/methodologies) for additional waste streams and by growing geographically as more Network Integrators join in new markets.
***
Understand how to buy credits and what evidence you receive in the [credit
purchase](/docs/protocol/credit-purchase) and [credit
retirement](/docs/protocol/credit-retirement) guides.
# Circular Economy Protocol
## What is the Circular Economy Protocol? [#what-is-the-circular-economy-protocol]
The Circular Economy Protocol is the set of technological and financial rules that coordinates circular economy activity on the Carrot Network. It connects supply chain data, chain-of-custody records, certificates, traceable credits, retirement, rewards, and settlement into one auditable flow.
At its core, the protocol standardizes how real-world circular economy work becomes traceable digital evidence. Waste movements are recorded as MassIDs, verified outcomes become RecycledID or GasID certificates, and those certificates back Tokenized Recycling Credits (TRC) or Tokenized Carbon Credits (TCC). The same protocol flow also governs how credits are purchased, retired, and connected to settlement and rewards distribution.
digital Measurement, Reporting and Verification ([dMRV](/docs/protocol/dmrv)) is the execution and evidence process inside this broader protocol. It runs approved methodology framework criteria against supply chain data and records the evidence that third-party verifiers, buyers, auditors, and the public can review.
## What's covered in this section [#whats-covered-in-this-section]
Why the linear take-make-waste economy fails and what needs to change
How Carrot turns verified recycling into tradable environmental assets
The end-to-end flow from waste collection to credit issuance
Who does what across standards, methodologies, dMRV, registry, VVBs, buyers, and supply chain
participants
End-to-end operational flow from supply chain data to credit issuance and retirement
How third parties review methodology compliance, dMRV evidence, and credit integrity
dMRV, MassIDs, methodology execution, and the recycling supply chain
MassIDs, certificates, credit lifecycle, issuance, purchase, and retirement
How the Registry executes and records transactions, and how it interoperates with other systems
# Platform Architecture
## How the Carrot Network works [#how-the-carrot-network-works]
This page gives the end-to-end operational view of the Carrot Network. It shows how supply chain data becomes auditable evidence, how approved methodology framework criteria produce verified outcomes, and how those outcomes move through certificate issuance, credit issuance, purchase, rewards distribution, and retirement.
This page is an orientation map. It does not define the Circular Economy Protocol by itself: [Protocol](/docs/protocol) explains the domain-specific circular economy rules, digital MRV ([dMRV](/docs/protocol/dmrv)) explains execution and evidence, and [Registry](/docs/registry) explains credit Registry Recording, purchase, retirement, wallets, and settlement records.
For a non-technical map of the organizations and roles behind this architecture, see
[Credit Ecosystem Roles](/docs/protocol/credit-ecosystem-roles).
## Overview [#overview]
### 1. Supply chain data capture [#1-supply-chain-data-capture]
[Network Integrators](/docs/protocol/network-integrators) digitize waste management operations, capturing material type, weight, and chain of custody at every handoff. This data enters the platform via the [Carrot API](/docs/integrations/api), creating a digital record of the physical work performed across the [recycling supply chain](/docs/protocol/supply-chain).
### 2. MassID creation [#2-massid-creation]
Supply chain data is codified into [MassIDs](/docs/protocol/mass-ids) — the foundational data units of the network. Each MassID records material type, weight, and the full chain of custody from waste source to recycling facility. As materials move through the supply chain, MassIDs are created and updated, building the Proof-of-Physical-Work and Proof-of-Provenance record that methodology execution will later verify.
### 3. Methodology execution [#3-methodology-execution]
The platform processes MassIDs through its dMRV pipeline — verifying compliance with scientific standards, evaluating conditions, and producing verified outcomes. Each methodology is implemented as a [Methodology Verification Framework (MvF)](/docs/standard/concepts/mvf) that defines the rules, and a [Methodology Verification Application (MvA)](/docs/standard/concepts/mva) that automates their execution. When a MassID passes methodology verification, it is marked eligible for recording on the public registry.
[Learn about methodology execution](/docs/protocol/methodology-execution)
### 4. Recording on the public registry [#4-recording-on-the-public-registry]
Each verified MassID is recorded on the public registry — metadata is built, uploaded to independent public storage ([IPFS](https://ipfs.tech/)), and a unique registry entry is created — a publicly verifiable record of the waste batch. Entries can later be revoked if the underlying data is found to be incorrect; revocation is itself recorded on the public registry (see [Revocation](/docs/protocol/smart-contracts/on-chain-flows#revocation)).
[Learn how registry records are created](/docs/protocol/on-chain-minting)
### 5. Certificate issuance [#5-certificate-issuance]
When a MassID passes methodology verification under a specific methodology at an accredited facility, [certificates](/docs/protocol/certificates) ([GasID](/docs/protocol/certificates#gasid) or [RecycledID](/docs/protocol/certificates#recycledid)) are issued. Certificates link verified environmental outcomes — recycled material or prevented greenhouse gas emissions — to the underlying MassID that proves the physical work occurred.
### 6. Credit generation [#6-credit-generation]
Certificates generate credits — [Tokenized Recycling Credits (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc) and [Tokenized Carbon Credits (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc) — whose unit is defined by the applicable methodology. The [BOLD Recycling](/docs/methodologies/bold-recycling) methodology issues `C-BIOW` TRCs in metric tons of certified recycled material; the [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) methodology issues `C-CARB.CH4` TCCs in metric tons of CO₂e reductions. Credits are interchangeable only within their applicable class and methodology symbol. Other methodologies may issue different credit symbols. Credits use an open, widely supported implementation format designed for market activity: purchasing, holding, and retiring.
### 7. Credit purchase [#7-credit-purchase]
Buyers (organizations or individuals) [purchase credits](/docs/protocol/credit-purchase) through Carrot interfaces — for example, the [Carrot Store](https://store.carrot.eco) for individuals, or Carrot-provided interfaces for organizations. Purchases are settled directly on the public registry in traceable digital currency (USDC); all steps complete in a single transaction or none of them do.
### 8. Rewards distribution [#8-rewards-distribution]
Proceeds from credit purchases are [distributed back](/docs/protocol/rewards-distribution) to every participant in the recycling supply chain, proportional to their verified contribution. This Recycle-to-Earn model ensures that [Waste Generators](/docs/protocol/supply-chain), [Bin Custodians](/docs/protocol/supply-chain), [Haulers](/docs/protocol/supply-chain), [Processors](/docs/protocol/supply-chain), [Recyclers](/docs/protocol/supply-chain#the-role-of-the-recycler), and Network Integrators are all rewarded for the environmental work they perform.
### 9. Credit retirement [#9-credit-retirement]
Purchased credits are [retired](/docs/protocol/credit-retirement) to permanently claim the environmental benefit they represent. Retirement permanently removes the credits from circulation on the public registry and creates a non-transferable Credit Retirement Receipt as permanent proof. Credits can be retired standalone at any time after purchase, once they are back in [Vault](/docs/protocol/smart-contracts) custody, or through integrated retirement (purchased and retired in a single atomic transaction).
## Public verifiability [#public-verifiability]
All registry activity — from MassID recording through credit retirement — is written to the immutable public registry as transactions executed by deterministic software. This data is publicly verifiable and consumable by anyone and any platform: auditors, regulators, indexers, and third-party applications can read and verify it directly from the public registry without relying on Carrot's infrastructure. That design enables **interoperability** (other systems can build on the same data) and **transparency and trust** independent of Carrot's availability.
The [Carrot Registry](/docs/protocol/registry) offers a user-friendly, domain-focused view of public registry data plus platform data (methodology definitions, rule execution, accreditations). For infrastructure-independent verification of public registry data only, any public blockchain explorer (e.g. [PolygonScan](https://polygonscan.com/)) provides direct access to raw transactions and event logs. See [Interoperability](/docs/protocol/interoperability) for how external systems can monitor, index, and verify Carrot data.
## Deeper topics [#deeper-topics]
* [Credit Lifecycle](/docs/protocol/credit-lifecycle) — The MassID, Certificate, and Credit lifecycle and relationships
* [Smart Contracts](/docs/protocol/smart-contracts) — The automated registry software that executes network transactions
* [dMRV](/docs/protocol/dmrv) — Execution and evidence for methodology framework criteria
* [Supply Chain](/docs/protocol/supply-chain) — Participant roles, logistics flows, and the validator model
* [Carrot Registry](/docs/protocol/registry) — The public verification interface, and the independent public block explorers that verify on-chain ledger data without it
### Diagram: platform-architecture-flow
This platform architecture flow traces how captured data becomes retired credit through MassID creation, methodology execution, certificate and credit issuance, purchase, and retirement. The rewards branch shows purchase value returning to the supply chain, Network Integrator, methodology, and Carrot Network, making the operational pipeline and incentive distribution part of one system.
# The Problem
## The linear economy is failing [#the-linear-economy-is-failing]
More than 80% of everything produced and consumed by humans ends up as pollutants — buried in landfills, dumped into water bodies, or burned into the atmosphere. The take-make-waste model, known as the linear economy, offloads the environmental costs of waste production into the commons and distributes disposal costs uniformly across taxpayers, providing no incentive to reduce, sort, reuse, or recycle.
The numbers are stark:
* The world generates over **2 billion tons** of municipal solid waste annually, expected to reach **3.4 billion tons by 2050** ([World Bank, What a Waste 2.0](https://datatopics.worldbank.org/what-a-waste/)).
* **33%** of global waste is openly dumped. Only **19%** is recovered through recycling or biological treatment.
* Toxins and airborne particulate matter from landfills and burned waste are linked to respiratory diseases and cancer.
* Liquid runoff (leachate) drains into water bodies, contaminating soil and aquifers.
As global GDP grows, so does waste per capita — and developing countries experience the fastest increases in waste generation relative to income growth.
## Resource scarcity compounds the crisis [#resource-scarcity-compounds-the-crisis]
Global resource use has more than tripled since 1970. Commodity prices have begun to outpace economic growth, signaling increasing scarcity. Without a shift to reuse and recycling, supply chains face growing risk from limited raw material availability.
A sustainable path requires decoupling economic growth from virgin resource consumption — keeping existing materials in the economy for as long as possible and transitioning to regenerative materials where feasible.
## Existing solutions aren't scaling [#existing-solutions-arent-scaling]
Landfills, incineration, biological treatment infrastructure, producer responsibility programs, and carbon markets have each attempted to address the waste crisis — but none has achieved the scale or trust needed for systemic change.
Landfills and waste-to-energy (WtE) incineration sustain the linear economy model. Landfills emit methane — a greenhouse gas with [27 times the warming potential of CO₂](https://www.ipcc.ch/assessment-report/ar6/) — and even the best methane capture systems eliminate no more than 50% of emissions. Incineration produces energy inefficiently while transferring pollution from the ground to the atmosphere, and both approaches remove the incentive for source sorting.
Long-term municipal contracts with landfill and incineration operators lock in expensive, poorly performing waste solutions and restrict innovation for recycling and biological treatment.
Biological treatment of organic waste — including composting, anaerobic digestion, black soldier fly processing, and microbial processing — eliminates nearly all methane emissions by processing material under controlled conditions. These methods produce nutrient-rich outputs that restore topsoil, reduce the need for carbon-intensive fertilizers, and enhance carbon capture through improved plant growth. It is estimated that for every ton of organic waste biologically treated, **1.0 to 2.75 tons of CO2 equivalent** emissions are prevented or captured ([EPA WARM model](https://www.epa.gov/warm)).
Despite these benefits, organic waste continues to flow overwhelmingly to landfills and incinerators due to the absence of market incentives and infrastructure for source sorting.
Extended Producer Responsibility (EPR) laws — requiring manufacturers and importers to bear a portion of the environmental costs of their products — and Pay-As-You-Throw (PAYT) programs have seen limited adoption in their current form. Both are centralized approaches that have not created the market dynamics needed to scale high-performance recycling at the individual and business level.
Carbon markets, both mandatory (Emissions Trading Systems) and voluntary, face persistent challenges that limit their effectiveness:
* **Limited coverage** — Major economies (including the US, Brazil, India, and Indonesia) still lack mandatory carbon pricing mechanisms.
* **Prices too low** — In many markets, it remains cheaper to buy inexpensive credits or pay fines than to invest in decarbonization.
* **Certification bottlenecks** — Third-party certification (e.g., [Gold Standard](https://www.goldstandard.org/), [Verra](https://verra.org/)) is slow (3-5 years), expensive (US$250-500K per project), and limited to the largest polluting projects.
* **Trust deficit** — Carbon accounting is inherently difficult for intangible emissions. Double counting, unverified future-performance claims, and lack of public registries undermine confidence.
* **Greenwashing** — Companies under ESG pressure often resort to superficial sustainability claims rather than measurable environmental improvement. Regulation is improving (e.g., SEC climate disclosure proposals, EU ETS expansion), but transparency gaps remain.
Physical waste, unlike carbon, is **tangible, measurable, and verifiable**. Recycling and biological treatment offer documented, science-based methods for reducing greenhouse gases — backed by frameworks from the [UNFCCC](https://unfccc.int/), the [EPA WARM model](https://www.epa.gov/warm), and the [Greenhouse Gas Protocol](https://ghgprotocol.org/). This makes waste-based environmental credits a potentially higher-quality alternative to traditional carbon offsets.
## The opportunity [#the-opportunity]
The transition from a linear to a circular economy requires market forces and incentives at every level — from individual waste generators to industrial processors. Businesses need financial incentives to source recycled inputs and design for recyclability. Individuals need to trust that their sorting efforts lead to real recycling outcomes and be rewarded for participating.
What's missing is a system that can **track, verify, and incentivize** recycling and biological treatment at scale — creating a market-driven circular economy where environmental impact is transparent, tradable, and trustworthy. This requires robust [supply chain](/docs/protocol/supply-chain) traceability and digital MRV ([dMRV](/docs/protocol/dmrv)) to ensure every claim is backed by auditable data.
[Read about Carrot's solution](/docs/protocol/the-solution)
# The Solution
## From linear to circular [#from-linear-to-circular]
The circular economy is a fundamental redesign of how materials flow through the economy. Instead of the take-make-waste model, a circular economy keeps materials in use for as long as possible and recovers them at end of life for reuse and recycling.
Materials fall into two broad categories, each representing roughly half of total resource consumption:
* **Technical materials** — Finite resources (metals, glass, plastics) that do not degrade naturally. Most can be recycled repeatedly if products are disassembled and sorted by material type. Higher recycling volumes also improve processing efficiency — for example, glass ovens running on recycled cullet operate at lower temperatures, reducing energy costs and CO2 emissions.
* **Biological materials** — Renewable resources (food, green waste, compostable packaging) that can be returned to the natural environment through biological treatment (e.g., composting, anaerobic digestion, black soldier fly processing, microbial processing), restoring topsoil and supporting future plant growth. Biological products are not to be confused with biodegradables, which are petroleum-derived and produce microplastics when they degrade.
An efficient circular economy reduces dependence on virgin resource extraction, cuts carbon-intensive supply chains, and creates new economic opportunities in recycling, remanufacturing, and biological treatment.
## Background: circular economy concepts [#background-circular-economy-concepts]
The circular economy draws on established frameworks. Carrot builds on these foundations to create a market-driven approach.
Zero Waste provides the benchmark for circular economy performance. As defined by the [Zero Waste International Alliance (ZWIA)](https://zwia.org/zero-waste-definition/), it is the conservation of all resources through responsible production, consumption, reuse, and recovery — without burning or discharge to land, water, or air.
Institutions such as ZWIA and the US Green Building Council's [TRUE (Total Resource Use and Efficiency)](https://true.gbci.org/) program set a minimum **90.1% waste diversion** rate from landfills, incinerators, and the environment for certification. While this sounds ambitious compared to the global average of 19%, practical experience shows it is achievable.
A critical insight from waste composition data: approximately **50% of all waste globally is organic matter**. Because organic waste is 100% recyclable through biological treatment, diverting it from the trash stream is the single most impactful first step. Removing organic waste also eliminates food contamination of recyclables, typically improving recycling performance of remaining materials by **2-4x**.
Pay-As-You-Throw (PAYT) assigns waste responsibility to each generator based on the actual amount of waste they produce — much like a utility bill for water or electricity. This simple shift in pricing creates direct incentives for waste reduction and source sorting.
When businesses and individuals pay per unit of waste, they are motivated to reduce, sort, and recycle. PAYT also opens the recycling market to private enterprises that can offer high-performance hauling, recycling, and biological treatment services, creating competition and innovation where centralized municipal systems have failed to scale.
Extended Producer Responsibility (EPR) requires product manufacturers and importers to bear a portion of the environmental costs of their products through recycling offsets. Companies report the waste generated by their operations and products, then purchase offsets — recycling or carbon credits — to compensate for unrecovered material.
EPR programs are gaining traction globally. Major corporations have endorsed the framework, and regulations are expanding across jurisdictions. However, current EPR systems face fundamental challenges:
* **Double counting** — Receipt-based validation systems are easily manipulated, with multiple receipts generated for the same waste mass across different jurisdictions.
* **No chain of custody** — Rewards from offset sales only reach the final operator in the supply chain, with no mechanism to compensate upstream contributors (collectors, sorters, haulers).
* **Centralized and bureaucratic** — Coordination between municipalities, states, and federal governments leads to poor data quality and inefficient resource allocation.
## How Carrot bridges the gap [#how-carrot-bridges-the-gap]
Many carbon market solutions — enhanced rock weathering, direct air capture, biochar sequestration — depend on complex modeling, estimation, and long-term inference. Carrot's approach is different: its digital MRV ([dMRV](/docs/protocol/dmrv)) system verifies real physical events. Waste is collected, weighed, transported, and processed at an accredited facility. The data is direct, the outcomes are measurable, and each credit links to a specific, verifiable physical event.
Carrot combines PAYT and EPR with dMRV to solve the fundamental problems of trust, transparency, and fair reward distribution.
Physical waste — unlike carbon emissions — is **tangible, measurable, and verifiable**. Every material mass can be tracked through the recycling [supply chain](/docs/protocol/supply-chain), from generation to final processing. The Carrot Network codifies this physical work into [MassIDs](/docs/protocol/mass-ids), creating an unbreakable chain of custody that eliminates double counting and enables rewards to be distributed directly to all verified contributors through settlement executed by deterministic software.
The carbon reduction benefits of recycling and biological treatment are well documented and science-based, with measurement frameworks from the [UNFCCC](https://unfccc.int/), [EPA WARM model](https://www.epa.gov/warm), and the [Greenhouse Gas Protocol](https://ghgprotocol.org/). By applying these frameworks to verifiable physical waste data, the dMRV system produces environmental credits — [Tokenized Recycling Credits (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc) issued under methodologies such as [BOLD Recycling](/docs/methodologies/bold-recycling), and [Tokenized Carbon Credits (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc) issued under methodologies such as [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) — that are backed by real, measurable outcomes rather than estimates or future projections.
Proceeds from credit purchases are distributed to participants, creating a self-reinforcing incentive loop: more recycling generates more credits, which fund more recycling capacity. This market-driven approach scales participation without requiring centralized enforcement or taxation.
[Read about how the system works end-to-end](/docs/protocol/how-it-works)
## Vision: closing the loop [#vision-closing-the-loop]
The Carrot Network lays the groundwork for a fully circular consumer economy. As it matures, ecosystem participants will be able to build solutions that bring transparency to the entire product lifecycle:
* **Proof of recycled content** — Certified-recycled MassIDs can be attached to new products, enabling producers to verifiably prove recycled material content rather than relying on unverified marketing claims.
* **Product composition** — Third-party auditors can analyze the material and chemical composition of products and assign Product Type Identifiers (PTIs), enabling automated MassID creation when products enter the recycling stream.
* **Local recyclability** — Consumers can check whether a product is recyclable in their area — not only theoretically recyclable — and learn how to dispose of it correctly for local recycling operators.
These capabilities close the information gap between producers and consumers, making recyclability a competitive advantage for businesses and an informed choice for buyers.
***
[See how to buy](/docs/protocol/credit-purchase) | [Contact our
team](https://carrot.eco/en/contact)
### Diagram: solution-overview-flow
This solution overview expands the same loop into physical and digital operating stages. Waste generation, collection, and processing move into MassID creation, dMRV verification, certificates, credits, and the credit market; rewards distribution then feeds back into the physical world. The takeaway is a self-reinforcing system where verified activity finances more recycling.
# Third-Party Verification
## Third-party assurance at every level [#third-party-assurance-at-every-level]
Carrot does not rely on its own assessment to generate [credits](/docs/protocol/credits). At every level of the ecosystem, independent third parties validate that the process is sound. This separation between Carrot's operations and independent assurance is fundamental to credit integrity.
The result: the methodology framework a credit depends on, and the facilities and participants behind it, are validated by parties independent of Carrot rather than by Carrot's own assessment. Rule execution is deterministic and every outcome is reviewable.
For the broader role map, including where VVBs and auditors sit in the crediting system, see
[Credit Ecosystem Roles](/docs/protocol/credit-ecosystem-roles).
## Four levels of independent validation [#four-levels-of-independent-validation]
Each level addresses a different dimension of trust — from physical operations to digital rule execution.
| Level | What is validated | Who validates |
| ------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Facility audit** | Physical inspection of recycling and biological treatment facilities. Verifies that the facility operates as claimed and meets the requirements defined in the methodology. | Independent auditors |
| **Accreditation** | Document and process validation. Verifies that participants (generators, haulers, processors, recyclers) have proper documentation, licensing, and operational capacity. | Independent auditors |
| **Methodology framework validation** | The methodology framework (MvF) is validated against the source scientific methodology. Ensures the operational rules faithfully represent the scientific basis. | Validation/Verification Bodies (VVBs) |
| **dMRV execution** | The automated verification application (MvA) runs methodology rules against supply chain data. Execution results, rule runs, and inputs remain platform data; selected commitments are recorded on the immutable public registry. | Deterministic software, with Carrot-recorded human decisions where a rule cannot be settled by code; independently audited by VVBs and public observers |
Where a rule cannot be settled by code it returns an indeterminate result, and the judgment is made
by a decision recorded on Carrot's side — approve or reject, each with a mandatory written justification
and a named reviewer. If the review window closes with no decision, the outstanding rules are
rejected automatically and the verification fails. Those decisions are preserved with the
verification run, so external assurance can review both the rule outcomes and the judgments applied
to them.
## What Carrot does vs. what third parties do [#what-carrot-does-vs-what-third-parties-do]
### Carrot — infrastructure and approval [#carrot--infrastructure-and-approval]
Carrot provides the infrastructure that orchestrates and records digital MRV ([dMRV](/docs/protocol/dmrv)) execution. It approves methodologies, methodology verification frameworks, and third-party dMRV applications for use on the Carrot Network, then runs approved framework criteria against submitted data and preserves the resulting evidence.
Carrot does not create methodologies, verification frameworks, or dMRV applications. It also does not replace external assurance: its role is to execute approved criteria, record outcomes, and make the evidence reviewable.
Carrot's infrastructure includes:
* Validating data inputs against approved framework criteria
* Executing calculations and eligibility or exclusion rules
* Recording digital evidence and audit trails, including logs, versions, events, and automated decisions
* Applying integrity controls and double-counting prevention, including across overlapping methodologies
### Third parties — independent assurance [#third-parties--independent-assurance]
[Validation/Verification Bodies](/docs/glossary#vvb), independent auditors, and other approved assurance providers review the evidence and governance process with scope and depth defined by the applicable methodology, framework, accreditation process, or market requirement.
They may:
* Validate MvF fidelity against the source methodology
* Evaluate whether the MvA faithfully implements the MvF
* Review the [digital evidence package](/docs/glossary#digital-evidence-package) generated by Carrot's dMRV system and perform tests, sampling, and additional audits
* Issue independent reports with findings, non-conformities, and recommendations
## The evidence package [#the-evidence-package]
Carrot's dMRV system organizes and delivers a digital evidence package — data, documents, logs, versions, and events — that VVBs use to perform their independent analysis. This package is the interface between automated verification and human judgment: everything the system records becomes input for independent review.
The verification infrastructure connects supply chain data, methodology rules, and audit trails in a single verifiable pipeline. Network Integrators provide supply chain data from their operations, the system applies methodology rules to that data, and the resulting evidence is available for independent review.
* [dMRV](/docs/protocol/dmrv)
* [Network Integrators](/docs/protocol/network-integrators)
* [Methodology Execution](/docs/protocol/methodology-execution)
# The Standard - Circular Economy Crediting Program
## What is a standard in environmental markets? [#what-is-a-standard-in-environmental-markets]
In environmental markets, a **standard** is the crediting program that defines and governs the rules for how environmental credits are measured and verified. The standards body approves [methodologies](/docs/methodologies), manages their lifecycle — from initial design through versioning to eventual discontinuation — and ensures that the credits produced under those methodologies meet a consistent level of quality.
Without a standards body, there is no independent authority governing what counts as a valid credit. The standard is the layer of trust between the project that generates environmental impact and the buyer who pays for it.
For the broader map of standards, methodologies, digital MRV ([dMRV](/docs/protocol/dmrv)), [registry](/docs/registry), VVBs, and buyers, see
[Credit Ecosystem Roles](/docs/protocol/credit-ecosystem-roles).
## Why Carrot is a standard [#why-carrot-is-a-standard]
Carrot operates as a standards and governance body for methodologies, methodology verification frameworks, and dMRV applications approved for use on the Carrot Network. It defines the Carrot dMRV Standard, evaluates whether submitted methodologies and frameworks meet that standard, and manages their lifecycle through approval, versioning, and discontinuation.
The Carrot dMRV Standard establishes the common ground that allows multiple methodologies to coexist on shared infrastructure, each contributing verified environmental impact data to the same ecosystem.
This independent-authority role is part of the reason the Carrot Network is built as [digital public infrastructure](/docs/network/digital-public-infrastructure), not as a private verification product.
## Crediting architecture [#crediting-architecture]
The architecture moves from shared program rules to public credit records. The [Protocol](/docs/protocol) defines the domain-wide requirements. The Standard governs methodologies; each methodology is operationalized through a [Methodology Verification Framework (MvF)](/docs/standard/concepts/mvf); dMRV applications execute those rules; and the Registry records the resulting credit lifecycle.
## What this means for credit quality [#what-this-means-for-credit-quality]
Every [credit](/docs/protocol/credits) issued within the Carrot Network is backed by a methodology governed under the Carrot dMRV Standard. Three properties support credit integrity:
* **Open-source rules** — All verification logic is published under an open-source license and publicly auditable. Anyone can inspect the rules that produced a given outcome.
* **Automated, auditable verification** — Verification is executed by deterministic software ([MvAs](/docs/standard/concepts/mva)) that produces the same result for the same input, every time. Results are recorded in the public registry and viewable through the [Carrot Registry](/docs/protocol/registry).
* **Independent assurance** — Third-party [Validation and Verification Bodies (VVBs)](/docs/glossary#vvb) provide independent review, adding a layer of oversight beyond the automated process.
## Core principles [#core-principles]
The Carrot dMRV Standard is built on five principles that apply to every methodology in the network: integrity & traceability, additionality & verifiability, standardization & comparability, interoperability & automation, and transparency & auditability. Together, they ensure that every credit is backed by auditable, reproducible evidence — from the original supply chain event to the final credit issuance.
## Compliance and enforcement [#compliance-and-enforcement]
Methodology compliance is currently managed by the Carrot Foundation, which oversees adherence to the Carrot dMRV Standard. As the ecosystem matures, enforcement responsibilities will progressively expand to include community participation. See [Governance](/docs/network/governance) for how this evolution is structured.
Participants who fail to meet the requirements of the Carrot Standard face enforcement actions. Depending on the severity and nature of the violation, consequences may include suspension or removal from the network, and credits may be withheld or revoked. These measures protect the integrity of the credits issued under the network and maintain trust for all participants.
The Standard governs how methodologies are structured, implemented, and evolved within the Carrot ecosystem.
Each methodology is expressed in two layers: a **Methodology Verification Framework (MvF)**, which is the human-readable specification of verification rules and requirements, and a **Methodology Verification Application (MvA)**, which is the deterministic software implementation of those rules. Together, these layers ensure that the intent of a methodology is faithfully and reproducibly executed.
Methodologies operate within a broader ecosystem of actors, tooling, and governance processes that manage their full lifecycle — from initial proposal through approval, active use, versioning, and eventual discontinuation.
* [Methodology Verification Framework (MvF)](/docs/standard/concepts/mvf)
* [Methodology Verification Application (MvA)](/docs/standard/concepts/mva)
* [Methodology Ecosystem](/docs/standard/concepts/ecosystem)
* [Methodology Lifecycle](/docs/standard/concepts/lifecycle)
## Explore this section [#explore-this-section]
* **[Concepts](/docs/standard/concepts/mvf)** — MvF, MvA, ecosystem, and lifecycle fundamentals.
* **[Guides](/docs/standard/guides/mvf-author-guide)** — Practical guides for authoring frameworks, building verification applications, and participating in RFPs.
* **[Policies](/docs/standard/policies/versioning)** — Versioning, quality assurance, accreditation, discontinuation, and rewards distribution.
### Diagram: crediting-architecture-flow
The architecture starts with the Protocol and the Standard as the circular economy crediting program, then moves through an approved Methodology and its dMRV Framework into dMRV execution. dMRV applications execute framework rules and produce auditable evidence; the Registry records the resulting credit lifecycle from issuance to retirement.
# Terms and Conditions of Sale of Environmental Credits
{/* cspell:words Fndn Sielva Gubelstrasse LGPD GDPR FADP OFAC SECO ITMOs mutandis Lugano dMRV stablecoins */}
**Version 2.0 — August 31, 2026**
These Terms govern every purchase of Environmental Credits on the Carrot platform, by consumers (individuals) and businesses; individually negotiated corporate purchases may additionally be governed by a master agreement that prevails where it so provides (Clause 1.4). For buyers domiciled in Brazil, the Portuguese-language version of these Terms is the governing text; for all other buyers, this English version governs.
## 1. Who we are and what these Terms govern [#1-who-we-are-and-what-these-terms-govern]
1.1. These Terms and Conditions ("**Terms**") govern the purchase of Environmental Credits from Carrot Fndn, a foundation established under Articles 80 et seq. of the Swiss Civil Code, with registered seat in Zug, Switzerland, c/o Sielva Management SA, Gubelstrasse 11, 6300 Zug, UID CHE-152.448.302 ("**Foundation**" or "**Carrot**").
1.2. Support: [support@carrot.eco](mailto:support@carrot.eco) (Portuguese-language support available for buyers in Brazil). Data-protection officer: [legal@carrot.eco](mailto:legal@carrot.eco).
1.3. By completing a purchase, you (the "**Buyer**") enter into a contract of definitive cession of Environmental Credits with the Foundation, on the terms below. These Terms apply together with the Foundation's General [Terms and Conditions](/docs/terms/terms-and-conditions) (the "Website Terms") and [Privacy Policy](/docs/terms/privacy-policy); in case of conflict regarding the purchase of Credits, these Terms prevail.
1.4. **Buyers and scope.** These Terms govern every purchase of Environmental Credits made on the Carrot platform, by consumers (individuals, or whoever acquires as final recipient) and by businesses (legal entities). Other products and services offered on the platform — such as memberships, data and API access, and certification services based on the Carrot Network's verified data (for example, zero-landfill certification, product passports evidencing recycled-content use, inset tracking, or scope-3 hauling documentation) — are contracted under their own separate terms, are not sales of Credits, and do not by themselves confer Environmental Claims; nothing in these Terms governs them, and their contracting does not alter the nature of the Credit purchase under Clause 3. Provisions addressed to the "consumer Buyer" (in particular Clause 7) apply only where consumer-protection rules are applicable. Individually negotiated corporate purchases may additionally be governed by a master B2B agreement, which supplements and, where it so provides, prevails over these Terms for that transaction.
## 2. Definitions [#2-definitions]
* "**Environmental Credit**" or "**Credit**": an intangible, book-entry, individualized asset representing a verified environmental contribution — (i) a "**Recycling Credit**" (**TRC**): a determined mass of waste effectively recycled or reused, verified under an approved Methodology; or (ii) a "**Carbon Credit**" (**TCC**): one metric tonne of CO₂-equivalent emissions reduced or removed, verified under an approved Methodology. For Credits under Clause 5.4, "approved Methodology" includes the applicable third-party standard or methodology there designated.
* "**Carrot Registry**": the book-entry registry maintained and operated by the Foundation, under Swiss law, from its seat in Switzerland, in which Credits are issued, recorded, transferred, and retired, and in which Credits are situated. The Carrot Registry uses distributed-ledger (blockchain) technology as its form of record-keeping and proof of integrity: Credits are recorded as digital ("tokenized") registry entries — the origin of the "T" in the TRC and TCC acronyms. Tokenization is the registry's form of book-entry recording; it does not make a Credit a cryptocurrency, a means of payment, or a financial instrument. The Carrot Registry records the holder's own title in the manner of a register of ownership; the Foundation acts as issuer and registry operator, not as depositary, custodian, or safekeeper of assets for the holder.
* "**Account**": the holder's account on the Carrot platform, in which Credits in Registry Holding and Credits already retired in the holder's name are recorded, with the corresponding Certificates.
* "**Registry Holding**": the state of a Credit owned by the holder, not yet retired, recorded in the holder's Account and capable of Retirement or Transfer under Clause 6.
* "**Transfer**": the definitive cession of a Credit in Registry Holding to another Account holder, recorded in the Carrot Registry (Clause 6).
* "**Retirement**": the definitive and irreversible cancellation of a Credit in the Carrot Registry — or, for Credits under Clause 5.4, in the applicable third-party registry — in the name of the designated beneficiary, which consumes the Credit and is the sole act that entitles the beneficiary to report the corresponding environmental contribution ("**Environmental Claims**").
* "**Certificate**": the document issued by the Foundation after Retirement, identifying the beneficiary, quantity, type, vintage, lot, and the public verification reference (including the associated data identifiers — RecycledID for TRC, GasID for TCC), together with any non-transferable digital acknowledgment (receipt token) issued to the Buyer or beneficiary, which serves solely as evidence of Retirement and confers no rights, value, transferability, or function beyond such evidence.
* "**Methodologies**": the measurement, reporting, and verification (dMRV) methodologies approved within the Carrot Network.
* "**holder**": any person recording Credits in an Account, whether acquired by purchase or by Transfer. Opening an Account requires acceptance of these Terms, which bind every holder.
* "**Delivery**": the recording or Retirement of Credits under Clause 5.
## 3. Nature of the transaction — what you buy (and what you do not buy) [#3-nature-of-the-transaction--what-you-buy-and-what-you-do-not-buy]
3.1. The purchase governed by these Terms is the definitive acquisition of an intangible asset (the Credit), destined for environmental contribution through Retirement — immediate or future — in the name of the Buyer or of a beneficiary the Buyer designates within the limits of these Terms.
3.2. **What the purchase is not:** (i) it is not a provision of services; (ii) it is not an investment, security, public offering, bond, equity interest, or right to income — the Credit confers no expectation of profit, and the Foundation promises no liquidity, repurchase, or appreciation; (iii) it is not a cryptocurrency or a means of payment; (iv) it confers no rights over the Foundation, the Carrot Network, or their intellectual property.
3.3. **Purpose of contribution.** The value of the Credit is realized through its Retirement. Registry Holding and Transfer (Clause 6) exist to give flexibility of use — including the Buyer's own reporting calendars — and are not an invitation to speculation. The Foundation's commercial communication is not investment advice. The Carrot Registry, the Methodologies, and the public verification pages are open infrastructure, maintained for the network as a whole and consultable by anyone without charge; the Credit is the private, tradable asset issued on that infrastructure. The issuance, registration, and Retirement of Credits and the maintenance of the Carrot Registry are inherent attributes of the Credits and of the Foundation's role as issuer and registry operator; they are not services rendered to the Buyer, and no part of the price is consideration for them. The Credits sold derive from environmental claims exclusively and irrevocably assigned to the Foundation by the network's participants under the network terms; the Foundation sets Credit prices at its sole discretion, and no participant, Buyer, or other person is entitled to have Credits offered at any particular price. Distributions of sale proceeds to participants are governed by the network terms, not by these Terms.
3.4. **Voluntary claims; no corresponding adjustment.** Credits are sold for voluntary Environmental Claims. They are not internationally transferred mitigation outcomes (ITMOs) under Article 6 of the Paris Agreement; no corresponding adjustment by any state is provided, procured, or implied; and no Credit is a compliance instrument under any emissions trading or compliance system.
3.5. **Professional resale only by accreditation.** The intermediation, distribution, or professional resale of Credits — including by platforms that acquire in order to resell — is permitted only under a specific accreditation agreement with the Foundation, which governs the intermediary's obligations toward its customers and the rules of the countries where it operates. These Terms do not authorize any public offering of Credits by third parties.
## 4. Purchase, price, and payment [#4-purchase-price-and-payment]
4.1. Purchases are made on the Carrot platform upon acceptance of these Terms at checkout.
4.2. **Price and taxes.** The price is the one displayed at checkout, in the currency there indicated, with applicable taxes identified ("taxes included" or itemized, as the case may be). Taxes, charges, or payment-method costs borne by the Buyer (for example, IOF on international transactions for buyers in Brazil) are disclosed at checkout or charged by the card issuer or payment provider, as applicable law provides. For consumers, the purchase of Credits is not deductible for income-tax purposes and is not a charitable donation.
4.3. **Payment methods:** those available at checkout (card, PIX, bank transfer, or others), processed by payment service providers. The purchase is confirmed upon payment approval. For purchases paid by bank transfer, the sale completes upon credit of cleared funds to the Foundation's account, and the Credits are recorded in the Buyer's Account (or retired, per the chosen mode) within 5 (five) business days of confirmed funds clearing, unless a master B2B agreement provides a different schedule.
4.4. **Purchase documents:** the Buyer receives the Foundation's invoice and, where applicable, the corresponding Brazilian electronic fiscal document, plus the Certificate whenever Retirement occurs.
4.5. **Chargebacks.** If a payment is reversed or charged back, the Foundation may suspend delivery, Transfers, Retirements, and Certificate issuance related to the affected purchase while the reversal is pending, and may treat an upheld reversal as termination of the purchase. In that case: for Credits from that purchase still in Registry Holding, cancellation of the Credits settles the matter and no price remains due for them; for Credits already retired or transferred before the reversal, the corresponding price remains due — all without prejudice to non-waivable consumer rights.
4.6. **Promotional credits.** Free or promotional Credits are governed by the specific campaign rules published with each campaign.
4.7. **Buyer identification and domicile.** Purchase, Registry Holding, and Transfer require registration with truthful, complete, and current data. The Buyer declares their country and address of domicile and authorizes the Foundation to use payment data and IP/geolocation to determine the applicable tax jurisdiction and the applicable version of these Terms. The Buyer warrants the accuracy and currency of this information.
## 5. Delivery: immediate Retirement or Registry Holding [#5-delivery-immediate-retirement-or-registry-holding]
5.1. At checkout, the Buyer chooses between:
**(a) Immediate Retirement** — upon payment confirmation, the Foundation records the Credits in the Carrot Registry as acquired by the Buyer and, immediately and as part of the same registry settlement, executes the Buyer's express Retirement instruction (Clause 7.3), retiring the Buyer's Credits in the name of the Buyer or of the beneficiary the Buyer designates. Title passes to the Buyer upon the registry recording; Retirement is the consumption of the Buyer's own Credits pursuant to the Buyer's instruction. No separate fee is charged for Retirement.
**(b) Registry Holding** — the Credits are recorded in the Buyer's Account, for future Retirement (at any time, on the Buyer's instruction, in the Buyer's name or that of an identified designated beneficiary) or Transfer under Clause 6.
5.2. In either mode, the Account displays the Credits with type, quantity, lot, and vintage. Once Retirement occurs, the Foundation issues the Certificate and makes the public verification reference available in the Carrot Registry. Retirement is definitive and irreversible.
5.3. Credits in Registry Holding do not confer Environmental Claims (Clause 2, "Retirement") — reporting the contribution requires Retirement.
5.4. **Credits linked to third-party registries and standards.** The Foundation may issue and sell Credits under third-party methodologies, standards, or programs, or linked to credits issued in third-party registries (for example, international carbon certification programs and registries). Credits issued and maintained in third-party registries are delivered exclusively in the manner of Clause 5.1(a), applied mutatis mutandis to the origin registry — immediate Retirement in the origin registry, in the name of the designated beneficiary — and are not eligible for Registry Holding or Transfer in the Account. The Foundation designates at the point of sale, per Credit type, the available delivery modes and the registry in which Retirement occurs. The Foundation may enable segregated holding of third-party-registry credits in the future, through an update of these Terms.
## 6. Registry Holding and Transfer [#6-registry-holding-and-transfer]
6.1. The holder may keep Credits issued in the Carrot Registry in Registry Holding for as long as they wish, retire them at any time (in their own name or that of an identified third party they designate), and transfer them under this Clause. Credits linked to third-party registries follow Clause 5.4.
6.2. **Transfer conditions:** (i) the transferee must hold an Account with approved registration and verification (KYC/KYB); (ii) transfers to sanctioned persons or in violation of anti-money-laundering rules are prohibited, and the Foundation may refuse or suspend transfers in those cases; (iii) the Transfer is recorded in the Carrot Registry and is definitive — the transferor loses all rights over the transferred Credit; (iv) any payment between transferor and transferee is exclusively their relationship, outside the platform — the Foundation does not intermediate, does not price, and does not guarantee liquidity or a counterparty; (v) the Foundation may charge a fixed administrative fee for processing a Transfer, disclosed in advance — never a fee calculated on the value of any exchange between the parties.
6.3. **The Foundation operates no market.** The platform is not an exchange, organized over-the-counter facility, or trading system for Credits; there is no order book, no public price formation, no quotations, and no intermediation or matching of dealings between holders by the Foundation.
6.4. **Accredited intermediaries.** The acquisition of Credits for professional resale follows Clause 3.5 (accreditation agreement). The accredited intermediary is fully responsible, toward its customers, for the obligations of the resale — including consumer and tax rules of the countries where it operates.
## 7. Right of withdrawal (consumer Buyers) [#7-right-of-withdrawal-consumer-buyers]
7.1. The consumer Buyer may exercise the right of withdrawal within the legal period of their domicile — in Brazil, 7 (seven) calendar days from purchase confirmation (Article 49 of the Consumer Defense Code); in the European Economic Area and the United Kingdom, 14 days from the day the contract is concluded (purchase confirmation), subject to Clause 7.3 — through the support channel (Clause 1.2), with identity confirmation and immediate acknowledgment of receipt of the request. Consumers in the EEA and the UK may use the [model withdrawal form](/docs/terms/withdrawal-form), but it is not obligatory; refunds are made without undue delay and in any event within 14 days of the withdrawal request. If the law of your country provides no withdrawal right, purchases are final once completed — Clause 7.4 and our support policy still apply.
7.2. **Effects, according to the state of the Credit at the time of the request:**
(a) **Credits in Registry Holding:** the purchase is undone — the Credits return to the Foundation and the full amount is refunded by the same payment method, immediately, monetarily adjusted where required by law.
(b) **Credits retired at the Buyer's express request** (Clauses 5.1(a) and 7.3): for consumers whose domicile preserves the withdrawal right in this case (including Brazil), the Foundation refunds the full amount paid, by the same payment method, monetarily adjusted where required by law; the retired Credit does not return — it is absorbed by the Foundation. Support may not refuse a refund requested within the legal period.
(c) **Credits transferred to a third party:** the refund is conditioned on the return of the Credits to the Buyer's Account before exercise — if return is not possible, the withdrawal produces no refund, without prejudice to the consumer's non-waivable legal rights.
7.3. **Consent to immediate execution.** By choosing immediate Retirement at checkout, the Buyer declares, through a separate, dedicated checkbox that is never pre-ticked and must be actively checked, that: (i) they request that the Foundation retire the Credits immediately upon payment confirmation, before the end of any withdrawal period; (ii) they understand that they are acquiring a Credit that will be immediately and irreversibly retired and can no longer be transferred or returned; and (iii) they acknowledge that, once Retirement occurs, they lose their right of withdrawal — except where the law of their domicile preserves it (in Brazil, Clause 7.2(b) applies). In the European Economic Area and the United Kingdom, this express consent and acknowledgment extinguish the right of withdrawal upon full performance (Articles 16(a) and 16(m) of Directive 2011/83/EU and their UK equivalents, whichever applies). The declaration is recorded with date, time, content, and Terms version, and the purchase confirmation restates this consent and acknowledgment on a durable medium (e-mail).
7.4. After the legal period, the transaction is consummated. Later requests are handled under the Foundation's support policy, which may, at its discretion and as a commercial courtesy, offer equivalent credits — without this constituting a legal obligation.
7.5. **No application to business purchases.** The withdrawal right in this Clause is a consumer right and does not apply to purchases made by businesses in the exercise of their professional activity, except where a legal entity qualifies as a consumer (final recipient) under applicable law and case law.
## 8. Retirement, public proof, and personal data [#8-retirement-public-proof-and-personal-data]
8.1. Retirement is recorded in the Carrot Registry with a publicly consultable reference (the Certificate page), which proves: beneficiary, quantity, type, vintage, lot, and date.
8.2. **Beneficiary privacy.** In the public record, an individual is identified by civil name only with their authorization (opt-in); otherwise, by a non-sensitive identifier. The private Certificate contains the full identification. Legal entities are identified by corporate name and registration number.
8.3. Personal data is processed in accordance with the [Privacy Policy](/docs/terms/privacy-policy) and applicable law (including the Swiss FADP and, where applicable, the LGPD for data subjects in Brazil and the GDPR), including the published information on international data transfers.
## 9. Registration, identification, and anti-money-laundering [#9-registration-identification-and-anti-money-laundering]
9.1. The Foundation may request information and documents proportional to the value and profile of the operation (KYC/KYB/AML) and may refuse or undo operations that violate international sanctions or anti-money-laundering rules. Verification may be performed by payment or identity providers on the Foundation's behalf.
9.2. The Buyer declares that: (i) they are over 18 and legally capable (or a legal entity duly organized, acting through an authorized representative); (ii) the funds used are of lawful origin; (iii) they are not on sanctions lists (UN, EU, US/OFAC, Swiss SECO) and are not domiciled in an embargoed jurisdiction; (iv) they purchase in their own name (or that of the organization they represent) and for their own account.
## 10. Warranties and liability [#10-warranties-and-liability]
10.1. The Foundation warrants that the Credits sold: (i) exist and are validly issued in the Carrot Registry in accordance with the Methodologies or, for Clause 5.4 Credits, validly issued in the designated third-party registry under the designated standard; (ii) are owned by the Foundation and free of encumbrances at delivery; (iii) have not been double-sold or double-counted; and (iv) will be recorded, transferred, and retired as provided in these Terms.
10.2. The Foundation is liable for defects of the transaction under applicable law, including the Consumer Defense Code where applicable. Nothing in these Terms excludes or limits consumer rights established by mandatory consumer-protection laws.
10.3. **IN RELATIONSHIPS NOT SUBJECT TO MANDATORY CONSUMER-PROTECTION LAWS, THE FOUNDATION'S TOTAL LIABILITY IS LIMITED TO THE AMOUNT EFFECTIVELY PAID BY THE BUYER IN THE TRANSACTION, EXCEPT IN CASES OF FRAUD, WILFUL MISCONDUCT, OR GROSS NEGLIGENCE.** Some jurisdictions do not allow the exclusion or limitation of certain damages or warranties; in those jurisdictions this limitation applies only to the extent permitted by law.
10.4. The Foundation will use reasonable efforts to keep the platform and the Carrot Registry available and intact, but does not answer for temporary unavailability caused by maintenance, force majeure, or third-party failures, in which case the periods in these Terms are suspended for the corresponding time. The Foundation makes no representation as to any value or price of Credits at any time and is not liable for the consequences of the holder's decision to hold rather than retire Credits, nor for losses arising from Transfers between holders.
## 11. Environmental Claims and use of the Certificate [#11-environmental-claims-and-use-of-the-certificate]
11.1. Only after Retirement may the beneficiary report the corresponding Environmental Claims (reports, institutional communication, fulfillment of voluntary commitments), always with reference to the Certificate and without altering its content. Reporting a contribution based on Credits in Registry Holding is prohibited. Use of the Certificate by a designated beneficiary constitutes acceptance of this Clause 11.
11.2. The beneficiary's public statements based on Credits must comply with the laws applicable to such statements — including consumer-protection and environmental-claims rules and disclosure statutes where applicable (such as the US FTC Green Guides and California AB 1305) — and must not report the same Retirement under more than one program, standard, or claim. Every Environmental Claim must be presented as a voluntary claim, without any corresponding adjustment under Article 6 of the Paris Agreement having been made, procured, or represented. The Foundation maintains public per-project verification pages substantiating origin, methodology, verification, and retirement status.
11.3. The holder acquires no rights over trademarks, software, Methodologies, or any intellectual property of the Foundation or the Carrot Network, beyond the use of the Certificate under Clause 11.1. The beneficiary may reproduce the Certificate and public registry references in sustainability reports, regulatory filings, assurance processes, and stakeholder communications.
## 12. Recurring purchases [#12-recurring-purchases]
12.1. The Buyer may opt into a recurring Credit purchase plan, authorizing periodic charges destined, each cycle, to the acquisition of Credits with the chosen destination (immediate Retirement or Registry Holding, Clause 5.1). A recurring purchase is the periodic acquisition of an asset — not the contracting of a subscription or continuous-compensation service.
12.2. Each charge constitutes an autonomous purchase, individually documented. The price of each cycle is the one in force on the charge date; changes are communicated at least 30 (thirty) days in advance and apply only to future cycles.
12.3. Cancellation at any time, through the Account or the support channels, effective from the following cycle — without penalty. The amount, frequency, and cancellation method are disclosed before enrollment, and cancellation is available online.
12.4. The right of withdrawal (Clause 7) applies autonomously to each recurring charge.
12.5. A failed charge suspends the corresponding cycle's delivery, with no obligation of the Foundation until payment is confirmed.
## 13. Taxes [#13-taxes]
13.1. Each party bears the taxes the law attributes to it. The Foundation bears the Swiss taxes on its activity and, where required, collects Brazilian taxes on consumption (CBS/IBS) as a registered non-resident supplier, issuing the corresponding fiscal document.
13.2. Prices are exclusive of value-added, sales, or consumption taxes except as displayed at checkout; where the Foundation is required by law to collect such taxes, they are identified on the checkout screen and stated on the invoice or fiscal document. Amounts collected under a split-payment or self-assessment mechanism are accounted for under that mechanism.
13.3. For business Buyers, the specific allocation of taxes, withholdings, and any gross-up in individually negotiated transactions may be detailed in the master B2B agreement or in the invoice conditions.
13.4. **Resale and transfer:** taxes on Transfers between holders and on resale by accredited intermediaries are the exclusive responsibility of the respective parties, under the law of each jurisdiction.
## 14. Amendments; entire agreement; assignment [#14-amendments-entire-agreement-assignment]
14.1. The Foundation may update these Terms at any time, publishing the new version and date. The version applicable to each purchase is the one accepted at the respective checkout, archived and available to the Buyer. Changes affecting Credits already in Registry Holding take effect only 30 (thirty) days after individual notice (e-mail and Account); until then, the holder may retire or transfer the Credits under the previous version. Changes required by law may take effect earlier, with notice. For purchases under a master B2B agreement, the applicable version is the one attached to or designated in that agreement.
14.2. **Entire agreement.** These Terms, the documents expressly referred to in them, and the essential information of the checkout constitute the entire agreement on the purchase. Technical materials, white papers, protocol documentation, and marketing communications are informative and do not form part of the contract, unless expressly incorporated — without prejudice to laws under which public statements and advertising are binding on the Foundation or form part of what the Buyer is entitled to receive.
14.3. **Assignment.** The Buyer may not assign their contractual position under these Terms without the Foundation's prior written consent. The Transfer of Credits is governed by Clause 6, not by this Clause.
## 15. Governing law, forum, and language [#15-governing-law-forum-and-language]
15.1. These Terms are governed by Swiss law, subject to the public-order and consumer-protection rules of the Buyer's domicile — in Brazil, in particular the Consumer Defense Code — which prevail where mandatory.
15.2. Where mandatory law gives a consumer the courts of their own domicile — including consumers domiciled in Brazil and consumers domiciled in states bound by the Lugano Convention — that forum prevails. In all other cases, the courts of Zug, Switzerland have exclusive jurisdiction.
15.3. The parties will seek amicable resolution through the support channels before formal measures.
15.4. **Language.** For Buyers domiciled in Brazil, the Portuguese version of these Terms governs; for all other Buyers, this English version governs. Translations are provided for convenience.
# Platform Usage Agreement
{/* cspell:words Fndn LGPD ANPD USDC stablecoin Sielva Gubelstrasse McKee */}
> **About this document**
>
> This is the instrument that participants accept electronically during registration on the Carrot platform, under Clause 10. The version published here is 1.4, currently in force.
>
> The global Terms and Conditions, the Privacy Policy, the Terms and Conditions for the Purchase and Sale of Tokenized Environmental Credits, and the Rewards Distribution Policy form part of this Agreement by reference, in the order of precedence set out in Clause 1.3.
> This English version of the Platform Usage Agreement (Brazil), version 1.4, is legally binding. In the event of any divergence of interpretation between this translation and the Portuguese original, the Portuguese version prevails.
**Version 1.4 — March 2026**
# PLATFORM USAGE AGREEMENT [#platform-usage-agreement]
Circular Economy and Environmental Assets Network
## UNDERSTAND WHAT THIS AGREEMENT MEANS [#understand-what-this-agreement-means]
**YOU do...** · **CARROT does...** · **How are you rewarded?**
You share data about your environmental actions (e.g., collection, sorting, and recycling) on the Carrot platform through the Network Integrator, an intermediary traceability platform accredited by Carrot.
Carrot validates those actions, turns them into tokenized Environmental Credits (Recycling Credit or Carbon Credit), and makes them available for sale on regulated or voluntary markets, whether domestic or international.
When a sale takes place, you automatically receive your share of the proceeds, according to your role in the chain, without having to sell anything yourself and at no cost.
> **✓ What this means for you**
>
> * You pay nothing to use the platform.
> * You do not have to sell anything yourself.
> * You may leave Carrot's credit program at any time, with no penalty.
> * Your personal data is protected by encryption and is not publicly exposed without your authorization.
## IDENTIFICATION OF THE PARTIES [#identification-of-the-parties]
### THE USER [#the-user]
User: the individual or legal entity identified by the data provided and validated in the registration and identity verification process (KYC/KYB) carried out on the Carrot platform, operated by Carrot Foundation. The information provided by the User in the registration form — including, without limitation, full name or corporate name, CPF or CNPJ, address, email, contact details, and other identification information, as well as any attached documents — forms part of this Agreement by reference, as if transcribed herein, and makes up the inseparable body of the contractual instrument, the User being fully aware that any subsequent registration changes duly recorded on the platform will automatically become part of this Agreement.
### THE PLATFORM [#the-platform]
**CARROT FOUNDATION**
Swiss Foundation — Articles 80 et seq. of the Swiss Civil Code.
Registered seat: Sielva Management SA, Gubelstrasse 11, Zug 6300, Switzerland.
Tax ID: UID# CHE-152.448.302.
President: Ian Clayton McKee.
[legal@carrot.eco](mailto:legal@carrot.eco)
Carrot and the User (jointly, the "Parties") accept and establish the following terms and conditions:
## 1. PURPOSE [#1-purpose]
> **✓ What this means for you**
>
> This agreement governs how you use the Carrot platform and how the environmental partnership works — from your first record through to receiving your rewards.
1.1 This Agreement governs the User's access to and use of the Digital Environmental Verification Platform (VDA/dMRV), including the recording of circular economy actions, the issuance of Tokenized Environmental Credits (CRT/CCT), and the distribution of Environmental Rewards to eligible Participants.
1.2 The User acknowledges that the Network brings together different profiles — Generators, Haulers, Processors, Recyclers/Final Destination Facilities, Integrators, and Auditors — and that the permissions, obligations, and Reward percentages for each profile are detailed in the platform's Terms and Conditions of Use (T\&C) and in the Rewards Distribution Policy, incorporated into this Agreement by reference.
> **✓ What this means for you**
>
> Adherence by Reference: Following the global standard among technology companies, this instrument formalizes our union, while operational details and technical methodologies remain in the T\&C ([https://docs.carrot.eco/en/docs/terms/terms-and-conditions](https://docs.carrot.eco/en/docs/terms/terms-and-conditions)). This allows the ecosystem to evolve without constant contractual bureaucracy, enabling the ecosystem to scale.
1.3 The documents forming part of this Agreement prevail in the following order in the event of conflict: (a) T\&C ([https://docs.carrot.eco/en/docs/terms/terms-and-conditions](https://docs.carrot.eco/en/docs/terms/terms-and-conditions)); (b) Terms and Conditions for the Purchase and Sale of Tokenized Environmental Credits ([https://docs.carrot.eco/en/docs/terms/credit-sales-terms](https://docs.carrot.eco/en/docs/terms/credit-sales-terms)); (c) this instrument; (d) Privacy Policy ([https://docs.carrot.eco/en/docs/terms/privacy-policy](https://docs.carrot.eco/en/docs/terms/privacy-policy)) and Rewards Distribution Policy ([https://docs.carrot.eco/en/docs/standard/policies/rewards-distribution](https://docs.carrot.eco/en/docs/standard/policies/rewards-distribution)).
## 2. ADHERENCE TO THE TERMS AND CONDITIONS [#2-adherence-to-the-terms-and-conditions]
> **✓ What this means for you**
>
> By signing this Agreement, you confirm that you have read and understood the platform's rules.
>
> When the rules change, you will be notified by email in advance. If you do not agree, you may leave at no cost.
2.1 The User declares that they have read, understood, and fully accepted: (a) the Terms and Conditions of Use ([https://docs.carrot.eco/en/docs/terms/terms-and-conditions](https://docs.carrot.eco/en/docs/terms/terms-and-conditions)) and (b) the Terms and Conditions for the Purchase and Sale of Tokenized Recycling and Carbon Credits ([https://docs.carrot.eco/en/docs/terms/credit-sales-terms](https://docs.carrot.eco/en/docs/terms/credit-sales-terms)).
2.2 The Platform may update this Agreement or the documents incorporated into it to reflect operational, technological, or legal changes. The User will be notified by email at least 15 (fifteen) days before the changes take effect.
2.3 Should the User disagree with any update, they may close their account at no cost before the effective date. Failure to respond will be interpreted as acceptance.
2.4 Official communications will take place by email. The User undertakes to keep their email address up to date.
2.5 In the KYC/KYB process (Know Your Customer/Know Your Business), the User must provide truthful and complete identification information. In the case of a legal entity, the legal representative must evidence their authority to represent it.
## 3. HOW YOUR ENVIRONMENTAL IMPACT BECOMES AN ASSET OF VALUE [#3-how-your-environmental-impact-becomes-an-asset-of-value]
> **✓ What this means for you**
>
> For your environmental impact to have market value, we need to demonstrate to credit buyers that the system for validating, verifying, and measuring credit issuance is complete and accurate, and that the impact generated is measured conservatively.
>
> It is also essential to credit integrity that double counting be impossible — that is, the mass sent to Carrot's credit generation program cannot also be sent to another credit generation system.
>
> That is what ensures the buyer pays for it — and that you receive your share. For this reason, when you record an action on the platform, you transfer to us exclusively the right to issue and sell the credit for that specific action.
>
> You remain free to leave the platform whenever you wish. What you may not do is record the same action elsewhere — that would destroy the value of that specific credit, as well as the reputation of the system, harming every other participant.
3.1 For your environmental impact to have market value, the Platform must be the only entity authorized to issue the credit associated with each recorded action. That exclusivity is what assures the buyer that the credit is unique, verified, and of unimpaired integrity — and what assures you that you will receive your share of the proceeds. For this reason, when recording an action on the platform, the User transfers to the Platform, exclusively and irrevocably, the right to issue and sell the Tokenized Environmental Credit (CRT/CCT) corresponding to that specific action, including the environmental reporting rights (by means of retired credits) and the Environmental & Social Claims arising from it, pursuant to Section 4 of the T\&C. From the retirement of the credit onward, the buyer takes ownership of the right to declare the environmental offset (Environmental Claim).
3.2 This transfer of rights is restricted in scope to the recorded action: the User assigns the right over the credit for that action — not over their company, their future operations, or any other asset.
3.2.1 The transfer of rights set out in this Clause 3 neither reflects nor implies any present monetary value in the data or environmental actions shared by the User. The commercial value of any Environmental & Social Claim arises exclusively from the Platform's application of the Methodology, the validation of the circular economy action, the issuance of the corresponding credit or token, and its actual sale to a Token Buyer — a cycle that may or may not be completed. No individual User holds title over any MassID, since the environmental gain represented by each credit results from the collective contribution of multiple Participants in the chain of custody, each receiving only their proportional share of the proceeds, in accordance with the Rewards Distribution Policy, when an actual sale occurs. The exclusive and irrevocable nature of the transfer serves exclusively to preserve the integrity of the credit program, for the protection of all Participants, Token Buyers, and the ecosystem as a whole. No liability falls upon the Platform solely by reason of this transfer should the Token not be issued or sold in connection with the respective circular economy action.
3.3 The Carrot Platform, after validating the data of the Circular Economy action (MassID, ProductID) and confirming it against official local documents (e.g., the Waste Transport Manifest (MTR) and/or equivalent documents), holds the exclusive right to issue and sell the credits (CRT/CCT) related to the MassID. Traceability of the mass, MassID, identifying the participants in the final route through to a recycler audited and accredited by Carrot Foundation, and evidence of final destination via MTR with data verified by Carrot's system are the sole requirements for the validity of issuance in Brazil. The sale of the credits is not conditioned on the prior onboarding of Chain of Custody Participants other than the Recycler — only on the identification of the participants in the final route. (Note: the rewards allocated to the remaining participants will remain available for a set period.)
3.4 Recording the same environmental action in another certification and credit issuance system — in whole or in part — constitutes double counting. This compromises the integrity of the credit sold to the buyer and of Carrot's credit program. It harms the other participants in the network and subjects the User to immediate suspension, return of amounts received, and civil and criminal liability, pursuant to item 11 of the T\&C.
3.5 Closure of the account by the User does not affect the transfer of rights carried out over actions already recorded and validated before closure. The corresponding credits remain valid and the rewards will be distributed as normal.
## 4. YOUR ENVIRONMENTAL REWARDS · HOW THE FINANCIAL RETURN WORKS [#4-your-environmental-rewards--how-the-financial-return-works]
> **✓ What this means for you**
>
> When a buyer acquires the credit generated by your action, you automatically receive your share of the proceeds — without having to do anything beyond recording the data correctly.
>
> You have 90 days to provide a digital wallet to receive the rewards and withdraw the amount.
>
> Everything runs through a smart contract, with no intermediaries.
>
> How much you receive depends on your role in the chain and on the sale value of the credit — the percentages are in the Rewards Distribution Policy.
> **⚖ Legal nature of the Reward — with tax effect**
>
> Rewards constitute a distribution of a share of the proceeds obtained by the Platform on the sale of the Credits to third-party buyers.
>
> Rewards do NOT constitute, for any legal or tax purpose: (a) consideration for a service rendered by the User; (b) remuneration, salary, or professional fees; (c) proceeds from the sale of an asset or right by the User; nor (d) the User's own operating revenue.
>
> Each party is individually responsible for the taxes due from it on the amounts received, pursuant to Clause 6.
4.1 The Platform will distribute to the User, automatically by means of Smart Contracts, a share of the proceeds obtained on the sale of the Environmental Credits, in accordance with the percentages set out in the Rewards Distribution Policy in force on the date of each sale ([https://docs.carrot.eco/en/docs/standard/policies/rewards-distribution](https://docs.carrot.eco/en/docs/standard/policies/rewards-distribution)).
4.2 Rewards constitute, for all legal and tax purposes, a distribution of the proceeds of a commercial transaction carried out by the Platform — not consideration for a service rendered by the User, proceeds of a sale by the User, or remuneration of the User. This qualification is binding between the Parties.
4.3 The right to a Reward is conditioned upon: (a) completion of onboarding with KYC/KYB approval; (b) full acceptance of this Agreement and the documents incorporated into it; and (c) validation of the environmental action data under the applicable methodology.
4.4 The withdrawal period is 90 (ninety) calendar days from the date the amount is made available in the Smart Contract. Once that period elapses without redemption, the amount will be transferred to the Community Impact Pool, extinguishing the User's right over that amount.
4.5 The Platform does not guarantee any minimum Reward amount or any set timeframe for sales to occur. Rewards are conditioned upon the Environmental Credits actually being sold to buyers. Should the Credits not be sold, no Reward will be due, and the User will have no right to any compensation, reimbursement, or consideration by reason of the absence of a sale. The User declares awareness that the transfer of rights set out in Clause 3 does not, in itself, create a vested right to receive any amount.
4.6 Rewards will be paid in USDC, in accordance with the Distribution Policy. The User is responsible for maintaining an active and compatible digital wallet. The Platform is not liable for loss of access to the wallet.
**Special responsibility of the Recycler / Final Destination Facility**
4.7 The accredited Recycler acting as Final Destination Facility and Project Developer assumes responsibility for the final destination and treatment of the waste and for actively inviting the other participants in the chain (Generator, Hauler, Processor) to complete onboarding and redeem their Rewards within the 90-day period, processing their data in compliance with the LGPD.
## 5. PERSONAL DATA PROTECTION — LGPD [#5-personal-data-protection--lgpd]
> **✓ What this means for you**
>
> We collect only the data needed to validate your identity, record your actions, verify and certify credits, and transfer your Rewards.
>
> Sensitive data is kept on encrypted servers. No data is published without your authorization.
>
> You may access, correct, or request deletion of your data: [operations@carrot.eco](mailto:operations@carrot.eco).
The Parties warrant compliance with Law No. 13.709/2018 (LGPD) and undertake to process personal data exclusively for the purposes of this Agreement.
**5.1 Roles under the LGPD**
5.1.1 For the data the User enters about their own operations (MassIDs, generation data, employee information), the User acts as Controller and the Platform as Processor.
5.1.2 For the data required for KYC/KYB, credit issuance, and Reward distribution, the Platform acts as an independent Controller.
5.1.3 Neither party will be held liable for acts or breaches of data protection legislation committed by the other party, its agents, and/or contractors. To understand how your personal data is collected, processed, stored, and protected by the Platform, consult our Privacy and Data Protection Policy, available at ([https://docs.carrot.eco/en/docs/terms/privacy-policy](https://docs.carrot.eco/en/docs/terms/privacy-policy)), drawn up in compliance with Law No. 13.709/2018 (LGPD).
**5.2 Obligations of the Parties**
* Promote a culture of data protection among employees.
* Adopt security measures capable of protecting data against unauthorized access.
* Delete or anonymize data once the purpose has been achieved or the Agreement has ended.
* Maintain an incident response plan and an active data governance program.
**5.3 Specific data processing**
5.3.1 The User consents to their identification data being used for: (i) identification and validation of participants (KYC/KYB); (ii) chain of custody traceability; (iii) credit issuance; (iv) Reward distribution; (v) compliance with legal obligations; and (vi) public recognition of the organization's environmental impact, pursuant to Section 7A of the Global Terms and Conditions (Impact Recognition Program), the User being able to revoke that authorization at any time by written notice to [legal@carrot.eco](mailto:legal@carrot.eco).
5.3.2 Data of Generators and Haulers will be masked in public interfaces, visible only to the Platform and to accredited Auditors. Public visibility depends on express consent given at onboarding.
5.3.3 The Platform implements TLS/SSL encryption in transit and AES-256 at rest. Identifying data is not written directly on-chain — hashing is used for traceability without exposing identity.
5.3.4 The User's failure to comply with LGPD obligations may give rise to immediate termination of this Agreement.
5.3.5 In the event of a security incident carrying material risk, the Platform will notify the User and the ANPD within the statutory deadlines.
## 6. TAX RESPONSIBILITY [#6-tax-responsibility]
> **In plain language**
>
> Each party is responsible for its own taxes. The Platform neither withholds nor collects tax on the User's behalf — except where the law expressly requires it.
>
> The Reward you receive is not a salary and is not a service invoice. But income tax may apply depending on the amount and on your tax situation.
>
> We strongly recommend that you consult an accountant or a tax lawyer.
6.1 Each Party is exclusively responsible for meeting its tax obligations before the tax authorities of its jurisdiction.
6.2 Rewards constitute a distribution of the proceeds of a third party's commercial transaction — neither service revenue nor the proceeds of disposing of an asset. That qualification does not exclude the possible levy of taxes on the accretion to the User's assets, the assessment of which is the User's exclusive responsibility.
6.3 The reward is distributed to all participants in the same format globally, using the digital currency (stablecoin) USDC deposited in the participant's digital wallet. The User declares awareness that transactions involving crypto assets may be subject to reporting to the Brazilian Federal Revenue Service (Normative Instruction RFB No. 1.888/2019 and amendments) and to income tax on capital gains, where applicable.
6.4 Should the user choose not to receive their rewards, the amount will automatically be allocated to Carrot's Community Pool, aimed at fostering the development of the circular economy. Users may also declare the allocation of their rewards to the Community Pool during onboarding or at any time, or even exchange them for retired credits for environmental offsetting, fostering the growth of the very ecosystem they take part in.
6.5 The Platform does not provide tax advice and assumes no responsibility for the User's tax obligations. The User agrees to indemnify the Platform against any liability arising from failure to meet their tax obligations.
## 7. RESPONSIBILITIES OF THE PARTIES [#7-responsibilities-of-the-parties]
> **✓ What this means for you**
>
> We are responsible for the security and functioning of the platform.
>
> You are responsible for the truthfulness of the data you enter.
>
> If something goes wrong through our fault, our liability is limited to the greater of: the rewards you received in the last 12 months, or the value of the environmental actions you transferred to us that gave rise to the problem.
>
> We are not responsible for indirect losses, loss of profits, or variation in the value of credits or tokens.
**7.1 Obligations of the Platform**
* Keep the technological infrastructure available and secure.
* Validate environmental data in accordance with the applicable methodologies.
* Issue and commercialize the Environmental Credits diligently.
* Distribute the Rewards in accordance with the Distribution Policy in force.
* Communicate any material change to the terms in advance.
**7.2 Obligations of the User**
* Provide truthful, complete, and up-to-date data.
* Not record the same environmental data in other recycling or carbon credit generation programs (Clause 3.4).
* Keep access credentials and the digital wallet secure.
* Notify the Carrot Platform of any irregularity that comes to their attention.
* Comply with the Code of Conduct set out in the T\&C.
7.3 The User accepts and acknowledges the risks related to use of the platform, as detailed in the T\&C. The Platform is not liable for risks inherent to the use of blockchain or crypto assets outside its control.
7.4 The Platform's liability for direct losses arising from its own failure is limited to the amount paid by the User to the Platform in the 12 (twelve) months preceding the event. Indirect damages, loss of profits, reputational damage, and losses from variation in the value of credits, tokens, or crypto assets are expressly excluded.
7.5 Disclosing Environmental & Social Claims for the same data to third parties constitutes double counting and is expressly prohibited, pursuant to Clause 3.4 and item 11 of the T\&C.
7.6 The Platform is not responsible for errors in the recording of circular economy actions caused by incorrect or incomplete data submitted by the User or by Network Integrators. However, the Platform is liable for direct damages caused by recording errors attributable to its own systems or processes, subject to the cap established in Clause 7.4.
## 8. GOVERNING LAW AND DISPUTE RESOLUTION [#8-governing-law-and-dispute-resolution]
> **✓ What this means for you**
>
> For your platform usage relationship in Brazil, Brazilian law applies — venue in São Paulo.
>
> For Tokenized Environmental Credits, Swiss law applies — better suited to this international financial instrument.
>
> We try to settle everything amicably before any court proceedings.
8.1 This Agreement will be governed by and construed in accordance with the laws of the Federative Republic of Brazil. The Parties elect the Central Courts of the Judicial District of São Paulo, State of São Paulo, as the venue for resolving any disputes relating to the platform usage relationship.
8.2 The issuance, transfer, and sale of Tokenized Environmental Credits are governed by Swiss legislation, applicable to Carrot Fndn as a foundation incorporated in Zug, Switzerland.
8.3 In the event of conflict between this Agreement and the Terms and Conditions (T\&C), the provisions of the T\&C will prevail, pursuant to Clause 1.3.
8.4 The Parties undertake to seek an amicable solution to any disagreement, by means of prior notice and a 30 (thirty) day period for direct negotiation, before any court proceedings.
8.5 Without prejudice to the choice of law established in Clauses 8.1 and 8.2, and in accordance with Section 21.4 of the Global Terms and Conditions (T\&C), the public policy provisions and mandatory rules of Brazilian legislation applicable to the User — including, without limitation, the Consumer Protection Code (Law 8.078/1990), the General Data Protection Law (Law 13.709/2018), and the Crypto Assets Legal Framework (Law 14.478/2022) — will apply to the extent that they cannot be set aside by agreement between the parties. The application of mandatory local rules does not affect the validity or enforceability of the remaining clauses of this Agreement, nor does it constitute a waiver of Swiss law as the law applicable to the matters the parties may freely contract on.
## 9. GENERAL PROVISIONS [#9-general-provisions]
9.1 Partial invalidity: If any clause is invalid or unenforceable, the remaining clauses stay in force. The invalid clause will be construed as closely as possible to the Parties' original intent.
9.2 Forbearance: A Party's failure to exercise its rights does not constitute waiver, novation, or precedent.
9.3 Assignment: The User may not assign this Agreement to third parties without the Platform's prior written consent. The Platform may assign rights to a successor entity, upon notice to the User.
9.4 Additional services: Upon prior notice and the User's acceptance, the Platform may charge for additional services such as data storage and circularity certification, pursuant to item 8 of the T\&C.
9.5 Entire agreement: This Agreement and the documents incorporated into it constitute the entire agreement between the Parties, superseding prior understandings on the same subject matter.
## 10. ELECTRONIC ACCEPTANCE [#10-electronic-acceptance]
10.1 Electronic Acceptance. The User's acceptance of this Agreement takes place by unequivocal electronic manifestation, consisting of the affirmative act of ticking the dedicated acceptance field on the platform, after this instrument and the other documents linked to it have been made available in full for reading, and immediately followed by the recording in the system of: (i) synchronized date and time; (ii) IP address; (iii) device and browser identifier (user agent); (iv) approximate geolocation, where available; and (v) the SHA-256 hash code of the specific version of the Agreement then in force. That manifestation is equivalent to an electronic signature for all legal purposes, pursuant to Article 10, §2, of Provisional Measure No. 2.200-2/2001, Article 4, item I, of Law No. 14.063/2020, and Article 107 of the Civil Code, and is recognized by the Parties as a valid, effective, and sufficient means of formalizing this instrument, dispensing with any other form of signature. The User may, at any time, request proof of acceptance containing the elements above through Carrot's official channels.
10.2 Signature Provider. For the purposes of this clause and of Article 784, §4, of the Code of Civil Procedure, the Platform acts as signature provider, being responsible for verifying and preserving the integrity of the electronic document by means of the technical mechanisms described in the preceding paragraph, as well as for the custody and provision, upon request by the User or a competent authority, of the corresponding audit trail.
10.3 Extrajudicial Enforcement Instrument. The Parties expressly acknowledge that this instrument, once accepted electronically in the manner set out in this clause, constitutes an extrajudicial enforcement instrument, pursuant to Article 784, item III and §4, of the Code of Civil Procedure, as worded by Law No. 14.195/2021, witnesses' signatures being dispensed with by reason of the integrity verification carried out by the signature provider indicated above.
***
Legal questions: [legal@carrot.eco](mailto:legal@carrot.eco) · Operational support: [operations@carrot.eco](mailto:operations@carrot.eco)
This document supersedes all previous versions of the Carrot Platform Usage Agreement.
# Privacy Policy
{/* cspell:words Fndn LGPD GDPR revDSG ANPD FDPIC CCPA DPRK COAF subprocessors accreditation */}
**Version 1.0 — March 2026**
Data Protection Officer (DPO): [legal@carrot.eco](mailto:legal@carrot.eco)
## 1. Introduction and Scope [#1-introduction-and-scope]
Carrot Fndn is a Swiss foundation established under Articles 80 et seq. of the Swiss Civil Code, domiciled in Zug, Switzerland (Tax ID: UID# CHE-152.448.302), which develops and operates the Carrot Network — a technology platform that combines cloud infrastructure and blockchain for tracking circular economy actions and issuing Tokenized Environmental Credits (TRC/TCC).
This Privacy and Data Protection Policy ("Policy") describes how Carrot Fndn collects, processes, stores, shares, and protects personal data, in compliance with:
* Lei nº 13.709/2018 — Lei Geral de Proteção de Dados Pessoais (LGPD);
* Resolução CD/ANPD nº 15/2024 — procedure for communicating security incidents to ANPD;
* Lei nº 14.478/2022 — Brazilian Crypto Assets Legal Framework and Central Bank of Brazil regulations applicable to Virtual Asset Service Providers (VASPs), as applicable;
* General Data Protection Regulation (GDPR — EU Regulation 2016/679), as applicable to data subjects residing in the European Economic Area;
* Swiss Federal Act on Data Protection (revDSG — in force since September 1, 2023), applicable to the Foundation's operations by virtue of its domicile in Zug, Switzerland.
This Policy applies to all Users who access the websites and subdomains operated by Carrot Fndn under the carrot.eco domain, including, without limitation: [www.carrot.eco](http://www.carrot.eco), registry.carrot.eco, store.carrot.eco, docs.carrot.eco, and my.carrot.eco, as well as any other subdomains that may be created, the Carrot Network and its smart contracts, or who interact with the Foundation in any capacity.
> **Jurisdiction Note**
>
> For purposes of the LGPD, Carrot Fndn may act as Controller or Processor of personal data, depending on the context of the operation (detailed in Section 2). Brazilian law governs the Platform usage relationship in Brazil; Swiss law (revDSG) governs the Foundation's operations and the issuance and sale of Tokenized Environmental Credits.
## 2. Roles and Responsibilities in Data Processing [#2-roles-and-responsibilities-in-data-processing]
Defining the roles of each party in data processing is essential for the proper attribution of responsibilities under art. 5, items VI and VII, of the LGPD and art. 4 of the GDPR.
### 2.1 When the User Is the Controller [#21-when-the-user-is-the-controller]
For data that the User inputs into the Platform regarding their own operations — including data of employees, clients, Generators, Transporters, and Processors —, the User acts as Controller and is responsible for ensuring the lawfulness of the processing before sharing such data with the Platform. It should be noted that, in most cases, this data is submitted to the Carrot Network directly by *Network Integrators* on behalf of the User Controller.
### 2.2 When Carrot Is the Processor [#22-when-carrot-is-the-processor]
Carrot Fndn acts as Processor when it processes personal data on behalf and under the instructions of the User Controller — for example, when validating data submitted by *Network Integrators* for the purpose of credit issuance.
### 2.3 When Carrot Is an Independent Controller [#23-when-carrot-is-an-independent-controller]
Carrot Fndn acts as an independent Controller in processing activities carried out on its own behalf, such as:
* KYC/KYB — identification and verification of Users, performed directly or through specialized third-party providers;
* Distribution of Rewards via smart contracts;
* Compliance with legal and regulatory obligations, including those arising from Lei nº 14.478/2022;
* Prevention of fraud, money laundering (AML), and terrorism financing (CFT);
* Accreditation process of participants carried out directly by Carrot Fndn.
### 2.4 Network Integrators and Validators as Subprocessors [#24-network-integrators-and-validators-as-subprocessors]
*Network Integrators* are third-party applications and platforms that integrate with the Carrot Network through APIs to record waste chain-of-custody events. When inputting personal data of chain participants (Generators, Transporters, Processors) into the Platform, *Network Integrators* act as Subprocessors of Carrot Fndn, under art. 39 of the LGPD.
Admission of *Network Integrators* to the Carrot Network is subject to the execution of a Data Processing Agreement (DPA) with Carrot Fndn, which shall establish compliance obligations, processing limits, and required security measures. Carrot Fndn will maintain an updated registry of accredited *Network Integrators* at [www.carrot.eco](http://www.carrot.eco).
Validators and Auditors are authorized agents who confirm transactions and certify operations along the chain of custody. When the exercise of their functions involves access to personal data contained in MassIDs or audit records, these agents operate as limited Subprocessors, with access restricted to the minimum necessary for the validation or certification of the corresponding operation, equally subject to a DPA.
*Regardless of the role exercised, a party shall not be held liable for acts, omissions, or violations of data protection legislation committed by the other party, its agents, and/or contractors (cf. art. 42, §3, LGPD).*
## 3. Technology: Cloud Infrastructure and Blockchain [#3-technology-cloud-infrastructure-and-blockchain]
Carrot Fndn adopts a data architecture that combines cloud storage (*off-chain*) and blockchain storage (*on-chain*), with the objective of simultaneously ensuring traceability, auditability, and privacy of data subjects.
### 3.1 Off-chain Data (Cloud Servers) [#31-off-chain-data-cloud-servers]
Sensitive personal information — name, email, identification documents, KYC/KYB data — is stored on secure cloud infrastructure, currently hosted on servers located in the United States of America (providers such as AWS and *Google Cloud*), with encryption at rest (AES-256) and in transit (TLS 1.2+). This data is subject to access, correction, and deletion by the data subject, as provided in Section 7. For the Platform's traditional login component, a password recovery mechanism is available, unlike access to digital wallets (addressed in Section 8.3).
### 3.2 On-chain Data (Blockchain) [#32-on-chain-data-blockchain]
Transaction records for circular economy operations, credit issuance (TRC/TCC), and validation hashes are immutably recorded on the blockchain. In accordance with the principle of privacy by design, Carrot Fndn does not record identifiable personal data directly on-chain in a public manner: cryptographic hashing techniques are used to preserve data integrity without exposing the data subject's identity.
> **On-chain Anonymization Procedure**
>
> When the data subject exercises the right to deletion provided for in art. 18, IV, of the LGPD with respect to data recorded on-chain, Carrot Fndn shall adopt the following procedure: (i) permanent deletion of the personally identifiable data in the off-chain records; (ii) invalidation of the mapping between the public wallet address and the data subject's identity in the Foundation's database; (iii) issuance of an anonymization certificate to the data subject within 30 (thirty) days. The remaining on-chain hash will maintain the integrity of the environmental transactions without allowing re-identification of the data subject.
## 4. Data Collection, Purpose, and Legal Basis [#4-data-collection-purpose-and-legal-basis]
Carrot Fndn collects exclusively the data necessary to fulfill the purposes described in this Policy, in compliance with the principle of necessity (art. 6, item III, LGPD).
### 4.1 Categories of Data Collected [#41-categories-of-data-collected]
| Category | Examples | Purpose |
| ------------------------------- | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ |
| **Registration Data (KYC/KYB)** | Name, CPF/CNPJ, email, identification document, address, legal representation | Identity verification, regulatory compliance, and compliance with Lei nº 14.478/2022 |
| **Web3 Data** | Public wallet address | Reward processing and environmental asset registration |
| **Operational Data** | Origin, mass, and type of waste; MassID; ProductID; MTR | Issuance and validation of Tokenized Environmental Credits |
| **Browsing and Tracking Data** | IP address, date/time of access, session logs, functional and analytical cookies | Network security, fraud prevention, and Platform operation (see Section 5) |
| **Financial Data** | Payment account, Rewards history, crypto asset operations | Reward distribution, tax compliance, and AML/CFT |
#### 4.1.1 Use of Registration Data for Public Recognition (Section 7A of T\&C) [#411-use-of-registration-data-for-public-recognition-section-7a-of-tc]
The name, logo, and website of the Participant organization, which are part of the data collected during the registration process (KYC/KYB), may also be used for purposes of public recognition of environmental impact, as set forth in Section 7A of the [Terms and Conditions](/docs/terms/terms-and-conditions) (*Impact Recognition Program*).
Such use is contingent upon the authorization granted by the User upon accepting the Terms and Conditions, and may be revoked at any time by written notice to [legal@carrot.eco](mailto:legal@carrot.eco), without prejudice to disclosures previously made.
### 4.2 Legal Basis for Processing [#42-legal-basis-for-processing]
The processing of personal data by Carrot Fndn is based on the following legal grounds under art. 7 of the LGPD:
* **Performance of a contract** (art. 7º, inc. V): processing necessary for the provision of services contracted by the User;
* **Compliance with a legal or regulatory obligation** (art. 7º, inc. II): KYC/KYB, tax obligations, regulatory reporting, and compliance with Lei nº 14.478/2022, Resolução BCB nº 1/2020, and AML/CFT obligations;
* **Legitimate interest** (art. 7º, inc. IX): used specifically for (i) fraud prevention and Network security; (ii) anomaly and attack detection; (iii) technical improvement of services; and (iv) public recognition of Participants' environmental impact, including disclosure of the organization's name, logo, and website on Carrot Fndn's institutional channels, as set forth in Section 7A of the [Terms and Conditions](/docs/terms/terms-and-conditions) (*Impact Recognition Program*). The use of this legal basis is subject to a proportionality test and documented in a Data Protection Impact Assessment (DPIA) maintained internally;
* **Consent** (art. 7º, inc. I): for non-essential cookies and marketing purposes, collected in a specific, prominent, and unambiguous manner at the time of first access.
### 4.3 Data We Do Not Collect [#43-data-we-do-not-collect]
Carrot Fndn does not collect, under any circumstances: private keys, seed phrases, or any credentials that allow direct access to the User's digital assets.
### 4.4 Use of the Platform by Minors [#44-use-of-the-platform-by-minors]
Carrot Fndn's services are intended exclusively for natural persons over 18 (eighteen) years of age and legal entities represented by their legal representatives, pursuant to art. 14 of the LGPD and art. 8 of the GDPR. By using the Carrot Network, the User declares that they have full legal capacity. If the User is a legal entity, the legal representative declares that they have the authority to accept this Policy on behalf of the entity.
If Carrot Fndn identifies that data from a minor has been inadvertently collected without verifiable consent of parents or legal guardians, such data will be immediately deleted. Users who become aware of such a situation should notify the DPO at [legal@carrot.eco](mailto:legal@carrot.eco).
### 4.5 Automated Decisions [#45-automated-decisions]
The Carrot Network uses smart contracts to automatically process decisions with effects on the User, including:
* (i) calculation and distribution of Rewards based on the waste chain of custody recorded in MassIDs;
* (ii) validation or rejection of MassIDs for the purpose of issuing Tokenized Environmental Credits;
* (iii) temporary suspension of participants identified as potentially irregular by Network Auditors.
Under art. 20 of the LGPD, the User has the right to request human review of any automated decision that significantly affects them, including suspensions and Reward blocks. The request shall be sent to the DPO ([legal@carrot.eco](mailto:legal@carrot.eco)), with a description of the contested decision, and will be responded to within 15 business days, extendable by an additional 15 calendar days.
## 5. Cookies and Tracking Technologies [#5-cookies-and-tracking-technologies]
Carrot Fndn uses cookies and similar technologies on its websites to ensure the proper functioning of the Platform, analyze performance, and improve the User experience.
### 5.1 Cookie Categories [#51-cookie-categories]
| Category | Purpose | Tools / Destination | Legal Basis |
| --------------------- | ----------------------------------------------------------- | -------------------------------------------------------------------------------- | -------------------------------------------------------- |
| Strictly Necessary | Session authentication, security, and essential preferences | Carrot's own infrastructure (no transfer) | Performance of a contract (art. 7º, V, LGPD) |
| Analytics/Performance | Traffic analysis and browsing behavior | Google Analytics 4 (GA4) — US via SCCs; Vercel Analytics — Vercel infrastructure | Legitimate interest (art. 7º, IX, LGPD) / Consent (GDPR) |
| Functional | Language, region, and User preference personalization | Carrot's own infrastructure | Legitimate interest (art. 7º, IX, LGPD) |
### 5.2 Consent Management and Opt-out [#52-consent-management-and-opt-out]
On the first visit to any website operated by Carrot Fndn, the User will be presented with a cookie consent banner, allowing them to accept, decline, or customize each non-essential category. Consent is recorded with a timestamp and may be revoked at any time at the [Privacy Policy](/docs/terms/privacy-policy) page. Declining non-essential cookies does not prevent use of the Platform.
For specific opt-out from analytics tools:
* Google Analytics 4: install the opt-out add-on available at tools.google.com/dlpage/gaoptout;
* Vercel Analytics: disable in your browser's privacy settings or use compatible blocking extensions.
> **GA4 Transfer to US**
>
> Google Analytics 4 transfers data to servers in the US. Carrot Fndn adopts the European Commission's Standard Contractual Clauses (SCCs) as a safeguard. For Brazilian data subjects, the transfer is based on art. 33, VIII, of the LGPD (specific consent) and the data processing agreement with Google.
## 6. Sharing, Sub-processors, and International Transfers [#6-sharing-sub-processors-and-international-transfers]
Personal data may be shared with third parties under the following circumstances and conditions:
* **Technology partners and sub-processors:** exclusively to enable Platform operations, under a DPA with confidentiality and compliance obligations;
* **Accredited independent auditors:** for environmental certification and verification purposes, strictly limited to what is necessary;
* **Regulatory, judicial, and virtual asset supervisory authorities:** when required by law, court order, or applicable regulation, including the Central Bank of Brazil and COAF, under Lei nº 14.478/2022, for compliance with anti-money laundering (AML) and counter-terrorism financing (CFT) obligations.
### 6.1 Main Sub-processors [#61-main-sub-processors]
| Sub-processor | Service | Data Location | Safeguard |
| ------------------------- | ----------------------------------------- | ------------- | --------- |
| Amazon Web Services (AWS) | Cloud infrastructure and storage | US | SCCs |
| Google LLC (GCP / GA4) | Cloud infrastructure and data analytics | US | SCCs |
| Vercel Inc. | Website hosting and performance analytics | US | SCCs |
Material changes will be communicated with a minimum notice of 30 (thirty) days.
### 6.2 International Data Transfers [#62-international-data-transfers]
Carrot Fndn operates with cloud infrastructure hosted in the United States of America and with its institutional headquarters in Switzerland, which entails international transfers of personal data. Switzerland holds an adequacy recognition from the European Commission for GDPR purposes. For purposes of the Brazilian LGPD, ANPD has not yet published an official list of countries with an adequate level of protection; until such a decision is formalized, international transfers are carried out based on:
* **Standard Contractual Clauses (SCCs):** adopted with all international sub-processors, under art. 33, II, of the LGPD, as the primary safeguard for transfers from Brazil to the US and Brazil to Switzerland;
* **Specific consent of the data subject:** (art. 33, VIII, LGPD), when applicable and collected in a prominent manner.
> **Note on ANPD Adequacy**
>
> The adequacy recognition of Switzerland is valid only in the context of the GDPR (European Commission). For the LGPD, until ANPD publishes an official list, the current safeguard is the SCCs. This Policy will be updated when a formal ANPD decision is issued.
## 7. Data Subject Rights [#7-data-subject-rights]
Under art. 18 of the LGPD, the personal data subject has the following rights, exercisable by request to the DPO at [legal@carrot.eco](mailto:legal@carrot.eco):
### 7.1 Rights under the LGPD [#71-rights-under-the-lgpd]
| Right | How to Exercise It on the Carrot Platform |
| ------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Confirmation and Access (art. 18, I-II)** | Request via [legal@carrot.eco](mailto:legal@carrot.eco); response within 15 days. |
| **Correction (art. 18, III)** | Update registration data directly through the Platform interface or via DPO. |
| **Anonymization, Blocking, or Deletion (art. 18, IV)** | Off-chain data: permanent deletion. On-chain data: technical anonymization with issuance of certificate within 30 days (see Section 3.2). |
| **Portability (art. 18, V)** | Provision in a structured and interoperable format, upon request. |
| **Information on Sharing (art. 18, VII)** | This Policy describes the categories of recipients; additional details available via DPO. |
| **Revocation of Consent (art. 18, IX)** | At any time, for purposes based on consent, without prejudice to processing previously carried out. |
| **Review of Automated Decisions (art. 20)** | Request for human review of smart contract decisions with financial impact (Reward calculation, MassID suspension). Send to [legal@carrot.eco](mailto:legal@carrot.eco) with a description of the contested decision. |
> **Rights of Third Parties Whose Data Arrives via Integrator**
>
> Chain participants (e.g., transport companies whose data is submitted by Network Integrators) are personal data subjects and retain all rights under art. 18 of the LGPD, even without a direct contractual relationship with Carrot Fndn. Upon receiving a deletion request for such data, Carrot Fndn will assess whether there is a conflict with environmental audit obligations or legal retention periods. In case of conflict, it may invoke the exceptions under art. 18, §3, of the LGPD (compliance with a legal obligation or regular exercise of rights), communicating the outcome to the data subject within 15 days.
### 7.2 Additional Rights under the GDPR (Data Subjects in the EEA) [#72-additional-rights-under-the-gdpr-data-subjects-in-the-eea]
For data subjects residing in the European Economic Area, the following additionally apply:
* **Right to Object (art. 21 GDPR):** the data subject may object to processing based on legitimate interest, at any time;
* **Restriction of Processing (art. 18 GDPR):** in certain circumstances, the data subject may request that the processing of their data be restricted;
* **Complaint to a Supervisory Authority:** the data subject may file a complaint with the data protection authority of the EU Member State of their habitual residence or where the alleged infringement occurred.
Should Carrot Fndn begin to systematically process data of European data subjects at a relevant scale, it will assess the need to appoint a representative in the EU pursuant to art. 27 of the GDPR. To exercise these rights: [legal@carrot.eco](mailto:legal@carrot.eco).
### 7.3 Rights under the revDSG (Data Subjects in Switzerland) [#73-rights-under-the-revdsg-data-subjects-in-switzerland]
For data subjects residing in Switzerland, the rights provided under the revDSG apply, including: access, correction, deletion, portability, and objection. Complaints may be filed with the FDPIC (Federal Data Protection and Information Commissioner — [www.edoeb.admin.ch](http://www.edoeb.admin.ch)). Contact channel: [legal@carrot.eco](mailto:legal@carrot.eco).
Carrot Fndn will respond to requests within 15 (fifteen) days, extendable by an equal period when justified, under art. 18, §5, of the LGPD, and within a reasonable timeframe as required by the GDPR and the revDSG.
## 8. Information Security [#8-information-security]
Carrot Fndn adopts appropriate technical and administrative measures to protect personal data against unauthorized access, destruction, loss, alteration, disclosure, or any other form of improper processing, in compliance with art. 46 of the LGPD and art. 32 of the GDPR.
### 8.1 Technical Measures [#81-technical-measures]
* Encryption in transit: TLS 1.2 or higher protocol for all client-server communication;
* Encryption at rest: AES-256 standard for data stored on cloud infrastructure;
* On-chain cryptographic hashing: ensures mathematical integrity of records without exposing identifiable personal data;
* Identity-based access control (IAM): only authorized users and systems may access personal data;
* Continuous monitoring: detection of anomalies and unauthorized access attempts.
### 8.2 Administrative Measures [#82-administrative-measures]
* Privacy and data protection governance program, with periodic reviews;
* Training and awareness for employees and service providers;
* Security incident response plan, with documented notification procedures;
* Data Processing Agreements (DPAs) with all sub-processors and Subprocessors.
### 8.3 Digital Asset Custody [#83-digital-asset-custody]
Carrot Fndn does not store, manage, or have access to the private keys or seed phrases of Users' digital wallets. Custody of digital assets is the exclusive responsibility of the User, and the loss or misplacement of such credentials is the User's sole responsibility, with no possibility of recovery by the Platform.
Note: the mechanism described above applies exclusively to the Platform's Web3 digital wallet component. For traditional login access (email and password), Carrot Fndn provides a standard password recovery mechanism.
### 8.4 Security Incident Communication [#84-security-incident-communication]
In the event of a security incident that may pose a risk or relevant harm to data subjects, Carrot Fndn will adopt the following procedures:
| Applicable Law | Authority | Notification Deadline | Legal Basis |
| -------------------- | ----------------------------------------- | ------------------------------------------------ | -------------------------------------- |
| LGPD (Brazil) | ANPD | 72 hours after awareness | Art. 48 LGPD + Res. CD/ANPD nº 15/2024 |
| GDPR (EU/EEA) | Supervisory authority of the Member State | 72 hours after awareness | Art. 33 GDPR |
| revDSG (Switzerland) | FDPIC | As soon as possible (no fixed deadline in hours) | Art. 24 revDSG |
Notification to affected data subjects will be carried out via the email registered on the Platform. When the volume of affected individuals makes individual notification impractical, a prominent notice will be published at [www.carrot.eco](http://www.carrot.eco) and on the Platform's authenticated access panel for a minimum period of 30 (thirty) days.
The notification shall include: (i) the nature of the affected data; (ii) information about the data subjects involved; (iii) technical measures adopted; and (iv) related risks and actions to mitigate their effects.
### 8.5 Limitation of Liability for Security Incidents [#85-limitation-of-liability-for-security-incidents]
Notwithstanding the security measures described in Sections 8.1 and 8.2, Users acknowledge that no technology system offers absolute security.
Carrot Fndn shall not be liable for security incidents arising exclusively from: (i) zero-day vulnerabilities not yet identified by the security community at the time of the incident; (ii) state-level attacks or attacks on critical infrastructure beyond the Foundation's reasonable control; or (iii) failures in systems, networks, or third-party infrastructure over which the Foundation has no direct operational control.
Carrot Fndn remains liable for incidents resulting from failures in its own implemented security measures, subject to the liability provisions set forth in the [Terms and Conditions](/docs/terms/terms-and-conditions) (Section 15).
## 9. Data Retention and Deletion [#9-data-retention-and-deletion]
Personal data is retained for the period necessary to fulfill the purposes for which it was collected, subject to mandatory legal retention periods. Upon termination of the contractual relationship and expiration of applicable retention periods, off-chain data will be securely deleted or anonymized.
| Data Category | Retention Period | Legal Basis |
| ------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ |
| Contractual and tax data | Minimum 5 years | Art. 206, §5, Brazilian Civil Code; federal tax legislation |
| KYC/KYB data | 5 years after end of relationship; up to 10 years if there is a regulatory or judicial investigation | Res. BCB nº 1/2020; Lei nº 14.478/2022 (AML/CFT) |
| MTR and operational data | Minimum 5 years | Res. CONAMA nº 313/2002; Lei nº 12.305/2010 (PNRS) |
| Access and browsing logs | 6 months | Art. 15, Marco Civil da Internet (Lei nº 12.965/2014) |
| Environmental audit records (off-chain) | Per applicable methodologies | Verra, Gold Standard, and other international certification bodies |
| On-chain records (hashes) | Indefinite (technical immutability) | Technical anonymization applied — identity unlinking |
| Analytical cookie data | Up to 13 months (GA4 default) | Consent / legitimate interest |
| Public recognition data — Impact Recognition Program (Section 7A of T\&C) | Up to 15 business days after opt-out request | Section 7A of the Terms and Conditions — opt-out processing period |
## 10. Global Storage and Processing [#10-global-storage-and-processing]
Due to the decentralized nature of the Carrot Network and infrastructure resilience requirements, data is primarily processed and stored on servers located in the United States of America, in addition to the institutional headquarters in Switzerland. Carrot Fndn ensures that all international transfers comply with the mechanisms provided in arts. 33 to 36 of the LGPD, with adoption of Standard Contractual Clauses (SCCs) as the primary safeguard, ensuring a level of protection equivalent to that required by Brazilian legislation.
## 11. Data Protection Officer (DPO) [#11-data-protection-officer-dpo]
In compliance with art. 41 of the LGPD and Resolução CD/ANPD nº 2/2022, Carrot Fndn has designated a Data Protection Officer (DPO), responsible for:
* Receiving communications from data subjects, ANPD, FDPIC, and competent GDPR supervisory authorities;
* Advising employees and contractors on data protection practices;
* Acting as a communication channel between the Foundation, data subjects, and supervisory authorities.
**DPO Contact:** [legal@carrot.eco](mailto:legal@carrot.eco)
*The DPO's nominal identity will be disclosed in compliance with Resolução CD/ANPD nº 2/2022. For contact purposes, [legal@carrot.eco](mailto:legal@carrot.eco) is the official address designated for all data protection communications.*
## 12. Changes to this Policy [#12-changes-to-this-policy]
This Policy may be updated periodically to reflect legal, technological, or operational changes. Changes are classified into two types:
### 12.1 Material Changes [#121-material-changes]
Changes are considered material when they involve: (i) a new processing purpose; (ii) a new category of data collected; (iii) new sharing with third parties; or (iv) a change in the applicable legal basis. Such changes will be communicated with a minimum notice of 30 (thirty) days by email, requiring express consent from the User (opt-in) to continue using the Platform.
### 12.2 Non-Material Changes [#122-non-material-changes]
Changes in wording, clarifications, or corrections that do not alter the scope of processing will be communicated with a minimum notice of 15 (fifteen) days by email. Continued use of the Platform after the changes take effect implies tacit acceptance.
The current version of this Policy will always be available at [docs.carrot.eco/terms/privacy-policy](/docs/terms/privacy-policy).
## 13. Version History [#13-version-history]
| Version | Date | Responsible | Main Changes |
| ------- | ---------- | -------------------------- | --------------- |
| 1.0 | March/2026 | Legal and Tech Carrot Fndn | Initial Version |
## 14. Glossary [#14-glossary]
| Term | Definition |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **TRC** | Tokenized Recycling Credit — a tokenized recycling credit representing 1 ton of verified recycled material. |
| **TCC** | Tokenized Carbon Credit — a tokenized carbon credit representing emission reductions. |
| **MassID** | A unique digital asset representing a physical waste batch, tracking its provenance and chain of custody on the blockchain. |
| **ProductID** | A digital product identifier used to track the composition of post-consumer materials and recyclability. |
| **dMRV** | digital Measurement, Reporting and Verification — a digital process for measuring, reporting, and verifying environmental gains. |
| **MTR** | Manifesto de Transporte de Resíduos — a Brazilian regulatory document (Res. CONAMA nº 313/2002). |
| **Network Integrator** | A third-party platform integrated with the Carrot API to record chain-of-custody events; acts as a Subprocessor under art. 39 of the LGPD. |
| **KYC/KYB** | Know Your Customer / Know Your Business — a process for verifying the identity of natural persons and legal entities. |
| **DPO** | Data Protection Officer — responsible for data protection at Carrot Fndn. Contact: [legal@carrot.eco](mailto:legal@carrot.eco). |
| **SCCs** | Standard Contractual Clauses — approved clauses for international transfers of personal data. |
| **FDPIC** | Federal Data Protection and Information Commissioner — Switzerland's data protection supervisory authority ([www.edoeb.admin.ch](http://www.edoeb.admin.ch)). |
| **revDSG** | Revised Swiss Federal Act on Data Protection, in force since September 1, 2023. |
| **DPIA** | Data Protection Impact Assessment — an internal document that records processing activities based on legitimate interest. |
| **DPA** | Data Processing Agreement — an agreement executed between Carrot Fndn and sub-processors and Subprocessors. |
| **VASP** | Virtual Asset Service Provider — a regulatory category created by Lei nº 14.478/2022, subject to supervision by the Central Bank of Brazil. |
| **AML/CFT** | Anti-Money Laundering / Counter-Financing of Terrorism — prevention of money laundering and terrorism financing. |
***
Legal inquiries: [legal@carrot.eco](mailto:legal@carrot.eco) · Operational support: [operations@carrot.eco](mailto:operations@carrot.eco)
*This document supersedes all previous versions of the Carrot Platform Usage Agreement.*
# Terms and Conditions
{/* cspell:words Fndn homologation homologated unenforceability unmatured CCPA LGPD DPRK majeure stablecoins */}
**Version 2.0 — March 2026**
## 1. CARROT Network and Websites [#1-carrot-network-and-websites]
Carrot Fndn is a Swiss foundation in the sense of Article 80 et seq. of the Swiss Civil Code with its registered seat in Zug ("Foundation").
The Foundation has developed and deployed the CARROT blockchain-based network ("Network"), which is managed by the Carrot Foundation in partnership with its community of stakeholders. The Network enables on-chain and off-chain recording of circular economy actions, including supply chain logistics and waste management activities; environmental measurement, reporting, and verification; auditing; recycling, composting, reuse, and recycled content use in products certification; as well as decarbonization. The circular economy actions taken by participants ("Participants") (e.g., raw material providers, packers, fillers, producers, waste generators, bin custodians, haulers, processors, recyclers, raw material buyers, methodology authors, methodology developers, auditors, and NGOs, among others) are recorded on the Network via mobile, software, and web applications of third-party Carrot Network Integrators ("INTs") that connect to the Network via APIs. Resources such as raw materials or waste mass ("MassIDs") and products ("ProductIDs") are codified as unique identifiers that establish chain of custody and material or product responsibility. Based on the recorded circular economy actions and the corresponding environmental and social gains realized, the Foundation generates non-fungible Tokenized Recycling Credits ("TRC"), Tokenized Carbon Credits ("TCC") as well as other types of credits, which are subsequently offered by the Foundation to interested third-party buyers ("Token Buyers"). The purchase of TRCs and TCCs by Token Buyers distributes proceeds ("Rewards") to the supply chain Participants who contributed in a collaborative manner to recover resources for reuse or recycling, thereby avoiding pollution to land, water, and the atmosphere and the need for new raw material extraction. For the purpose of these Terms and Conditions ("Terms"), the Participants and the INTs are collectively referred to as ("Users").
The Foundation hosts and maintains websites under the domain [www.carrot.eco](http://www.carrot.eco) ("Websites") that allow users to learn about the Carrot Fndn and Network, its purpose, and how it functions; join the community; become versed in the circular economy; view reported circular economy data and Environmental & Social Claims of its Participants, purchase and retire tokens (e.g., TRCs, TCCs and others); confirm the retirement of credits (burned non-fungible tokens) in a public registry; and verify and compare environmental performance by all Participants, including through a leader board.
## 2. Acceptance of and Amendments to the Terms and Conditions [#2-acceptance-of-and-amendments-to-the-terms-and-conditions]
These Terms, together with any documents expressly incorporated by reference herein, govern the access to and use of the Websites, the Network, and related smart contracts. Furthermore, it governs the process for measuring, reporting, and verifying circular economy contributions ("Environmental & Social Claims") (e.g., prevented waste; prevented, captured, or removed greenhouse gas (GHG) emissions; green jobs; social and economic benefits; and others) and Rewards Users may receive, as further described below. By using the Websites and/or the Network, the Users agree to be bound by these Terms.
The use of the applications offered by the Carrot Blockchain Integrators (INTs) and any rights and obligations between Participants and INTs are not governed by these Terms but by other terms & conditions and/or agreements established between the parties.
The Foundation reserves the right to change or modify these Terms at any time at its own and sole discretion. By continuing to access, use, send, or have data sent by a third party (e.g., INT) to the Websites and/or the Network, the Users confirm that they accept the updated Terms and all the terms incorporated therein by reference. INTs and service providers ("Service Providers") such as Haulers, Processors and Recyclers, are also responsible for informing their customers, who are also Users, of updated terms and securing their acceptance of such Terms, especially as it relates to receiving Rewards that also involve those Users.
Any Participant/User who participates in the creation or sale of Tokenized Recycling Credits or Tokenized Carbon Credits is also bound by the [Terms & Conditions for Recycling and Carbon Credit Token Sales and Purchases](/docs/terms/credit-sales-terms) published under the Terms & Conditions section of the Carrot Network. The Terms & Conditions for Recycling and Carbon Token Credit Sales and Purchases shall be incorporated into these Terms by reference for all purposes.
## 3. Know Your Customer/Business ("KYC") [#3-know-your-customerbusiness-kyc]
In order to participate in the Carrot Network, Users must provide individual identification information, such as their full name, mobile number, birthdate, email address, wallet address to which Rewards (as defined below) may be sent, residential address, document showing proof of residential address, nationalities, government ID for each nationality, and documents showing proof of government ID, including proof of possession, such as a photo of the person holding the ID.
In the case of a company, the legal representative must, in addition to providing individual identification information, provide documents showing proof of legal representation, a corporate email, the legal name of the corporation, the Tax ID of the company, and a document showing proof of Tax ID as well as any other information as may be reasonably requested from time to time by the Foundation, in order to complete the Foundation's examination ("KYC-Check"). Users and INTs must provide true, accurate, current, and complete information and must promptly update the Foundation electronically with any data changes. Additional information will be required of specific Participants, such as Processors and Recyclers (e.g., environmental licenses to conduct business) and NGO Beneficiaries to verify the qualifications of parties relating to the environmental works being performed.
Know Your Customer (KYC) and Know Your Business (KYB) checks may be conducted by the Carrot Network itself or by third parties on behalf of the Carrot Network.
## 4. User's Transfer of Rights [#4-users-transfer-of-rights]
Users herewith transfer any and all past, present, or future rights, benefits, interests, credits, certificates, notes, claims, or authorizations, including reporting rights, claims on recycled or reuse of products and materials; carbon reduction, capture, or removal; or any other environmental, marketing, and similar rights or Environmental & Social Claims, resulting from or arising in connection with the data shared to the Network as it relates to circular economy actions (e.g., MassIDs, ProductIDs or other) in each case on an exclusive basis to the Foundation.
For the avoidance of doubt, the transfer of rights set forth in this Section 4 does not reflect or imply any present monetary value in the data or environmental actions shared by the User. The commercial value of any Environmental & Social Claim arises solely from the Foundation's application of the applicable Methodology, validation of the circular economy action, issuance of the corresponding credit or token, and its effective sale to a Token Buyer — a cycle that may or may not be completed. No single User holds ownership over any MassID, as the environmental gain represented by each credit results from the collective contribution of multiple supply chain Participants, each receiving only their proportional share of proceeds in accordance with the Rewards Distribution Policy upon a successful sale. The exclusive and irrevocable nature of the transfer serves solely to preserve the integrity of the crediting program for the protection of all Participants, Token Buyers, and the ecosystem as a whole. No liability shall attach to the Foundation solely by reason of this transfer in the event that no Token is issued or sold in connection with the relevant circular economy action.
For the avoidance of doubt, Users lose all of their rights to reporting Environmental & Social Claims in waste (Extended Producer Responsibility) or carbon (voluntary or mandatory) programs through the actions of recycling or reuse data submitted to the Network. Reporting of Environmental & Social Claims for the same product, resource, mass, or activity with another party is strictly prohibited, as this would constitute double counting and possibly double profiting on top of the same circular economy Environmental & Social Claims. Users may not themselves make any claim that in any way compromises the transfer of the Environmental & Social Claims to the Foundation. Furthermore, Users may not assign or transfer the Environmental & Social Claims in whole or in part to any party other than the Foundation. Any such prohibited transfer is null and void and can result in temporary or permanent removal from the Network as well as fines and legal action against the Participant.
Carrot holds the exclusive right to issue and sell credits (tokens) for the data provided to the network, upon validation and certification of circular economy actions — logistical events, chain of custody, and official hauling records (e.g., Waste Transport Manifests (Manifesto de Transporte de Resíduos (MTR) in Brazil)) recorded and tracked using the Network's MassID, RecycledID, ProductID, and GasID solutions. The minimum requirements for credit issuance include identifying the stakeholders involved in the final hauling leg to an accredited recycler without the need for full onboarding of the participants with the exception of the recycler, as long as the stakeholders are individually identified in official hauling records (e.g., MTRs in the case of Brazil).
The Carrot Fndn will in turn transfer the rights in Environmental & Social Claims to the Token (TRC or TCC) Buyer in exchange for the important investment realized by the buyer in supporting circular economy actions. Only following token retirement, thereby making it untransferable, will the Token Buyer be allowed to claim and use the associated Environmental & Social Claims. Retired tokens prove contributions realized by the holder of the token as an investment in ecosystem-driven waste and carbon avoidance, serving as proof of carbon offsetting and meeting Extended Producer Responsibilities in accordance with Carrot Standards. Retired tokens become eligible to be listed in the Carrot Registry and leaderboards. Such proofs may or may not be accepted by other registries, and Carrot is not responsible for their acceptance elsewhere, as this is beyond the control of Carrot Fndn.
## 5. Methodologies [#5-methodologies]
The Carrot Network utilizes methodologies created by third-party contributors for use in verifying data and measuring environmental and social gain ("Methodologies"). Methodologies are written by Methodology Authors and developed by Methodology Developers and each Participant receives a portion of the Rewards generated by the TRCs and TCCs that result from the use of the Methodology. The Reward amounts are predetermined in the Rewards Distribution Policy for each material and are published on the website at [Rewards Distribution Policy](/docs/standard/policies/rewards-distribution).
## 6. Homologation [#6-homologation]
Some Participants are deemed to have particularly important roles within the Carrot Network and will need to be accredited by the Foundation (or by one of its partners) to ensure performance capabilities, legal standing, and data quality are established.
Carrot Network Integrators who submit circular economy action data to the Network will need to be accredited for sufficient quality and security of the data provided. While data quality is the responsibility of the INT and the Users involved, verification of INT data will be continuously conducted by the Foundation and Network Participants.
NGO Beneficiaries will need to be accredited in order to be eligible to receive rewards from the Carrot Network. Homologation will involve submittal of the organization's governing documents; submittal of the organization's tax ID; proof of the organization's good standing to conduct business; proof of the organization's good standing with tax authorities; proof of the organization's mission or purpose to advance the transition to a circular economy; and proof that the organization is apolitical.
Processors and Recyclers need to be accredited for each Methodology utilized to certify recycling or reuse and issue TRCs and TCCs. Processors who receive and perform sorting activities, as well as Recyclers who do the important work of mass manipulation for transformation into new inputs, will be audited by an independent Auditor considered by the Foundation to be an expert in the field to ensure that they are capable of the environmental work being conducted and are in good professional and legal standing.
Homologation renewals will be dictated by the rules established by different methodologies, and it is the responsibility of each Participant to ensure that their accreditation is kept up-to-date. Homologation and renewals, including audits, may incur a cost for the candidate, and the cost will be communicated to the candidate in advance of the initiation of any accreditation work. The candidate will, of course, have every right to reject the accreditation work, which will result in the automatic disqualification of the candidate when the accreditation period expires. Carrot will always seek to establish a fair value for accreditation work, considering the costs and value of the work employed by Auditors and the accreditation team. Carrot's accreditation team can be reached at [operations@carrot.eco](mailto:operations@carrot.eco).
## 7. Rewards [#7-rewards]
Subject to the transfer of rights, successful passing of the KYC Check, verification of circular economy action data submitted to the Network by INTs, and certification under a methodology ("Methodology") selected by the accredited Recycler, Users may be rewarded with a portion of the proceeds generated by the sale of tokens (e.g., TRC and TCC) to Token Buyers ("Rewards").
Rewards, if any, will be paid out in tokens, in the amount determined by the Foundation and its supporters, and executed through the smart contracts developed or approved by the Foundation, directly to the wallet address provided by the User. Each User is fully responsible for providing the Foundation with a functioning wallet address held by them for their own account and for claiming the tokens that were reserved or distributed to them from the Network.
Access to and redemption of credit rewards (USDC) reserved in the Smart Contract for each participants based on the Rewards Distribution Policy, are strictly conditional upon the completion of onboarding (including the KYC/KYB process) and the full acceptance of the Carrot Network Terms of Use and Sales and Purchases of TRCs and TCCs by the respective Participant. The reward redemption period is 90 calendar days from the credit sale date, designed to incentivize supply chain digitalization, stakeholder onboarding, and improved waste sorting. Upon expiration of this period, unclaimed rewards will be automatically transferred to the [Community Pool](/docs/glossary#community-pool), canceling the User's opportunity to withdraw said rewards (incentives) from given credits. The User may sign the terms at any time and begin participating in earning rewards at any time for credits sold less than 90 calendar days ago and in future credit issuance.
The Rewards and their distribution allocations are predetermined in the rewards distribution policy of the Foundation ("Reward Policy"), which is available on the Carrot Network Website under Rewards Distribution Policy. The Reward Policy may be amended by the Foundation at any time at its discretion to benefit the community as a whole. However, amendments will be communicated to all Participants through the primary email address that was provided for each account, providing reasonable time for any adjustments if they are deemed necessary.
Particular attention should be given to the rewards distribution discounts to service providers designed to encourage supply chain digitization (i.e., the "Incentive Mechanism") when the Waste Generator is not identified, as well as to Waste Generators who are "Large Revenue" businesses, designed to ensure credit buyers are not discouraged from purchasing credits that distribute proceeds to large organizations while also maintaining sufficient incentive to ensure participation and network adoption. The Waste Generator plays a key role in the circular economy because he/she/it makes the determination of whether and how to sort post-consumer and post-industrial waste and products and, ultimately, if those will in fact be recovered for reuse and/or recycling.
Participants may also be temporarily or permanently excluded from receiving rewards if the Foundation or a third-party auditor ("Auditor") identifies behavior that is deemed unethical, illegal, criminal, or other and/or appears to show collusion with other Participants regarding reported circular economy actions, including but not limited to overstating the recycling or reuse activities and corresponding Environmental & Social Claims achieved. The exclusion in rewards distribution may be directed to the Participants directly involved as well as to users who are related to the Participants, penalizing such Participants through association. Such penalties are fundamental to deter bad actors and align interests in reporting data with the highest quality possible onto the Network. Such a mechanism for ensuring self-policing of data quality on the Network is often referred to as Proof-of-Authority, or ("PoA"). For more information, see the section below on Penalties and Suspensions.
Participants who are penalized by not receiving rewards from credit sales due to credits that were prevented from being sold, either for suspicious activity or identified as containing compromised data, recognize that, even if they have no part in the activities of the Bad Actor(s), that the penalty serves as a fundamental component of the network's self-policing mechanism required for ensuring high-quality data on the Network. The penalized good actor agrees to not dispute or take any action against the Carrot Fndn for Rewards not distributed to them. Penalized Participants should also not take action against any other good actors who are also involved, for no fault of their own. Good actors are invited to communicate with the identified Bad Actor to ensure actions are corrected and, if matters cannot be resolved, to change service providers and/or work with other Participants. Bad Actors shall be solely responsible for indemnifying and holding harmless the Participants from and against any claims, losses, and penalties, whether civil, criminal, tax, administrative, environmental or otherwise, resulting from the action or omission of such Bad Actor.
All Participants, as members of a Network, are each deemed responsible for documenting their circular economy actions and reporting Environmental Claims accurately and understand that rewards serve only as a bonus when all activities can be reasonably verified, and Participants are conducting their circular economy actions correctly.
## 7A. Impact Recognition Program [#7a-impact-recognition-program]
By accepting these Terms, the Participant grants the Foundation a non-exclusive, royalty-free authorization to publicly disclose the environmental results and impacts generated by their organization on the Network — including waste volumes recovered and recycled, carbon emissions reduced, prevented or removed, certificates and credits (recycling, carbon and other) issued and retired — on the Carrot website, social media channels, and institutional materials, with the purpose of publicly recognizing their contribution to the low-carbon, inclusive circular economy and encouraging others to participate.
Only environmental impact data and the organization's name, logo and website will be used, along with any further information voluntarily provided by the organization. No personal data of individual Users will be disclosed under this Section.
Participants who do not wish to be featured may opt out at any time by written notice to [legal@carrot.eco](mailto:legal@carrot.eco), without affecting their participation in the Network or their right to receive Rewards. Opt-out requests will be processed within 15 business days.
## 8. Service Fees [#8-service-fees]
The Carrot Fndn, organizations that represent it or utilize the network, may charge fees associated with services provided, including, but not limited to, data use, data storage, digital Measurement, Reporting and Verification (dMRV), auditing and certification of supply chains, reuse, recycling, composting, energy production, greenhouse gas emissions measurement (production, avoidance, prevention, removal and capture,) proof of recycled-content use in products, certification and issuance of credits and any additional services that may be offered for measuring and monetizing environmental, financial and social impacts.
Any fees associated with services provided will be communicated to Participants in advance and require prior approval by the User before being charged.
## 9. Intellectual Property Rights [#9-intellectual-property-rights]
Users acknowledge and agree that the Websites available at [www.carrot.eco](http://www.carrot.eco), docs.carrot.eco and registry.carrot.eco, including their "look and feel" (e.g., graphics, design, text, images, logos, page headers, button icons, and scripts); proprietary content, information, and other materials; and all content and other materials contained therein, including, without limitation, the Foundation's and the Carrot Network's logo and all designs, text, graphics, pictures, data, software, sound files, other files, and the selection and arrangement thereof are the proprietary property of the Foundation or its affiliates, licensors, or Users, as applicable, and the Users agree not to take any action(s) inconsistent with such ownership interests. The Foundation and its affiliates and licensors, as applicable, reserve all rights in connection with the Websites and their content, including, without limitation, the exclusive right to create derivative works. Except as expressly set forth herein, Users' use of the Network or Websites does not grant to Users ownership of any other rights with respect to any content, code, data, or other materials that Users may access on or through the Network or Websites.
## 10. Code of Conduct [#10-code-of-conduct]
The Foundation may issue rules for the use of the Network and Websites and amend them at its own and sole discretion ("Code of Conduct"). Users are obliged to inform themselves about the current version of the Code of Conduct and ensure that they and their respective communities comply with the Code of Conduct.
The Foundation may publish or communicate the current Code of Conduct through the Websites or other official Foundation channels.
## 11. Penalties and Suspensions [#11-penalties-and-suspensions]
In the event of any irregularities in activities or in the reporting of data relating to a Participant, flagged as a potential "Bad Actor," Carrot Fndn or an accredited independent third-party Auditor, may suspend the Participant immediately from involvement in the Network and participation in the issuance of certificates and/or TRCs and TCCs. Participants associated with any Bad Actors may also be suspended immediately. Additional information may be requested from all of the Participants involved until sufficient clarification has been provided in order to determine how long the penalty may be or if and when the Participant may be reinstated. If a credit is found to contain, or potentially contain, bad data and the credit has already been sold, any proceeds not yet distributed will be directed to the Community Pool for use as the community deems most appropriate. Carrot Fndn has no obligation to return the value associated with the credits that were reserved for the Participants while they have been penalized. Again, the burden rests on each Participant to ensure that the data being provided is accurate and that they are working with other Participants who take the work of data quality seriously.
If any participant fails to provide a response to the request for information within 30 days, the participant may be permanently disqualified from participating in the Network and the issuance of credits.
For the period in which the activities in question failed to meet the requirements of a given methodology, participants will not receive any rewards from the sale of TRCs or TCCs.
During the period of non-compliance, TRCs or TCCs issued prior to this period involving the Bad Actor and not yet sold will be prevented from being sold until the situation is resolved.
In the event of fraud being identified for any of the requirements of a given methodology, accredited Participants will permanently lose their Homologation rights, and appropriate legal measures may be taken.
Any evidence of intentional practices that negatively impact the well-being of local communities or of natural ecosystems will serve as solid justification for permanent exclusion from participating in the Network.
Legal action may be taken by the Carrot Fndn against the party for any damages done to the Foundation or the Network in accordance with the degree and involvement of each Party relating to the damages.
## 12. Communication [#12-communication]
Users agree and understand that the Foundation will communicate with Users via electronic means. Users agree to keep their email address current and to notify the Foundation of any changes. Users agree that any notices, agreements, disclosures, or other communications delivered to their email addresses are considered valid.
## 13. Representations and Warranties of the Users [#13-representations-and-warranties-of-the-users]
The Users represent and warrant to the Foundation the following, and acknowledge that the Foundation is relying on these representations and warranties:
1. If Users are entities, they are duly organized, validly existing, and in good standing under the laws of its domicile;
2. If Users are entities, they have the full right, power, and authority to use the Websites, the Network and related smart contracts and accept these Terms;
3. If User is a natural person, they are of legal age in the jurisdiction applicable to them and have the right, authority, and capacity to enter into these Terms;
4. They own or have secured all rights (including intellectual property rights), consents, clearances and approvals necessary to be able to grant the rights granted hereunder;
5. If the User is an accredited Recycler, they acknowledge that, under Carrot's crediting program and corresponding methodologies, they assume the role of the final, key stakeholder along the waste recovery and recycling chain that transforms waste into a resource, acting also as the "Project Developer" for credit issuance purposes. The Recycler commits to informing its supply chain Participants (the waste Generator, Bin Custodians, Haulers, and Processors,) associated with the waste mass it is recycling, of the opportunity to participate in the rewards distribution that may be produced from credit sales — inviting them to onboard the Carrot platform, notifying them of the reward redemption deadline, and explaining how their data is shared and protected in accordance with Carrot's Terms and Conditions and [Privacy Policies](/docs/terms/privacy-policy).
6. They will not transfer the Environmental & Social Claims in whole or in part to any party other than the Foundation, and they will not themselves make any claims that in any way compromise the transfer of the Environmental & Social Claims to the Foundation or the party to which the Foundation further transfers the claims upon the sale and retirement of TRCs and TCCs;
7. There is no guarantee as to the number of Rewards Users will receive or whether they will receive any Rewards at all;
8. They are allowed to receive and hold Rewards in tokens, if any, according to the laws and regulations applicable to them;
9. They are not listed, or associated with any person or entity listed, on any of the US Department of Commerce's Denied Persons or Entity List, the US Department of Treasury's Specially Designated Nationals or Blocked Persons Lists, the US Department of State's Debarred Parties List, the EU Consolidated List of Persons, Groups and Entities Subject to EU Financial Sanctions, or the Swiss SECO's Overall List of Sanctioned Individuals, Entities and Organizations, and neither they nor any of their affiliates, officers or directors is a resident of a country or territory that has been designated as non-cooperative with international anti-money laundering principles or procedures by an intergovernmental group or organization, such as the Financial Action Task Force on money laundering;
10. They confirm not to be resident of, citizen of or located in a geographic area that is subject to UN-, US-, EU-, Swiss, Brazil-, or any other sovereign country sanctions or embargoes (including, but not limited to: Belarus, Burundi, Central African Republic, Congo, DPRK (North Korea), Guinea, Guinea-Bissau, Iran, Iraq, Lebanon, Libya, Mali, Myanmar (Burma), Republic of South Sudan, Russia, Somalia, Sudan, Syria, Ukraine, Venezuela, Yemen, or Zimbabwe);
11. They are not domiciled in or organized under the laws of any country, whose legislation conflicts with the present allocation of tokens and/or the purpose of the Foundation in general;
12. The Contributor understands and agrees that it is not entitled to sell, donate, pledge or transfer in any other way the tokens to persons as defined in items \[9–11] above;
13. They have such knowledge and experience in financial and business matters that they are capable of evaluating the merits and risks of agreeing to these Terms and using the Network and Websites;
14. They have a deep understanding of the functionality, usage, storage, transmission mechanisms and intricacies associated with cryptographic tokens and blockchain-based software systems;
15. They have been advised that the use of the Website, the Network and related smart contracts and the tokens to be transferred by/to/from them hereunder may, in certain jurisdictions, be considered securities, and that such issuance and/or transfer may be subject to securities laws;
16. All information provided by them is true, current, accurate and complete, and they do not act on behalf of any third party;
17. They are using the Websites, the Network and/or related smart contracts in line with the Code of Conduct, as determined in these Terms and Conditions, and under no circumstances shall be used for any illegal purposes;
18. They understand and expressly accept that there is no warranty whatsoever on the Website, the Network and/or related smart contracts, expressed or implied, to the extent permitted by law, and that the use of Websites or Network is at their own and sole risk on an "as is" and "under development" basis and without, to the extent permitted by law, any warranties of any kind, including, but not limited to, warranties of title or implied warranties, merchantability or fitness for a particular purpose. They are aware that they will not receive money or any other compensation for any damages they might incur in connection with the use of the Network or Websites;
19. They have not relied on any representations or warranties made by the Foundation or any other person outside of those made in these Terms, including but not limited to, conversations of any kind, whether through oral or electronic communication or any presentation, technical paper, social media content or website posting;
20. They have not granted any other party any rights that conflict with the rights granted herein;
21. THEY HEREBY WAIVE THE RIGHT TO PARTICIPATE IN ANY CLASS-ACTION LAWSUIT OR CLASS-WIDE ARBITRATION AGAINST ANY ENTITY OR INDIVIDUAL INVOLVED IN THE DEVELOPMENT OR PROVISION OF THE WEBSITES, THE NETWORK AND/OR RELATED SMART CONTRACTS.
## 14. Representations and Warranties of the Foundation [#14-representations-and-warranties-of-the-foundation]
The Foundation represents and warrants to the Users the following, and acknowledges that the Users are relying on these representations and warranties:
1. The Foundation is a foundation duly organized, validly existing, and in good standing under the laws of Switzerland and has all requisite corporate power and authority to carry on its statutory purpose and operation as now conducted and as presently proposed to be conducted.
2. The Foundation has all the requisite power and authority to carry out and perform its obligations under these Terms. These Terms constitute a legal, valid, and binding obligation of the Foundation enforceable against the Foundation in accordance with its terms, except that such enforceability may be limited by applicable bankruptcy, insolvency, reorganization, moratorium, and similar laws of general application relating to or affecting creditors' rights generally and by equitable principles (regardless of whether enforcement is sought in a proceeding in equity or at law).
3. The execution, delivery, and performance under these Terms require no approval or other action from any person other than the Foundation.
4. There are no actions pending or threatened against or by the Foundation or any affiliate of the Foundation that challenge or seek to prevent, enjoin, or otherwise delay the transactions contemplated by these Terms. No event has occurred, or circumstances exist that may give rise to or serve as a basis for any such action.
## 15. Indemnifications [#15-indemnifications]
Users agree to the fullest extent permitted by applicable law, to indemnify, defend, and hold harmless the Foundation, and its respective past, present, and future employees, officers, directors, contractors, consultants, equity holders, suppliers, vendors, service providers, parent companies, subsidiaries, affiliates, agents, representatives, predecessors, successors, and assigns (individually and collectively, the "Foundation Parties"), from and against all actual or alleged claims, damages, awards, judgments, losses, liabilities, obligations, penalties, interests, fees, expenses (including, without limitation, attorneys' fees and expenses), and costs (including, without limitation, court costs, costs of settlement, and costs of pursuing indemnification and insurance), of every kind and nature whatsoever, whether known or unknown, foreseen or unforeseen, matured or unmatured, or suspected or unsuspected, in law or equity, whether in tort, contract, or otherwise (collectively, "Claims"), including, but not limited to, damages to property or personal injury, that are caused by, arise out of or are related to (a) misuse of the Website, (b) any Feedback Users provide, (c) violation or breach of these Terms (in particular but not exhaustively Section 5 of these Terms) or applicable law, (d) violation of the rights of or obligations to a third-party, including another User, and (e) Users negligence or willful misconduct. They agree to promptly notify the Foundation of any Claims and cooperate with the Foundation Parties in defending such Claims. They further agree that the Foundation Parties shall have control of the defense or settlement of any Claims. This indemnity is in addition to, and not in lieu of, any other indemnities as set forth in a written agreement between Users and the Foundation.
User accepts and acknowledges the risks related to the use of the Network, as set forth in these Terms. The User acknowledges and agrees that, while Carrot applies data security measures and software management, including encryption and cryptography, Carrot is not responsible for any risk related to the use of the Network including, but not limited to, the activity, personal data, and service obligations of the User. Notwithstanding, Carrot's liability for any losses and damages due to the breach of these Terms shall be limited to the total amount of payments made by the User to Carrot in connection with any Network services in the prior twelve (12) months. Any indirect damages are expressly excluded from Carrot's liabilities, including, but not limited to, loss of opportunity, damages, consequential damages, reputational damage, or other.
## 16. Disclaimers [#16-disclaimers]
Users' access to and use of the Websites, the Network and related smart contracts are at their own risk. They understand and agree that the service is provided on an "as is" and "as available" basis, and the Foundation expressly disclaims warranties or conditions of any kind, either express or implied. The Foundation and its officers, employees, directors, shareholders, parents, subsidiaries, affiliates, agents, and licensors make no warranty or representation and disclaim all responsibility for whether the services of the Foundation: (a) will meet Users' requirements; (b) will be available on an uninterrupted, timely, secure, or error-free basis; or (c) will be accurate, reliable, complete, legal, or safe. The Foundation disclaims all other warranties or conditions, express or implied, including, without limitation, implied warranties or conditions of merchantability, fitness for a particular purpose, title and non-infringement.
The Foundation will not be liable for any kind of action taken or taken in reliance on material or information contained on the Websites or Network.
While the Foundation attempts to make the access to and use of the Websites and Network safe, it cannot and does not represent or warrant that the Network or Websites will be available at all times, free of viruses or other harmful components. While the Foundation takes data security seriously and employs solutions such as encryption and cryptography, it cannot guarantee the security of any data that Users disclose online. No advice or information, whether oral or obtained from the Foundation parties or through the service, will create any warranty or representation not expressly made herein. Users accept the inherent security risks of providing information and dealing online over the internet and will not hold the Foundation responsible for any breach of security.
The liability of the Foundation for direct and indirect damages — regardless of the legal ground — is expressly excluded to the maximum extent permitted by law. Likewise, contractual liability for actions or omissions of auxiliary persons, as well as the non-contractual liability of the Foundation is excluded to the maximum extent permitted by law. The Foundation will not be responsible or liable to Users for any loss and take no responsibility for, and will not be liable to Users for, any use of the Website, the Network, and related smart contracts, content, and/or content linked to or associated with any losses, damages, or claims arising from: (a) Users error, incorrectly constructed transactions, or mistyped addresses; (b) server failure or data loss; (c) unauthorized access or use; (d) any unauthorized third-party activities, including without limitation the use of viruses, phishing, brute-forcing or other means of attack against the service. Notwithstanding the foregoing, nothing in this Section shall exclude or limit Carrot's liability for direct damages arising from Carrot's own breach of these Terms, which shall remain subject to the liability cap set forth in Section 15.
The Foundation is not responsible or liable for any sustained losses or injury due to vulnerability or any kind of failure, abnormal behavior, or software (e.g., wallet, smart contract), the Website, the Network, and related smart contracts. The Foundation is not responsible for losses or injury due to late reports by developers or representatives (or no report at all) of any issues with the Website, the Network, and/or related smart contracts.
The Foundation is not responsible for the correct recording of circular economy actions on the Network. Any and all liability of the Foundation in connection with the erroneous, omitted or failed recording of circular economy actions on the Network is explicitly excluded. However, the Foundation shall remain liable for direct damages caused by errors in the recording of circular economy actions attributable to its own systems or processes, subject to the liability cap set forth in Section 15.
The foregoing does not affect any warranties that cannot be excluded or limited under applicable law. To the extent the Foundation may not, as a matter of applicable law, disclaim any (implied) warranty, the scope and duration of such warranty shall be the minimum permitted by applicable law.
## 17. Risks [#17-risks]
Users accept and acknowledge the risks connected to the use of Websites, the Network, and related smart contracts. In particular, but not exhaustively, the Users understand the inherent risks listed hereinafter. By using the Website, the Network, and/or related smart contracts, the Users acknowledge and assume these risks:
### 17.1 Risk of Software Weaknesses [#171-risk-of-software-weaknesses]
The Users understand and accept that the Network and related smart contracts, other involved software and technology as well as technical concepts and theories are still unproven in a live (non-test) environment, which is why there is no warranty that the process for setting up communities and initiatives, issuing, receiving, use and ownership of the tokens will be uninterrupted or error-free and there is an inherent risk that the software and related technologies and theories could contain weaknesses, vulnerabilities or bugs causing, inter alia, the complete loss of the tokens.
The Users particularly understand and accept that the Network and related smart contracts are (once decentralized) immutable and that, consequently, it may be difficult or impossible to cure software weaknesses.
### 17.2 Regulatory Risk [#172-regulatory-risk]
The regulatory regime governing blockchain technologies, cryptocurrencies, and tokens is uncertain, and new regulations or policies may materially adversely affect the use of the Website, the Network and/or related smart contracts.
The Users understand and accept that blockchain technology allows new forms of interaction. There is a possibility that certain jurisdictions will apply existing regulations or introduce new regulations addressing blockchain technology-based applications, in a way that may be contrary to the current setup and which may, inter alia, result in substantial modifications to the Website, the Network and/or related smart contracts, including the termination of the Project and the loss of the tokens or their functionality for the Users.
The Users understand and accept that certain regulators may nevertheless qualify tokens as securities or other financial instruments under their applicable law. It remains in the Users responsibility to comply with any laws and regulations applicable to the Users when holding or transferring tokens.
The Users explicitly accept and acknowledge that the Foundation assumes no liability for any and all risks relating to taxation or regulatory issues in connection with the use of the Website, the Network, and/or related smart contracts. It remains the sole responsibility of the Users to seek local legal, tax, and regulatory advice.
### 17.3 Risk of Abandonment / Lack of Success [#173-risk-of-abandonment--lack-of-success]
A lack of use or public interest in the creation and development of distributed ecosystems could negatively impact the development of those ecosystems and related applications and could therefore also negatively impact the potential utility or value of the Website, the Network and/or related smart contracts.
### 17.4 Risk of Third-Party Providers [#174-risk-of-third-party-providers]
The services of the Foundation may rely on third-party software. If the Foundation is unable to maintain a good relationship with such third parties; if the terms and conditions or pricing of such third parties change; if the Foundation violates or cannot comply with the terms and conditions of such third parties; or if any of such third parties loses market share or falls out of favor or is unavailable for a prolonged period of time, access to and use of the Website, the Network and/or related smart contracts may suffer.
### 17.5 Risk of Private Key Loss [#175-risk-of-private-key-loss]
Tokens allocated to a particular address can only be accessed with the private key that corresponds to that address. The Users understand and accept that if the private key file or wallet password were lost or stolen, the access to the Users' address as well as to the tokens allocated to them would be unrecoverable and would be permanently lost. The Foundation neither has control over the Users' addresses; therefore, the Users shall have no recourse to seek any refunds, recovery, or replacements from the Foundation in the event that they cannot access other Users' address as well as to the tokens anymore and/or any tokens are lost or stolen.
### 17.6 Risk of Theft [#176-risk-of-theft]
The Users understand and accept that, while best efforts are made to reduce potential software attacks on the Website, the Network and related smart contracts, other involved software, and/or other technology components may be exposed to attacks by hackers or other individuals that could result in theft or loss of the tokens.
### 17.7 Risk of Network Attacks and Forks [#177-risk-of-network-attacks-and-forks]
The User understands and accepts that, as with other blockchains, the blockchain used for the Network could be susceptible to consensus-related attacks, including but not limited to double-spend attacks, majority validation power attacks, censorship attacks, and byzantine behavior in the consensus algorithm, or be subject to forks. Any successful attack or fork presents a risk to the Network and/or related smart contracts, the expected proper execution and sequencing of token transactions, the expected proper execution and sequencing of contract computations, as well as the token balances in the wallet of the Users.
There are risks associated with using Internet and blockchain-based products, including but not limited to, the risk associated with hardware, software, and internet connections, the risk of malicious software introduction, and the risk that third parties may obtain unauthorized access to information stored within User Account. Users accept and acknowledge that the Foundation will not be responsible for any communication failures, disruptions, errors, distortions, or delays they may experience when using the Website, the Network and/or related smart contracts for transactions, however caused.
## 18. Data Protection [#18-data-protection]
18.1 In relation to the performance of its services, the Foundation may process company identification data and User's personal data to ensure that Participants are properly identified and their User, Organization and Data declarations are accurate and in accordance with the Carrot Fndn [Privacy Policy](/docs/terms/privacy-policy).
18.2 To the extent that Network Integrators (INTs) collect personal data of other Users or third parties and disclose it to the Foundation by publishing it on the Network, it is the INT who is responsible for the lawfulness of any such Use and processing, pursuant to local privacy laws (i.e., GDPR or Article 39 of the LGPD in Brazil) and will hold the Foundation harmless in relation to any damages that arise or are claimed against the Foundation in the event of unlawful processing carried out under the INT's responsibility.
If any tools provided by the Network are utilized by the INT to assist in personal data protection, it is the INT's responsibility to ensure that the tools are utilized properly and kept up-to-date.
18.3 By accepting these Terms, the User agrees that their identification data will be used for the purposes of validating chain of custody and performing multiparty verification. Carrot, through its Network Integrators, Recyclers, and Auditors guarantee that the identification data of Generators and Transporters will be treated as private and masked on the Explorer and any public interface and managed in strict compliance with the local privacy laws. Public disclosure of such data is conditional upon the User's declared consent upon onboarding. Data from the entire chain of custody will remain visible at all times to the Foundation and accredited auditors for the purposes of verification and certification by independent third parties, as required for issuing high-integrity and regulatory-eligible credits (tokens). The foregoing does not apply to the public disclosure of organizational-level environmental impact data under Section 7A (Impact Recognition Program), which is governed exclusively by the terms of that Section.
18.4 Each party is responsible for adherence to local privacy laws concerning personal data management under its effective control and processing. The Foundation's liability is limited to personal data processed directly by it or under its instruction and does not extend to data processed by INTs, sub-processors contracted by Users themselves, or third parties outside the Foundation's operational scope.
18.5 The Foundation implements and maintains appropriate technical and administrative measures to protect personal data against unauthorized access, destruction, loss, alteration, or improper disclosure, as detailed in the [Privacy Policy](/docs/terms/privacy-policy). Notwithstanding, Users acknowledge that no technological system offers absolute security and that the Foundation shall not be liable for security incidents arising exclusively from zero-day vulnerabilities not yet identified by the security community, state-level or critical infrastructure attacks beyond the Foundation's reasonable control, or failures in third-party systems, networks, or infrastructures over which the Foundation has no direct operational control.
18.6 In the event of a security incident that may entail relevant risk or harm to data subjects, the Foundation will notify the relevant supervisory authority and the affected data subjects within the applicable legal deadlines: 72 (seventy-two) hours for the GDPR supervisory authorities (GDPR, Art. 33) and the ANPD (LGPD, Art. 48 and Resolution CD/ANPD No. 15/2024); and as quickly as possible for the FDPIC (revDSG, Art. 24). Notification shall include (i) the nature of the affected data; (ii) information on the data subjects involved; (iii) technical measures adopted; and (iv) risks related to the incident and actions taken to mitigate their effects.
18.7 Users are responsible for protecting the privacy of personal data of other Users and third parties under their control or inserted into the Network. In the event of gross negligence, intentional leakage, or attacks promoted or facilitated by the User, the Foundation may adopt the measures set forth in Section 11 of these Terms, including suspension, penalties, and legal action, without prejudice to applicable civil and criminal liability.
18.8 One party shall not be held liable for acts, omissions, or violations of data protection legislation committed by the other party, its agents, and/or contractors.
18.9 Failure to comply with the obligations set forth in the aforementioned data protection laws and in this contract by the user will result in its immediate termination.
Attention should be given to laws such as the EU's General Data Protection Regulation (GDPR)[^1], The Council of Europe's Convention for the Protection of Individuals with regard to Automatic Processing of Personal Data[^2], the California Consumer Privacy Act (CCPA)[^3] and Brazil's General Law for Protection of Personal Data (LGPD)[^4], to name a few.
[^1]: EU: General Data Protection Regulation — gdpr.eu
[^2]: ETS No. 108, Convention for the Protection of Individuals with regard to Automatic Processing of Personal Data, Council of Europe (CoE).
[^3]: California Privacy Protection Agency: The California Privacy Rights Act of 2020 — cppa.ca.gov/regulations/
[^4]: LEI Nº 13.709, DE 14 DE AGOSTO DE 2018. BRASIL, Lei Geral de Proteção de Dados Pessoais (LGPD) — planalto.gov.br/ccivil\_03/\_ato2015-2018/2018/lei/l13709.htm
## 19. Modifications to the Website [#19-modifications-to-the-website]
The Foundation reserves the right, in its sole discretion, to modify, suspend, or discontinue, temporarily or permanently, the provision of its Websites or Network (or any features or parts thereof) at any time and without liability as a result. The Foundation commits to communicating such actions to Participants in advance on every occasion, except when the action taken is necessary to protect the security of all Participants.
## 20. Tax [#20-tax]
The Users are solely responsible for determining what, if any, taxes apply to their use of the Website, the Network, and/or related smart contracts, as well as to the transfer of Environmental & Social Claims. The Foundation is not responsible for determining or paying the taxes that apply to such use.
## 21. Miscellaneous [#21-miscellaneous]
### 21.1 Relationship of the Parties [#211-relationship-of-the-parties]
The Foundation and the Users are independent contractors. These Terms do not create, nor are they intended to create, a partnership, franchise, joint venture, agency, fiduciary, or employment relationship between the Parties.
### 21.2 Severability [#212-severability]
If any provision of these Terms is invalid, illegal, or unenforceable in any jurisdiction, such invalidity, illegality, or unenforceability shall not affect any other provision of the Terms or invalidate or render unenforceable such provision in any other jurisdiction. Upon such determination that any provision is invalid, illegal, or unenforceable, the Terms shall be modified to effectuate the original intent of the original provision as closely as possible.
### 21.3 Assignment [#213-assignment]
Notwithstanding the possibility to grant access to the User Account to other Users, Users may not assign or transfer any rights and licenses granted under these Terms, without the prior written (text form sufficient) consent of the Foundation. The Foundation may freely assign or transfer any rights and licenses granted under these Terms without restriction, upon communication to the Users and Participants informing them of such assignments.
### 21.4 Applicable Law and Jurisdiction [#214-applicable-law-and-jurisdiction]
These Terms, as well as the use of the Website, the Network, and related smart contracts, shall be governed by and construed in accordance with the substantive laws of Switzerland. The application of the United Nations Convention on Contracts for the International Sale of Goods shall be excluded.
Any dispute arising out of or in conjunction with these Terms shall be submitted to the exclusive jurisdiction of the courts of the city of Zug, Switzerland.
Notwithstanding the choice of Swiss law and jurisdiction set forth above, where mandatory consumer protection laws, data protection regulations, or other non-waivable statutory provisions of the User's jurisdiction of residence grant rights or protections that cannot be excluded or limited by contract, such mandatory provisions shall apply to the extent required by applicable law. This carve-out does not affect the validity or enforceability of any other provision of these Terms, nor does it constitute a waiver of Swiss law as the governing law for all matters that the parties may freely contract upon.
For the avoidance of doubt: (i) this provision applies where local law is mandatory and cannot be displaced by contract, such as consumer protection statutes, data protection laws, and labor regulations; (ii) it does not apply to commercial or operational matters freely governed by these Terms; and (iii) the class-action waiver set forth in Section 13(21) applies to the fullest extent permitted by the applicable mandatory law of the User's jurisdiction.
# Withdrawal of a Credit Purchase
{/* Deliberately absent from terms/meta.json so it stays out of the sidebar — this page is reached from Clause 7.1 of the sale terms, not one of the four instruments a reader browses. Adding it to `pages` would undo that. It still routes, is indexed, and appears in the sitemap. */}
**Companion to the [Terms and Conditions of Sale of Environmental Credits](/docs/terms/credit-sales-terms), Clause 7.**
## Your right of withdrawal [#your-right-of-withdrawal]
If you purchased Environmental Credits as a **consumer**, you may withdraw from the purchase within the legal period of your country of domicile, as provided in Clause 7 of the [Terms and Conditions of Sale of Environmental Credits](/docs/terms/credit-sales-terms):
* **Brazil:** 7 calendar days from purchase confirmation (Article 49 of the Consumer Defense Code). This right is preserved even if you chose immediate Retirement.
* **European Economic Area and United Kingdom:** 14 days from purchase confirmation — unless you expressly consented to immediate Retirement and acknowledged the loss of the withdrawal right at checkout, in which case the right ends when Retirement occurs.
* **Other countries:** as the law of your domicile provides. If your country provides no withdrawal right, purchases are final once completed; our support policy still applies.
The effects of withdrawal depend on the state of your Credits (in your Account, retired at your express request, or transferred) and are described in Clause 7.2 of the Terms. Refunds are made by the same payment method you used.
## How to withdraw [#how-to-withdraw]
Contact us within the legal period at **[support@carrot.eco](mailto:support@carrot.eco)** and state clearly that you wish to withdraw from the purchase. **No particular form of words is required** — any clear statement is sufficient. We will confirm receipt of your request without delay.
So that we can identify the order, please include:
* the order number, or a description of the Credits purchased;
* the date of the purchase;
* the name of the consumer or consumers who made the purchase;
* the e-mail address used for the purchase.
# AMS-III.F Overview
## Overview [#overview]
**AMS-III.F** is a [UNFCCC Clean Development Mechanism](https://unfccc.int/process-and-meetings/the-kyoto-protocol/mechanisms-under-the-kyoto-protocol/the-clean-development-mechanism) (CDM) methodology titled "Avoidance of methane emissions through composting" (v12.0). It provides the scientific and regulatory basis for quantifying greenhouse gas emission reductions achieved by diverting organic waste from landfills to aerobic composting facilities.
The methodology quantifies the CO₂-equivalent emission reductions achieved by composting waste instead of sending it to a landfill, where it would decompose anaerobically and generate methane (CH₄).
* **Official reference**: [AMS-III.F on UNFCCC CDM](https://cdm.unfccc.int/methodologies/DB/NZ83KB7YHBIA7HL2U1PCNAOCHPUQYX)
* **Version**: 12.0
* **Credit type**: Carbon Credit — Tokenized Carbon Credits ([TCC](/docs/protocol/credits#tokenized-carbon-credits-tcc))
* **On-chain token**: `C-CARB.CH4` (methane reductions)
## Digital implementation of AMS-III.F [#digital-implementation-of-ams-iiif]
AMS-III.F matters because organic waste in landfills is one of the largest sources of anthropogenic methane, accounting for approximately 11% of global CH₄ emissions. Composting is a proven, scalable solution — but historically, measuring and verifying the resulting emission reductions has been expensive and manual, limiting participation to large-scale projects.
The BOLD Carbon framework implements AMS-III.F through Carrot's digital MRV ([dMRV](/docs/protocol/dmrv)) infrastructure via the [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) framework (MvF), which translates the methodology into automated, transparent verification logic. This enables:
* **Small-scale facility participation** — dMRV reduces verification costs, reducing barriers to carbon credit issuance for smaller facilities.
* **Continuous verification** — Instead of periodic audits, every batch of composted waste is verified individually through [MassID](/docs/protocol/mass-ids) chain of custody tracking.
* **Open-source rules** — All verification logic is publicly auditable under LGPL-3.0, so anyone can inspect how credits are calculated.
* **Supply chain rewards** — Proceeds from credit purchases are distributed to every participant in the supply chain, not only the facility operator.
Each `C-CARB.CH4` credit represents 1 metric ton of CO₂-equivalent emission reductions. Composting 1 ton of food waste mixed with 1 ton of green waste prevents over 2 tons of CO₂e compared to landfill disposal without methane capture.
## Scientific basis [#scientific-basis]
AMS-III.F relies on established environmental science from the UNFCCC CDM:
* **Baseline emissions**: Calculated using [UNFCCC CDM Tool 04](https://cdm.unfccc.int/methodologies/PAmethodologies/tools/am-tool-04-v8.0.pdf) — emissions from solid waste disposal sites (landfills and dumps)
* **Real emissions from composting**: Calculated using [UNFCCC CDM Tool 13](https://cdm.unfccc.int/methodologies/PAmethodologies/tools/am-tool-13-v2.pdf) — project and leakage emissions from composting
* **Source methodology**: [UNFCCC AMS-III.F](https://cdm.unfccc.int/methodologies/DB/NZ83KB7YHBIA7HL2U1PCNAOCHPUQYX) v12.0 — "Avoidance of methane emissions through composting" (verbatim CDM title; Carrot uses reduction-tier vocabulary in its own prose)
The core calculation: **Emission Reductions = Baseline Emissions - Real Emissions**
## Scope [#scope]
* **Facility type**: Small-scale, off-site professional aerobic composting facilities (SSC)
* **Waste types**: Food waste and green waste (garden/yard trimmings)
* **Baseline scenarios**: Landfill without methane capture, landfill with methane flaring, dump site
* **Verification**: dMRV with [MassID](/docs/protocol/mass-ids) chain of custody tracking
* **Credit issuance**: [GasID certificates](/docs/protocol/certificates#gasid) → `C-CARB.CH4` credit tokens
## How it works [#how-it-works]
1. Organic waste is verified as composted through [BOLD Recycling](/docs/methodologies/bold-recycling), generating RecycledID certificates.
2. The composting facility's mix ratio (food waste to green waste) is verified.
3. Baseline emissions are calculated based on the local waste disposal scenario.
4. Real emissions from composting are calculated using verified facility data.
5. The difference (emission reductions) generates [GasID certificates](/docs/protocol/certificates#gasid).
6. GasID certificates are created and corresponding `C-CARB.CH4` credits are minted.
7. Proceeds from credit purchases are distributed per the [Rewards Distribution Policy](/docs/standard/policies/rewards-distribution).
Use the [Credit Calculator](/docs/standard/guides/credit-calculator) to estimate TCC potential
from organic waste composting.
## Carrot framework [#carrot-framework]
AMS-III.F is implemented on the Carrot Network through the **[BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon)** framework (MvF). BOLD Carbon translates the CDM methodology into concrete verification rules, formulas, and data requirements that can be executed as automated dMRV.
## Resources [#resources]
* [View on Carrot Registry](https://registry.carrot.eco/document/9498dd79-97ca-4efb-b47d-a8b61cf1f995)
* [BOLD Carbon (CH₄) Methodology Framework (PDF)](https://drive.google.com/file/d/1TwEGKA_YAhgsb_1pFmbVxZxNN5uVEVY6/view)
* [AMS-III.F on UNFCCC CDM](https://cdm.unfccc.int/methodologies/DB/NZ83KB7YHBIA7HL2U1PCNAOCHPUQYX)
Feedback: [method@carrot.eco](mailto:method@carrot.eco)
[Learn about BOLD Recycling](/docs/methodologies/bold-recycling) · [View BOLD Carbon (CH₄) framework](/docs/methodologies/ams-iii-f/bold-carbon) · [Learn about rewards distribution](/docs/standard/policies/rewards-distribution)
# BOLD Recycling Credit Overview
## Overview [#overview]
The **BOLD (Breakthrough in Organics Landfill Diversion) Recycling Credit** is a digital MRV ([dMRV](/docs/protocol/dmrv)) methodology for verifying organic waste diversion from landfills to aerobic composting facilities. BOLD Recycling's methodology rules verify that organic waste has been properly sorted, collected, transported, and composted at a professional facility. [Rewards](/docs/protocol/rewards-distribution) for every participant in the supply chain are calculated and committed on-chain when a credit from the resulting [certificate](/docs/protocol/certificates) is sold, and paid out afterwards.
BOLD Recycling generates [Tokenized Recycling Credits (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc), represented on-chain as `C-BIOW` tokens. Each credit represents 1 metric ton of verified composted organic material. (Other recycling methodologies may issue TRCs with different on-chain symbols.)
## Why organic waste? [#why-organic-waste]
Organic waste represents approximately 50% of global waste and is 100% recyclable, yet most of it ends up in landfills. This matters for two interconnected reasons:
1. **Methane emissions** — Organic waste decomposing anaerobically in landfills generates approximately 11% of global methane emissions. Diverting organic waste to composting dramatically reduces these emissions.
2. **Recycling contamination** — When organic waste is mixed with recyclable materials (metals, glass, paper, plastic), it contaminates those streams and reduces recovery rates. Removing organic waste can improve sorting facility performance by 2–5x.
The transition to a circular economy begins with sorting organic waste from other recyclable streams — this is the challenge BOLD Recycling addresses.
## Scope [#scope]
BOLD Recycling covers the full supply chain from waste generation to composting:
* **Waste types**: Food waste, green waste (garden/yard trimmings), sludge from waste treatment plants, tobacco industry residues
* **Treatment**: Aerobic composting at professional facilities
* **Verification**: dMRV using [MassIDs](/docs/protocol/mass-ids) for chain of custody tracking
* **Credit issuance**: [RecycledID certificates](/docs/protocol/certificates#recycledid) → `C-BIOW` credit tokens
## How it works [#how-it-works]
1. Organic waste is sorted at the source by [Waste Generators](/docs/protocol/supply-chain).
2. [MassIDs](/docs/protocol/mass-ids) track the waste through collection, hauling, and processing.
3. The waste arrives at an accredited composting facility where recycling is verified through dMRV.
4. [Certificates](/docs/protocol/certificates) are issued and credits are minted.
5. Proceeds from credit purchases are distributed per the [Rewards Distribution Policy](/docs/standard/policies/rewards-distribution).
Use the [Credit Calculator](/docs/standard/guides/credit-calculator) to estimate TRC potential
from organic waste composting.
## Resources [#resources]
* [View on Carrot Registry](https://registry.carrot.eco/document/31f1ff32-fdc5-469a-9d30-caf0be89b50a)
* [BOLD Recycling Methodology (PDF)](https://drive.google.com/file/d/1Qdod8Qy3zT4lBkUp1TIyuxguHIYTevJJ/view)
Feedback: [method@carrot.eco](mailto:method@carrot.eco)
[Learn about AMS-III.F](/docs/methodologies/ams-iii-f) · [Learn about rewards distribution](/docs/standard/policies/rewards-distribution) · [View rules catalog](/docs/methodologies/bold-recycling/framework/application/application-rules) · [View framework](/docs/methodologies/bold-recycling/framework) · [View application](/docs/methodologies/bold-recycling/framework/application)
# Digital Public Infrastructure
{/* cspell:words Aadhaar X-Road UNDP */}
## A market that needs forming [#a-market-that-needs-forming]
Solving the world's hardest problems — climate change, the stewardship of natural resources, human development — depends on economies that value **public goods**, not only private ones. The difficulty is that the markets such an economy requires barely exist: the outcomes that matter most — a stable climate, clean air and water, recovered materials, healthy and productive communities — benefit everyone, yet are paid for by almost no one. And forming those markets is a **coordination problem** that neither companies nor governments, acting alone, are positioned to solve.
Forming them takes three things at once: a **financing system** that directs capital to verified outcomes rather than promises; a **technology layer** that makes those outcomes trustworthy — measured, independently verified, uniquely recorded, transparently settled; and an **organization** bound to a public purpose it cannot quietly abandon, to steward that layer. Digital public infrastructure is where those three meet — and the Carrot Network is Carrot's working contribution to it.
## What "digital public infrastructure" means [#what-digital-public-infrastructure-means]
Digital Public Infrastructure (DPI) is the term used across the UCL Institute for Innovation and Public Purpose, the United Nations Development Programme, the World Bank, and the G20 for digital systems that work as shared, society-wide rails rather than proprietary platforms: **foundational**, **interoperable**, **inclusive**, and **publicly accountable**. The reference cases are the foundational layers of identity, payments, and data exchange — India's Aadhaar and UPI, Brazil's Pix, Estonia's X-Road. The Carrot Network applies the same pattern to a domain those cases have not reached: **outcomes-based funding for environmental and social advancement**, beginning with waste reduction, recycling, and methane — and built to extend to other environmental domains.
Its core components are **digital public goods** — the open parts the rails are made of: open [methodology frameworks](/docs/methodologies), a [public credit registry](/docs/registry), and [open-source verification code](https://github.com/carrot-foundation/methodology-rules) that any operator, verifier, methodology author, or application developer can build on. Together they operate as **a public registry for the circular economy** — an open, digital MRV and crediting infrastructure on which established standards, registries, and buyer coalitions can build.
## What makes infrastructure "public" [#what-makes-infrastructure-public]
In the DPI literature, what makes infrastructure public is not who builds or owns it, but **how it is governed** — whether it is created and governed for the common good. The Carrot Network is built to meet that test through mechanism, not assurance:
* **Purpose, locked.** The network is stewarded by the [Carrot Foundation](/docs/network/the-foundation), a Swiss foundation whose purpose is fixed in its deed, externally supervised, and cannot be redirected toward private gain.
* **Open rules.** The verification code that executes each methodology is open source and publicly inspectable; methodology frameworks are versioned and documented.
* **Independent verification.** Verification is executed by deterministic software and reviewed by independent validation and verification bodies — not by Carrot itself.
* **Public records.** Credit issuance, transfer, and retirement are recorded on a public registry anyone can audit.
* **Reward-sharing.** Under transparent, published fees, 100% of proceeds fund the ecosystem and the network that serves it: proceeds from every credit sale flow to the people who do the environmental work, under the published [Rewards Distribution Policy](/docs/standard/policies/rewards-distribution) — [governed](/docs/network/governance), not discretionary.
## What the rails enable [#what-the-rails-enable]
Because the rails make outcomes **measurable, verifiable, and bankable**, they open a path markets have struggled to build: buyers and coalitions can commit to verified results before those results exist — advance, outcomes-based commitments that de-risk the producers who deliver them. The Carrot Network provides the verification, unique recording, and settlement such commitments require; it does not run market commitments or act as a buyer. And far from competing with government, the infrastructure is built to work with the public sector and lighten its load — the state keeps its mandate, regulatory authority, and role as backstop. What the network guarantees, a regulator can choose to endorse or reject at any time.
## Go deeper [#go-deeper]
The full argument — the market-formation case, the public-governance test, how the network is funded, the safeguards we design against, and what the model means for funders, participants, buyers, and governments — is in the White Paper:
**→ [White Paper: Digital Public Infrastructure for Global Climate Finance](/docs/network/white-paper)** *(read online or download the PDF)*
**Related pages:** [The Network](/docs/network) · [Governance](/docs/network/governance) · [The Carrot Foundation](/docs/network/the-foundation) · [Rewards Distribution Policy](/docs/standard/policies/rewards-distribution)
# White Paper: Digital Public Infrastructure for Global Climate Finance
{/* cspell:words Mazzucato Vasconcellos Aadhaar X-Road MOSIP UNDP Ransohoff Symbiosis IHLEG Baku Belem Belém LGPD GDPR UCL IIPP ODET Lemos Mckee Doria LTDA Eloverde Gavi Nilekani Omidyar permissioned non-rivalrous non-excludable minimization */}
*Ian McKee · Marcelo Doria — Carrot Foundation*
**v1.6 · July 2026** · [Download PDF](/downloads/dpi/Carrot-DPI-White-Paper-Circular-Economy-2026-v1.6.pdf)
For the short version, see [Digital Public Infrastructure](/docs/network/digital-public-infrastructure).
## Shaping the economy we need [#shaping-the-economy-we-need]
Solving the world's hardest problems — among them climate change, the stewardship of natural resources, and human development — will depend on building more sustainable economic systems, and on new kinds of technology to enable them. A sustainable economy is one that values **public goods**, not only private ones. The difficulty is that the markets such an economy requires barely exist: the outcomes that matter most — a stable climate, clean air and water, recovered materials, restored land, healthy and productive communities — benefit everyone, yet are paid for by almost no one. Public rules and private markets each carry part of the load, but neither, on its own, reliably directs capital toward the results society needs collectively.
The scale of what fails to flow makes this concrete. Under the UN climate process, the Baku-to-Belém roadmap puts the external finance the Global South will need for climate action at about **US$1.3 trillion a year by 2035**. In 2023, the total that arrived from abroad was about **US$196 billion** — roughly **15 percent** of what will be needed. And the gap is widest exactly where a market should be: private capital is expected to supply about half of the target, yet cross-border private climate finance came to only some **US$42 billion** — it would need to grow roughly **fifteenfold** (Climate Policy Initiative, 2025).
A shortfall of that size is not a market malfunctioning at the margin, waiting for a correction; it is a market that has **never been formed**. And it persists because market formation is, above all, a **coordination problem** — one that neither companies nor governments, acting alone, are positioned to solve. No single company can build a market whose value accrues to everyone; every competitor that benefits without contributing would ride free on the investment. No single government can build one either: the problems cross borders, and consensus among many governments is slow to form. What market formation requires is a way for those ready to act — buyers, builders, funders, and public bodies alike — to coordinate at the level of the system, without waiting for unanimity at either the individual or the intergovernmental level.
Forming markets is different work from fixing them, and coordination at that level takes three things at once. It takes a **new kind of financing system** — one that points development at clear, verifiable outcomes, environmental and social alike, directing capital to results rather than promises so that value reaches the people who produce them. It takes a **new technology layer** that makes those outcomes trustworthy — measured, independently verified, uniquely recorded, and transparently settled — and that turns the tools it builds into shared public goods rather than private bottlenecks. And it takes a **new kind of organization** to steward that layer — one bound to a clearly stated purpose it cannot quietly abandon, governed transparently, and open to the participation of the people it serves.
That layer is **digital public infrastructure (DPI)**. In the form this paper describes, it sits outside government, yet works in partnership with it — and with the private sector, philanthropy, finance, technology, and science — to establish trust between parties who would not otherwise cooperate, so that capital can flow to results. Its stewardship is coordinated by a **foundation whose purpose is fixed in its deed and cannot be redirected toward private gain**. Its development is progressively opened to the people who use it: its contributors, its builders, and its participants.
**The Carrot Network is digital public infrastructure for the resource-efficient, low-carbon circular economy — the shared rails for an economy that is low-pollution, regenerative, and inclusive.** Its purpose is environmental *and* social at once: using capital more efficiently to improve circularity, cut natural-resource extraction, reduce pollution, and tackle climate change, while creating **green jobs**, income, and local opportunity for the people who do the work. The methodologies, the public registry, and the verification code that make up these rails are **digital public goods** — open, auditable, and available to anyone building on them. Carrot proves the model today in waste, recycling, and methane. Because the pattern is general and the need is far broader than waste, the same rails are built to extend to other environmental domains — water, nature, and biodiversity among them. The low-carbon circular economy is therefore the case this paper works in full — and the pattern it demonstrates is the one climate finance needs wherever an outcome has to be verified before it can be paid for.
And because those open tools make outcomes **measurable, verifiable, and bankable**, they open a path markets have struggled to build: buyers can commit to results before those results exist, and de-risk the investment needed to produce them. Coordinated, that demand becomes a new kind of climate and development finance — one that pays for outcomes, not promises.
## What "digital public infrastructure" means [#what-digital-public-infrastructure-means]
Digital Public Infrastructure (DPI) is the term used across the University College London (UCL) Institute for Innovation and Public Purpose, the United Nations Development Programme, the World Bank, and the G20 for digital systems that work as shared, society-wide rails rather than as proprietary platforms. These bodies share a *family* of definitions rather than one canonical text, but they converge on a few traits: DPI is **foundational** (other services are built on top of it), **interoperable** (it works through open standards, not a single vendor's stack), **inclusive** (designed for broad access), and **publicly accountable** (governed in the open). The reference cases are the foundational layers of identity, payments, and data exchange — India's Aadhaar and UPI, Brazil's Pix, Estonia's X-Road, the open-source MOSIP. The World Bank frames the pattern as a stack of three trust functions — **trusted identity, trusted data exchange, and trusted settlement** — that, once public, other services can build on.
Closely related is the idea of **digital public goods** — the term the UN and the Digital Public Goods Alliance use for open-source software, open standards, open data, and open content that are freely reusable and adaptable. The relationship is simple: the infrastructure is the rail, and digital public goods are the open parts it is made of. DPI is *most* powerful when its core components are themselves digital public goods: non-rivalrous (one participant's use does not diminish another's) and non-excludable (open licenses and open standards let others build on the rails without permission — and, if ever needed, carry them forward independently). The Carrot Network is built to this standard: its core components are **digital public goods** — shared, inspectable resources that any operator, verifier, methodology author, or application developer can build on.
What none of these definitions require is a particular *owner*. As the UNDP and the UCL IIPP both put it, DPI is a multi-stakeholder endeavor that can be built by governments, by the private sector, by philanthropies, or by several together. The Carrot Network applies that idea to a domain the foundational cases have not reached: **outcomes-based funding for environmental and social advancement**. It builds its identity layer, methodology rules, evidence pipeline, public registry, and reward distribution as shared market rails — usable by many independent participants, and governed for the mission rather than for private gain. It begins with waste reduction via recovery, reuse, and recycling — a first domain chosen for leverage. Diverting organic waste from landfills cuts **methane**, the fastest and largest brake available on near-term warming, and the waste sector is one that can deliver it at a cost-saving at the system level (UNEP, *Global Methane Status Report*, 2025). It also opens the wider **circular economy**: an estimated two-thirds of global emissions are tied to how resources are extracted, used and discarded, and circular-economy interventions are judged capable of delivering roughly 85% of the additional emissions reductions needed beyond current national pledges to hold warming below 2°C (*Circularity Gap Report*, 2021). The transition they open is estimated at up to 76 GtCO₂e of avoided emissions through 2050 (WBCSD, *Global Circularity Protocol*).
## What makes infrastructure "public" [#what-makes-infrastructure-public]
If ownership does not decide what counts as public, what does? A rigorous recent answer comes from Mazzucato, Eaves and Vasconcellos (UCL IIPP, *Digital Public Infrastructure and Public Value: What is "public" about DPI?*, 2024). Their central finding is the one the Carrot Network is built on:
> **The "publicness" of digital infrastructure is not determined by who builds it or who owns it — but by how it is governed: whether it is created and governed for the common good.**
They show that defining DPI by its *technical attributes* (open standards, reusable components) or by its *functions* (the essential capabilities it provides) is necessary but, in their words, "broadly silent on governance." Infrastructure earns its "public" label only when explicit public values are locked in and enforced. They set out five governance principles — drawn from Mazzucato's "common good" framework — against which any candidate DPI can be measured:
* **Purpose and directionality** — the infrastructure has an explicit mission, and that mission shapes what it does.
* **Co-creation and participation** — the people who use it help shape it.
* **Collective learning and knowledge-sharing** — methods and evidence are open enough for others to learn from.
* **Access for all and reward-sharing** — value reaches participants broadly, not only the operator.
* **Transparency and accountability** — rules, decisions, and finances can be inspected.
These describe governance and outcomes, not origins. The same authors accept that shared infrastructure "can be provided both by public and private organisations, or even co-developed" — *provided that*, however it is built, a publicly accountable mechanism guarantees access and reward-sharing over time. That proviso is why the network's core components are released as digital public goods: open methodologies, an open registry, and open verification code are how "access for all" and "collective learning" stop being promises and become properties anyone can check. **It is also the standard the Carrot Network is built to meet — and the next section answers it head-on.**
## How the Carrot Network meets the public-governance test [#how-the-carrot-network-meets-the-public-governance-test]
The Carrot Network is stewarded by the **Carrot Foundation** (registered as "Carrot Fndn"), a Swiss foundation under Article 80 *et seq.* of the Swiss Civil Code, registered in Zug (UID CHE-152.448.302), constituted in October 2023 and supervised by Switzerland's Federal Supervisory Authority for Foundations (ESA). A Swiss foundation's statutory purpose (*Zweck*) cannot be altered by its own board; it is externally supervised and audited. That legal form is what lets the Foundation act as a **steward, not an owner** — it can evolve how the network operates, but it cannot redirect the network away from the purpose it exists to serve. This is the new kind of organization the opening of this paper called for: purpose stated and locked, governance transparent and externally supervised. It also answers the coordination problem at its root: a market whose value accrues to everyone can only be formed by an actor that does not need to capture that value — and a purpose-locked, non-profit steward is that actor by construction.
Measured against the five governance principles:
* **Purpose and directionality.** The Foundation's purpose — to build a low-carbon, inclusive circular economy — is recorded in its Deed and in the Swiss commercial register, and is binding under Swiss law. It is enforceable, not aspirational.
* **Co-creation and participation.** Participants across environmental-work and social-development ecosystems are direct counterparties to the network and help shape how it develops. Over time, responsibility for different aspects of the network is designed to be **managed in a distributed, decentralized way** rather than concentrated in a single operator; the network is centralized today to secure foundational quality and strong early leadership — a choice addressed openly in *Building DPI responsibly*, below — and participation broadens as it matures. *(This is a distributed-benefit and -management design, not a grant of control rights to individual stakeholders.)*
* **Collective learning and knowledge-sharing.** The verification code that executes each methodology is **open source under LGPL-3.0** and [publicly inspectable](https://github.com/carrot-foundation/methodology-rules); methodology frameworks are [versioned and documented](/docs/methodologies); the dMRV (digital Measurement, Reporting and Verification) evidence pipeline lets accredited verifiers, methodology authors, and application developers work over shared, documented rules rather than private spreadsheets.
* **Access for all and reward-sharing.** The network is open to participants across the value-adding ecosystem, and value flows to the people who do the environmental work, in proportion to verified contribution — not concentrating at the operator. Under transparent, published fees, 100% of proceeds fund the ecosystem and the network that serves it — at least 80% of every credit sale is distributed to ecosystem participants, and the remainder sustains the public rails (see *How the network is funded*, below) — and reward shares are tuned by impact type — for circular-economy outcomes, by material, territory, and role — to direct effort to where recovery is hardest. The tuning steers effort; it is contingent on a credit being issued and sold. *(A buyer owns the credit, fully on retirement; participants are rewarded for their contribution but never own the credit itself.)*
* **Transparency and accountability.** Beyond the federal supervision described above, the underlying record is immutable: there is a durable history of every transaction and every update to every data point, and the **key outputs — credit issuance, transfer, and retirement — are recorded on a [public registry](/docs/registry) that anyone can audit**. Not every part of the platform is publicly recorded, and some operational data is **permissioned to auditors and verifiers** rather than open to all — a deliberate balance between public auditability and the privacy of the people and businesses whose work is recorded, with personal and operational data encrypted and handled under applicable data-protection law and GDPR-aligned practices (see *Building DPI responsibly*, below).
## How the network is funded — and how it de-risks participation [#how-the-network-is-funded--and-how-it-de-risks-participation]
The environmental and social outcomes the network pursues are public goods, made financeable in the form of credits. The network runs on crediting systems and is supported by the sale of credits — verified environmental outcomes that a buyer pays for, described fully in *The environmental extension*, below. Credit integrity depends on who sets the rules, who issues credits, and who profits — and on keeping those roles honest. Carrot is built to hold them apart. It is a **purpose-locked, non-profit steward**. It has no shareholders, and its fees do not function as a dividend that grows with issuance. The rules that decide what qualifies are **open-source and auditable**; verification is executed by deterministic software and reviewed by **independent validation and verification bodies (VVBs)**, not by Carrot itself; and every credit's record is public. Carrot is built as open infrastructure that established standards and registries can build on and interoperate with, earning credibility through demonstrated results and independent recognition rather than self-declaration. The aim is not to add another standard to a crowded field; it is to supply the layer the field has lacked — shared, open rails for identity, verification, recording, and settlement.
Proceeds from each credit sale are distributed to the participants recorded along the value-creation chain, in proportion to verified contribution, under the published [Rewards Distribution Policy](/docs/standard/policies/rewards-distribution). Distribution uses a traceable digital currency (USDC), chosen because it settles across borders at low cost, reaches participants directly, and leaves an end-to-end auditable trail from sale to recipient. What is not distributed to participants is organized into **purpose-bound pools**, so it is always visible what each unit of value is *for* — the network's economics are governed, not discretionary by default:
* **Treasury — the Foundation's operations.** Funds the Foundation's management, administration, legal, compliance, governance, and board. It is fed by published fees on work the Foundation performs — a **registry fee (1%, where Carrot is the registry of record)**, a **rewards-distribution / settlement fee (2.5%)**, and **dMRV / integrity charges (currently 16.5%, varying by scenario)**. Together these are the network's share — 20% where Carrot is the registry of record — so 100% of every credit sale funds the mission — at least 80% reaching the ecosystem directly, the remainder sustaining the public rails — a split reviewable in the Rewards Distribution Policy rather than asserted as a headline rate. Because the Treasury is funded by published fees on a non-profit steward — not a dividend that grows with issuance — funding the network never competes with protecting its integrity.
* **Community Pool — ecosystem growth.** Funds network onboarding, expansion, and use globally. It is fed by three of the network's incentive mechanisms: the discount applied while an important stakeholder — in recycling supply chains, the waste generator — is not yet identified, which drives full digitization to the source; the self-policing mechanism, which withholds rewards from bad actors; and unclaimed rewards. Value that would otherwise sit idle is recycled into growing the open network — and this pool is designed to move toward open governance so other ecosystem actors can help direct it.
* **Impact Pool — local development.** Where the waste generator is a large business, a portion of the rewards it would receive is directed here instead, funding socio-environmental and circular-economy projects **at the country level**. This keeps a participation incentive in place and a baseline flow of rewards to service providers across the ecosystem, while ensuring credit buyers are not financing rewards to large corporations — routing that value to local engagement and development.
Two of these pools turn the network's own integrity mechanics into fuel for the public good. The **source-tracing incentive** — a discount along the service-provider chain when the generator is not identified — makes full digitization to the source economically advantageous, and the value it frees flows to ecosystem growth rather than to any private party. The **self-policing mechanism** ties rewards to honest data: because rewards flow along each underlying unit's chain of custody, a record flagged for bad or fraudulent data is disqualified, withholding rewards from *everyone* on that chain — so if, for example, a hauler and a recycler submitted false data to inflate rewards, the waste generators behind them would stop being rewarded too — putting the continuation of the contracted service itself at risk. The same would occur in any project that does not meet its agreed milestones, ensuring that everyone in the chain collaborates and works toward the agreed goal. Honest data is the condition of being rewarded at all, and the withheld value funds the ecosystem. The Foundation can also suspend or remove bad actors.
Seen from the supply side, these same mechanics **de-risk participation.** A recycler, a cooperative, or a municipality deciding whether to invest in collection, sorting, or measurement faces a predictable rule set, not a discretionary one: rewards are tied to verified outcomes rather than to a volatile headline price set by an operator; the fee schedule is published in the Rewards Distribution Policy, and changes to it pass through governance rather than operator discretion; and value reaches every verified role in the chain through the same transaction, rather than concentrating with a single buyer or intermediary. Rewards distributed under predictable, published rules, against verified outcomes, are what let a small operator treat environmental work as investable rather than a gamble. That is the financing system named at the outset, seen from its supply side — and the precondition for the demand-side commitments described in *Shaping markets*, below.
## Working with the state — and what the foundation guarantees [#working-with-the-state--and-what-the-foundation-guarantees]
The DPI literature generally assumes a *state* stands behind the infrastructure, guaranteeing access and reward-sharing. The Carrot Network has no state behind it — so it has to be clear about what provides those guarantees, and about how it works alongside the public sector rather than against it.
Some things only a government can do: it can make participation compulsory across a whole market, it carries an electoral mandate, and it can act as a backstop of last resort. **The Carrot Foundation claims none of these,** because it is an *opt-in, additive* market layer, not a gatekeeper to any essential service. What a purpose-locked foundation *can* guarantee are exactly the things a voluntary market needs in order to be trusted — or that a regulator can choose to endorse or reject at any time:
* **No private capture, locked in.** The purpose is fixed in the Deed and cannot be redirected toward private gain by ordinary decision — only through the external supervisory process Swiss law prescribes for altering a foundation's purpose.
* **External accountability.** Federal supervision and audit sit above the Foundation's own management.
* **Continuity that does not depend on the steward.** Because the verification code is open source and the public credit registry and open methodologies are not locked inside Carrot, the rails can outlive the institution that stewards them today. If the Foundation failed or lost its way, the network's public assets would remain auditable — and could be taken up and continued by others.
Far from competing with government, the infrastructure is built to *lighten its load*. It can lower public costs — waste handling and enforcement, the public-health burden of unmanaged pollution, the remediation of contaminated land and water — freeing municipal budgets while supporting local productivity and green jobs. It also brings technology, financing, and verified data to bear at a system level, across jurisdictions, value chains, and borders — beyond the remit of any single government. In that sense it is a **facilitator** for the public sector and a **safeguard** for the market it underpins: it supplies the verification, traceability, and settlement that market needs to be trusted, while the state keeps its mandate, its regulatory authority, and its role as ultimate backstop. The result is a clear division of labor — **public purpose anchored in a purpose-locked foundation and open infrastructure; public authority retained and exercised by the state.**
## A new pathway: private capital, public destination [#a-new-pathway-private-capital-public-destination]
One question remains from the previous section: can infrastructure with no state behind it be counted on in the same way? Most DPI to date has been state-initiated — UPI under a central-bank mandate, X-Road by the Estonian state, MOSIP as a multilateral open-source collaboration. State leadership built the reference cases, and it brings strengths no foundation can replicate: scale, mandate, and democratic legitimacy. But it also carries risks the DPI experience has made familiar. Priorities and funding can shift with administrations and budget cycles, exposing infrastructure to political reversal or under-investment; commitments to openness can be hard to sustain across political transitions; a system funded as one line in a national budget competes with every other need that budget carries; and infrastructure bound to a single state does not easily serve people and markets beyond its borders.
None of this argues against public leadership — it argues that what makes infrastructure dependable is not who owns it, but whether its purpose, funding, and governance can hold steady across political time. The DPI literature reaches the same conclusion from the other direction: it does not require a state *origin* — only public *governance*. Co-Develop treats who builds DPI as an open design choice so long as public accountability holds; the UCL IIPP paper accepts privately-managed DPI provided access and reward-sharing are guaranteed. The lesson is that **operation can be non-governmental as long as something guarantees the public destination.**
The Carrot Network applies that pattern to a domain where cross-border coordination has been slow — environmental markets — using **private capital as the trigger** and a purpose-locked foundation as the guarantor of the **public destination**:
* **The trigger is private.** Solidos Brasil LTDA, the development company (the "Lab"), raised early capital under conventional instruments to develop the open rails, the methodology standard, and the dMRV pipeline.
* **The transfer is structural.** Under an intellectual-property assignment agreement signed on 22 December 2023, Solidos Brasil LTDA assigned the Carrot Network intellectual property — the code, the methodologies, the registries, and the associated domains and content — to the Carrot Foundation, which now holds it in stewardship under Swiss foundation law. Solidos Brasil was the first company to build the network's technology; it continues that work for the Foundation today alongside a growing set of independent builders — among them **EcoCircle**, **Eloverde**, and the **Mare Foundation** — as open infrastructure designed for many builders.
* **The destination is public.** Governed under Art. 80 ZGB, the Foundation is the purpose-bound steward of the rails.
The Swiss-foundation-as-steward form is well established for public-interest assets — it is the structure philanthropy has long used for mission-locked institutions, including the Geneva-based product-development partnerships built for global health — the **Medicines for Malaria Venture**, a Swiss foundation since 1999, and the **Drugs for Neglected Diseases initiative**, constituted like the Carrot Foundation under Article 80 *et seq.* of the Swiss Civil Code — assets stewarded for a mission rather than for owners. The Carrot Network applies that stewardship pattern to environmental markets — with the rails themselves released as digital public goods.
## The environmental extension [#the-environmental-extension]
Environmental markets need one design element that identity and payments infrastructure did not: a **crediting instrument** to internalize externalities.
Using identity or payments infrastructure has immediate value to the user, so adoption is self-motivating. Environmental work — reuse, recycling, composting, anaerobic digestion, super-pollutant reduction (e.g., methane, nitrous oxide, ground-level ozone, black carbon, and fluorinated gases), carbon dioxide removal, reforestation, water and nature restoration, renewable energy production, among others — is different: it produces value (the public good) for third parties (the city, the atmosphere, future generations), and the people doing the work are not automatically rewarded by those who benefit. Without a mechanism to channel buyers' and obligated parties' willingness-to-pay back to the people producing the outcome, the rails have no fuel.
Carrot's credits — the Recycling Credit and the Carbon Credit, recorded on a public, auditable registry — are that mechanism. Both are live today: credits have been issued, sold, and retired, and the proceeds distributed to the participants recorded along each underlying unit's chain of custody. They are, in effect, an **outcomes-based (results-based) financing instrument**: a buyer's payment is released against a verified environmental result, not a promise or an estimate, and the value it releases is distributed to the people who produced that result. This is the financing model the development-finance institutions have themselves formalized. The World Bank's *Carbon Crediting: A Results-Based Approach to Mobilizing Additional Climate Financing* (2025) frames crediting as results-based finance — funding released only once outcomes are achieved, measured, and independently certified — with its **SCALE** trust fund as the Bank's platform for results-based climate finance, and the IFC's *Unlocking Social and Environmental Impact: Outcome-Based Finance* (2025) makes the case for outcome-based instruments as the pathway for impact capital in emerging markets. Carrot's crediting mechanism applies that model on open public rails: **the network operates as a public registry for the circular economy — an open, digital MRV and crediting infrastructure** on which established standards, registries, and buyer coalitions can build. The credits are market instruments running *on top of* public-purpose rails, with rules and value flows visible and inspectable. The DPI pattern absorbs this extension cleanly: **the rail stays public; the credit is the market-forming layer that makes the rail economically viable for the people doing the environmental work.** A crucial point of integrity: recording a credit on a public registry confers durability and auditability — not integrity. Integrity comes from the methodology and the independent verification *upstream* of the registry. Carrot is the shared infrastructure that operators, methodology authors, accredited verifiers, and buyers all build on; it does not run environmental projects on the ground and is not the verifier. That separation is what lets the network serve as shared rails for every stakeholder — and, because all of them build on the same open infrastructure, what makes it scalable and interoperable.
## Shaping markets, not only recording them [#shaping-markets-not-only-recording-them]
Public rails and a credit instrument make a market *possible*. What makes it *work* is the ability to shape demand and de-risk supply so that capital moves before the outcome exists. This is where public infrastructure does more than record transactions — it can help *transform* a market, shaping it toward a directed outcome rather than merely clearing individual transactions.
That reframing has a rigorous grounding, and it turns on a distinction worth making plainly. The conventional view treats a market as a natural default that occasionally **fails** — through externalities like pollution, or missing public goods — leaving the public role to **correct** the failure and then step back. Mazzucato's *Governing the Economics of the Common Good: from correcting market failures to shaping collective goals* (2024) rejects that premise: markets are not givens to be patched but *"outcomes of governance structures"* — made, and therefore able to be **shaped**, by the actors who govern them. The task is not to *fix* a market after it fails, but to **form and shape** one, steering it toward a collectively-chosen direction.
For the environmental economy the distinction is decisive — it is the diagnosis this paper opened with. The hundreds of billions that should flow to verified environmental and social outcomes, and do not, mark a market to **form**, not a failure to correct. Nor will today's channels form it on their own: cross-border private climate finance travels overwhelmingly as project debt to utility-scale energy in a handful of large markets, **and it does not reach the distributed environmental work** — the small producers, cooperatives, and municipal chains — where circular-economy outcomes are actually made. Part of what keeps that work out of reach is the cost of entry: conventional crediting programs and registries carry upfront accreditation and registration fees that price out small and midsize operators — few composting facilities or recycling centers can afford accreditation with a registry, much less carry that cost with no assurance that credit sales will ever pay it back. As a digitally-native registry, Carrot sharply lowers that cost of participation — expanding access, and with it a pool of credit supply today's markets have yet to reach. Carrot is infrastructure for that formation: a rail governed for a fixed public purpose, built to give a market its direction rather than only to record what happens within one.
The mechanism that does this on the demand side is **coordinated advance demand** — buyer's clubs, demand coalitions and alliances (the pattern used for vaccines and now carbon dioxide removal), and, in its most formalized form, the Advance Market Commitment (AMC). It is also the coordination device the opening of this paper called for: a way for willing buyers to act together, at the level of a system, without waiting for unanimity. An AMC is a commitment, made *before* the supply exists, to purchase a defined volume of a **verified outcome** at a defined price. That forward commitment is what makes the supply financeable: it turns "we hope someone buys this" into "this volume is already sold," which is the demand certainty that lets a supplier — and its financiers — invest. The AMC enters to give a market that needs formation its first firm demand. The pattern has a track record:
* **Health.** The canonical case is the pneumococcal AMC: in 2009, five governments and the **Bill & Melinda Gates Foundation** committed **US$1.5 billion** through **Gavi, the Vaccine Alliance**, to guarantee demand for pneumococcal vaccines before manufacturers had built the supply. It worked — over a billion doses have since been supplied to lower-income countries, and the final tender drove the price to US$2 a dose. The same logic, at emergency speed, underpinned the **COVID-19 advance purchase agreements**, which committed roughly **US$18 billion** to vaccines that did not yet exist.
* **Carbon removal.** Frontier Climate — the buyer coalition built by Stripe — has used advance commitments (prepurchases plus pay-on-delivery offtake agreements) to pull early carbon removal off the lab bench. Its buyer commitment has grown to **US$1.8 billion** (June 2026), with roughly **US$694 million already contracted** to carbon-removal suppliers — and **71% of founders said it influenced their decision to start a carbon-removal company** (Ransohoff, *How to Start an Advance Market Commitment*, 2024). Ransohoff explicitly lists **greenhouse-gas removal, including methane and nitrous oxide,** among the next domains suited to an AMC.
* **At coalition scale.** The **Symbiosis Coalition** (Google, Meta, Microsoft, and Salesforce) has announced its intention to contract up to **20 million tonnes of nature-based carbon-removal credits by 2030** through a shared, quality-first process — a live example of buyers coordinating advance demand. Renaissance Philanthropy's *Commitments Playbook* (2024) describes how such coalitions are assembled: anchor commitments, a public call to action, and time-bound deadlines that convert pledges into coordinated demand.
An advance commitment, though, is only as credible as the verification and settlement behind it. To commit to buy "a verified outcome" before it exists, a buyer needs to trust that the outcome can be **independently verified**, **uniquely recorded** so it cannot be double-counted or double-sold, and **settled transparently**. Those are the three trust functions — identity, data exchange, settlement — that public digital infrastructure provides, and the digital public goods the Carrot Network releases: open methodologies, an open public registry, and open verification code. In development-finance terms, this is what makes an outcome **bankable**: when many buyers commit in advance to purchase future output, that certainty of demand lets capital treat small, dispersed environmental producers as investable — the market-building logic development-finance institutions already apply to blended finance (the International Finance Corporation has made this case in emerging-market circular-economy finance).
This is the pathway the infrastructure is built to enable: **digital public goods → verifiable, uniquely-recorded outcomes → outcomes that buyers can commit to in advance → de-risked, bankable investment → a market that pays for results.** The Carrot Network provides the public infrastructure on which such commitments can be coordinated, tracked, and scaled. It does not itself run a market commitment or act as buyer; it makes the pattern possible and credible for the coalitions, funders, and obligated parties who do. The rails are deliberately agnostic to why a buyer pays: whether demand comes from a voluntary coalition, an obligated party under regulation, or a public program paying for results, the verification, unique recording, and settlement are the same. No voluntary market closes a gap of the scale this paper opened with on its own; what it proves is the trust infrastructure every demand channel needs in order to reach the distributed work where outcomes are made. Used this way, the infrastructure supports a shift in climate and environmental finance **from promises to verified outcomes** — built on public rails.
## Carrot in the global DPI conversation [#carrot-in-the-global-dpi-conversation]
Environmental markets are now an explicit frontier for DPI — and Carrot is an operating contribution to it, not a claim on empty ground:
* The **ITS Rio / Ronaldo Lemos report *Digital Public Infrastructure for Climate*** (2025), prepared for the COP30 Presidency, frames "Climate DPI" as an operating system for climate action and proposes a modular "ClimateStack" whose layers explicitly include **carbon markets and the settlement of credits and climate finance** — the market-facing functions, not only data. The Carrot Network is an early-stage, operating implementation of that finance-and-registry function, focused first on waste and methane, and shows how those settlement and market layers can be built as public goods rather than as a proprietary exchange. With the right partners and capital, the same rails can serve nature and climate DPI more broadly — they are domain-agnostic by design.
* The **UNDP's "Nature ID"** work proposes DPI for nature and climate as an interoperability layer for environmental data, carbon-market traceability, and biodiversity credits — naming real-world anchors such as Brazil's Cadastro Ambiental Rural.
* The institutions defining DPI — **UCL IIPP**, the **Co-Develop Fund** (Rockefeller Foundation, Bill & Melinda Gates Foundation, Omidyar Network, Nilekani Philanthropies), the **UNDP**, and the **World Bank** — have concentrated on identity, payments, and data exchange. Carrot's contribution is to show that the same design pattern, the same governance standard, and the same market-shaping potential extend to environmental claims — from waste and methane today toward water, nature, and biodiversity. Carrot itself does not trade materials or run services on the ground; it makes the value of the verified public good tangible and channels it to the ecosystem that produced it.
## Building DPI responsibly: the risks we design against [#building-dpi-responsibly-the-risks-we-design-against]
DPI is not automatically benign, and a credible public-infrastructure project should say so in concrete terms. The UN's *Universal DPI Safeguards Framework* (UNDP and the UN Office for Digital and Emerging Technologies, 2024) and a substantial independent literature document real harms from real systems — exclusion, surveillance, and capture. The hardest lesson from large-scale deployments is precise: **when access to an essential service is gated behind a digital rail, failures of that rail fall hardest on the most vulnerable — and "voluntary" systems tend to drift toward de facto mandatory as essential value concentrates on the rail.** As a non-state builder, the Carrot Network is itself a subject of the Universal DPI Safeguards life cycle, and we accept that standard.
How the network is designed against each failure mode — stated honestly, including where a guardrail is still maturing:
* **Exclusion / the drift to de facto mandatory.** Carrot rewards people for environmental contributions at a system level; it does not stand between anyone and their food, identity, benefits, or livelihood, so the welfare-gating failure mode does not arise in the same form. The subtler risk is Carrot's own: as demand concentrates on the rail, a participant who is not registered could lose access to the *rewarded* market for their contribution. The network is an additive market layer: participation is opt-in, and participants can and do transact off-rail — private buyers and municipally-run channels exist, though they remain small, local, and hard to scale — and no buyer is required to source only through Carrot.
* **Surveillance and data risk.** A registry that records identified workers' contributions is itself a potential surveillance surface, so the scope of public transparency matters. Public-registry transparency is **scoped to credit records** — issuance, transfer, retirement — while operational and personal data is **permissioned to auditors and verifiers**, not open to all, and is handled under a data-minimization, encryption, and retention posture and applicable privacy law (LGPD/GDPR), as set out in the published [Privacy Policy](/docs/terms/privacy-policy).
* **Capture.** Carrot is **deliberately centralized today**, under a focused development team, to ensure foundational quality, a clear vision, and strong early leadership. This is a feature of the early phase, not the end state: participation expands to more stakeholders over time, and **guardrails are added as the network grows, aligned to the Foundation's stated purpose.** The structural protections that hold throughout are the purpose-lock (the mission cannot be unilaterally changed), external federal supervision, and open interfaces and open code so others can build on the rails — and, if necessary, carry them forward independently.
* **Registry integrity.** Recording a credit on a public registry confers durability and auditability — not integrity. Carbon and environmental markets have seen weak credits passed off as verified; Carrot enforces integrity upstream, in the **methodology and independent third-party verification**. For example, each unit of material (a MassID) can carry at most one carbon credit and one recycling credit, which prevents double-counting, and co-benefits are never priced into the carbon credit. Methodologies published on Carrot confront offset and greenwashing risk directly, and credit buyers who overstate their claims can be suspended.
We offer these as commitments we can be held to, through named mechanisms rather than assurances of good character — open code anyone can audit, a public registry anyone can inspect, federal foundation supervision, and a published [Rewards Distribution Policy](/docs/standard/policies/rewards-distribution) and [Terms & Conditions](/docs/terms/terms-and-conditions). Integrity in this domain has to be demonstrated through mechanism — compliance, traceability, transparency — not declared.
## Learn more [#learn-more]
The market this paper opened with is not waiting to be corrected; it is waiting to be formed — and no single company or government can form it alone. Forming it takes the three things named at the outset, and the Carrot Network is where they can exist together at scale: a financing system that directs capital to verified outcomes and distributes value to the people who produce them; a technology layer, built from digital public goods, that makes those outcomes trustworthy; and a purpose-locked steward, externally supervised, that holds the rails to their stated purpose. Each is inspectable today. The work of formation itself is shared by design — it belongs to the buyers, builders, funders, and public bodies these rails were built for. The notes that follow describe where each can begin.
**For philanthropic funders and catalytic investors** — The Carrot Foundation is structured to receive philanthropic and catalytic capital in support of the public-purpose rail: methodology development, the dMRV pipeline, and network governance. It can also fund the Foundation's own early-stage capacity — the administrative and development costs of standing up a public-purpose institution before the network's published fees can carry them. The same rails let a funder or buyer coalition direct outcomes-based advance commitments to verified environmental **and social** results — cleaner material streams and lower emissions, plus green jobs, inclusion, and local development — de-risking the producers who deliver them. Philanthropy, used this way, is **market-forming capital**: it moves before a market can pay for itself, and it leaves behind open rails that others build on. Funders who want to examine the rails, the Rewards Distribution Policy, or the public registry directly — or to explore what an anchor commitment could help form — are invited to start that conversation with the Foundation. For support, contact [fund.impact@carrot.eco](mailto:fund.impact@carrot.eco).
**For ecosystem participants and integrators** — The Carrot Network is open to the people and businesses who produce verified environmental outcomes — in today's circular-economy chains: waste generators, processors, and recyclers — and to the integrators who connect them to shared rails. Reward is tied to verified outcomes under a published, rules-based schedule that participants can plan and invest against. For onboarding support participants can contact [onboard@carrot.eco](mailto:onboard@carrot.eco); for accreditation of project developers and recyclers, [operations@carrot.eco](mailto:operations@carrot.eco); and for network{/* Approved source wording; generic usage, not the canonical role name. */} integrators, [integration@carrot.eco](mailto:integration@carrot.eco).
**For buyers and demand coalitions** — A credit on the network is an outcomes-based instrument: payment is released against an independently verified result, uniquely recorded so it cannot be double-counted or double-sold, and settled transparently — visible from purchase to the people who produced the outcome. The same rails let coalitions coordinate advance commitments to outcomes that do not yet exist, with the verification and settlement already in place. For support, contact [registry@carrot.eco](mailto:registry@carrot.eco).
**For governments and public agencies** — The infrastructure is built to lighten the public sector's load, not replace it: lower waste-handling and enforcement costs, reduced public-health and remediation burdens, freed municipal budgets, and support for local green jobs and productivity — with the verified data, traceability, and settlement a market needs, while the state keeps its mandate, regulatory authority, and backstop role. It can also enable new market-based policy: under **extended producer responsibility (EPR)**, for example, producers can meet obligations by funding verified waste-reduction outcomes directly — compliance demonstrated through results rather than through documentation alone. For support, contact [gov.support@carrot.eco](mailto:gov.support@carrot.eco).
**For researchers and policy actors** — Methodology frameworks, verification code, and the public credit registry are publicly inspectable digital public goods. For research and methodology development, contact [science@carrot.eco](mailto:science@carrot.eco).
**For general questions** — [contact@carrot.eco](mailto:contact@carrot.eco).
**Related pages:** [The Carrot Foundation](/docs/network/the-foundation) · [Governance](/docs/network/governance) · [The Network](/docs/network) · [Rewards Distribution Policy](/docs/standard/policies/rewards-distribution) · [Terms & Conditions](/docs/terms/terms-and-conditions)
**Cite as:** McKee, I., & Doria, M. (2026). *Digital Public Infrastructure for Global Climate Finance — Case: Low-carbon circular economy.* Carrot Foundation White Paper v1.6.
## External resources [#external-resources]
* Mazzucato, M., Eaves, D. & Vasconcellos, B. (2024). *Digital Public Infrastructure and Public Value: What is "public" about DPI?* UCL IIPP WP 2024-05. Peer-reviewed: *Journal of Economic Policy Reform* 29(2):113–141 (2026), open access.
* Mazzucato, M. (2024). *Governing the Economics of the Common Good: from correcting market failures to shaping collective goals.* *Journal of Economic Policy Reform* 27(1):1–24, open access. [https://doi.org/10.1080/17487870.2023.2280969](https://doi.org/10.1080/17487870.2023.2280969)
* Eaves, D. & Sandman, J. (2023). *What is Digital Public Infrastructure?* Co-Develop.
* World Bank / ID4D (2022). *A Digital Stack for Transforming Service Delivery: ID, Payments, and Data Sharing.*
* Ransohoff, N. (2024). *How to Start an Advance Market Commitment.* Works in Progress / Frontier.
* Renaissance Philanthropy (2024). *Commitments Playbook.*
* Symbiosis Coalition (2024). *Introducing Symbiosis.*
* International Finance Corporation (IFC) (2025). *Unlocking Social and Environmental Impact: Outcome-Based Finance in Clean Cooking, Distributed Renewable Energy, and Small-Scale Agribusiness.* See also IFC work on blended finance as a market-building instrument for emerging-market circular-economy finance.
* World Bank (2025). *Carbon Crediting: A Results-Based Approach to Mobilizing Additional Climate Financing.* See also SCALE — Scaling Climate Action by Lowering Emissions, the World Bank's umbrella trust fund for results-based climate finance.
* WBCSD — *Global Circularity Protocol.*
* IHLEG — Independent High-Level Expert Group on Climate Finance (2025). *Delivering an integrated climate finance agenda in support of the Baku to Belém Roadmap to 1.3T.* LSE Grantham Research Institute, November 2025.
* Climate Policy Initiative (2025). *Global Landscape of Climate Finance 2025.*
* UNEP (2025). *Global Methane Status Report 2025.*
* Circle Economy — *Circularity Gap Report 2021* (and annual editions).
* ITS Rio & Lemos, R. (2025). *Digital Public Infrastructure for Climate.* COP30 Presidency.
* UNDP — *Digital Public Infrastructure* and *The Case for Nature ID.*
* *Universal DPI Safeguards Framework* (UNDP / UN ODET, 2024) — dpi-safeguards.org.
# Attachments
Attachments use a presigned URL model. Integrators first request a temporary URL from Carrot API, then
upload or download file data directly with the returned URL.
## Create upload URL [#create-upload-url]
Use `PUT /documents/{documentId}/attachments/{fileName}` to request an upload URL.
Send:
* `contentLength` (bytes)
* `contentType` (MIME type)
After receiving the URL:
1. Send `PUT` to the presigned URL with the file in binary format.
2. Include the same `Content-Type` declared in the URL request.
3. Send `Content-Length` equal to the `contentLength` you declared. `Content-Length` is part of the
signature — the URL carries `X-Amz-SignedHeaders=content-length;host` — so a mismatched length
fails with a signature error. `Content-Type` is not signed, so a mismatch there fails differently
or not at all; send it correctly anyway.
4. No `Authorization` header is required for the presigned upload call.
## Get download URL [#get-download-url]
Use `GET /documents/{documentId}/attachments/{fileName}` to request a temporary download URL.
Then perform a standard `GET` on the returned URL to fetch the file.
## Limits and behavior [#limits-and-behavior]
* Maximum file size per upload: 10 MB.
* Upload URLs are valid for 7 days; download URLs for 2 minutes — request a download URL immediately
before fetching the file.
* After uploading, you must reference the file name in an event's `attachments` array. A file that no
event references cannot be downloaded.
* File names are unique per document: once a file has been uploaded under a given name, requesting a
new upload URL for that same name on the same document is rejected with
`Attachment already exists` rather than overwriting. The rejection happens on the
create-upload-URL call, so requesting a URL for a name whose bytes were never uploaded still
succeeds.
See [File Uploads](/docs/integrations/guides/file-uploads) for practical integration patterns.
# Authentication
Carrot API uses OAuth 2.0 client credentials with bearer tokens.
There is no user login step. Integrations authenticate with a `clientId` and `clientSecret`.
## Authentication flow [#authentication-flow]
1. Receive `clientId` and `clientSecret` from the Carrot API team.
2. Request an access token from the auth endpoint using Basic Authentication.
3. Use the returned bearer token in the `Authorization` header on API requests.
```bash
curl --request POST \
--url https://auth.api.carrot.eco/oauth2/token \
--header 'Authorization: Basic ' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'scope=api.carrot.eco/main-scope'
```
## Token lifecycle [#token-lifecycle]
* `access_token` maximum duration is currently 1 hour.
* `expires_in` is returned by the token endpoint response and must be treated as API-provided runtime data (not hard-coded in your integration).
* Refresh tokens are not used in this flow.
* Request a new token before expiry to avoid request failures.
## Token response format [#token-response-format]
Typical successful response:
```json
{
"access_token": "",
"token_type": "Bearer",
"expires_in": 3600,
"scope": "api.carrot.eco/main-scope"
}
```
## Applying bearer tokens [#applying-bearer-tokens]
Send your token on each request:
```http
Authorization: Bearer
```
## Environment behavior [#environment-behavior]
Environment is controlled by credentials, not by URL.
* Test credentials operate only on test data.
* Production credentials operate only on production data.
* A test token cannot modify production documents, and the reverse is also true.
See [Environments](/docs/integrations/getting-started/environments) for operational guidance.
## Common auth errors [#common-auth-errors]
* **`401`** — the token could not be parsed: no `Authorization` header, or a bearer value that is not
a decodable JWT. The body is `{"message":"Unauthorized"}`, with no `code` field.
* **`403` (edge authorizer)** — the token parsed but was rejected: expired, invalid signature,
non-`Bearer` scheme, scope not allowed, or issuer mismatch. The body is `{"message":""}`,
for example `{"message":"Authorization token expired"}`. There is no `errors[]` envelope.
* **`403` (`RESTRICTED_RESOURCE_ERROR`)** — a valid token without permission for the target resource,
including a test credential touching production data or the reverse. The body is the standard
`errors[]` envelope described in [Errors](/docs/integrations/api/errors).
An expired token never produces a `401` — it is rejected at the edge as a `403`, so token-refresh
logic keyed on `401` will never fire. Refresh only when the gateway body identifies expiry
(`{"message":"Authorization token expired"}`). The other `403` causes — bad signature, wrong scope
or issuer, `RESTRICTED_RESOURCE_ERROR` — are not fixed by a new token, and retrying them after a
refresh only loops.
***
[Environments](/docs/integrations/getting-started/environments) · [Quick Start](/docs/integrations/getting-started/quick-start) · [Error Handling](/docs/integrations/guides/error-handling)
# Documents
Documents are the core resource in Carrot API. A document (commonly a [MassID](/docs/protocol/mass-ids)) becomes the immutable
container for traceability data, and all changes happen through appended events.
## Create document [#create-document]
Use `POST /documents` to create a document with required baseline fields:
* `category`
* `externalCreatedAt`
* `isPublic`
* `isPubliclySearchable`
* `type`
* exactly one of `participantId` — a participant resolved via the
[Participants API](/docs/integrations/api/participants) — or an inline `participant` object
* exactly one of `addressId` — an address resolved via the
[Participants API](/docs/integrations/api/participants) — or an inline `address` object
Sending both `participantId` and `participant`, or neither, fails validation with
`400 VALIDATION_ERROR`. The same rule applies to `addressId` and `address`.
Prefer resolving participants and addresses first and referencing them by ID. The inline form is
still supported and find-or-creates the record, which is the only way to create a document together
with a new participant or address in a single call.
Optional fields:
* `deduplicationId` — a create-once key. A repeated value is rejected with `409 CONFLICT_ERROR`
(`Document deduplicationId: (…) already exists`), never replayed; see
[Error Handling](/docs/integrations/guides/error-handling) for how to treat that conflict.
* `tags`, `title`, `shortTitle`, and classification fields.
## Retrieve document by id [#retrieve-document-by-id]
Use `GET /documents/{id}` to fetch the full document payload, including:
* current status and value
* participant and address references
* complete event timeline
* public visibility flags
## Design note: immutability [#design-note-immutability]
Document data is append-only in practice. There is no `PATCH`/`PUT` endpoint for document mutation and
no `DELETE` endpoint. Operational changes are represented as events.
For a production-oriented workflow, see
[Submitting a MassID](/docs/integrations/guides/submitting-a-mass-id).
# Errors
This page summarizes standard error formats and common failure modes for Carrot API integrations.
## Error response format [#error-response-format]
Typical error payload:
```json
{
"statusCode": 400,
"errors": [
{
"code": "BAD_REQUEST_ERROR",
"message": "Invalid type on $input.name, expected to be (string)",
"id": "3f6b0f2c-6d5f-4a3a-9f9a-1c2d3e4f5a6b",
"timestamp": 1684766595000
}
]
}
```
* `code` is a SCREAMING\_SNAKE enum member — see the table below.
* `id` is a random 36-character identifier in `8-4-4-4-12` hexadecimal form.
* `timestamp` is epoch **milliseconds**, sent as a JSON number, not a string.
* `errors` currently always contains exactly one entry.
## Error codes [#error-codes]
| HTTP | Code | Meaning |
| ---- | -------------------------------- | -------------------------------------------------------------------------------- |
| 400 | `BAD_REQUEST_ERROR` | Request payload failed schema validation. |
| 400 | `VALIDATION_ERROR` | Payload is well-formed but breaks a business rule. |
| 401 | *(gateway)* | No `Authorization` header, or a bearer value that is not a decodable JWT. |
| 403 | *(gateway)* | Token parsed but rejected: expired, bad signature, wrong scope or issuer. |
| 403 | `RESTRICTED_RESOURCE_ERROR` | Valid token without permission for this resource or environment. |
| 404 | `NOT_FOUND_ERROR` | Resource does not exist or is not shared with token owner. |
| 405 | `METHOD_NOT_ALLOWED_ERROR` | HTTP method not supported on this path. |
| 409 | `CONFLICT_ERROR` | Operation conflicts with existing data — including a replayed `deduplicationId`. |
| 409 | `PENDING_PROCESS_CONFLICT_ERROR` | Requested document is still processing. Retry later. |
| 429 | *(gateway)* | Request rate exceeded the client's allowed threshold. |
| 500 | `INTERNAL_SERVER_ERROR` | Unexpected server-side failure. |
| 503 | `SERVICE_UNAVAILABLE_ERROR` | Service temporarily unavailable or request exceeded processing window. |
| 504 | `GATEWAY_TIMEOUT_ERROR` | Upstream timeout/session expiration while completing request. |
Rows marked *(gateway)* are produced by the API edge, not by the service. They carry a plain
`{"message": "..."}` body — no `errors[]` envelope and no `code` field — so disambiguate a `403` by
the shape of its body, not by its status alone.
For rate limits and quotas, see
[Rate Limits](/docs/integrations/reference/rate-limits).
For error recovery patterns and retry strategies, see
[Error Handling](/docs/integrations/guides/error-handling).
# Events
Events are the primary mechanism for evolving document state. After a document is created, all relevant
changes are recorded as new events.
## Create event [#create-event]
Use `POST /documents/{documentId}/events` to append one event to a document timeline. Prefer
referencing the event's participant and address by `participantId`/`addressId`; the inline
`participant`/`address` form is still supported and find-or-creates the record. See
[Participants](/docs/integrations/api/participants).
## Batch events [#batch-events]
Use `POST /documents/events` to create multiple events for a document in a single request. The body
takes exactly one of:
* `documentId` — append the events to an existing document; or
* `document` — a full document payload, creating the document and its events in the same request.
Supplying both or neither returns `400` (`Exactly one of documentId or document must be provided`).
Each event in the batch follows the same schema as the single-event endpoint above, with one extra
check the single-event endpoint does not have: participant and address identities are checked for
conflicts across the events in the batch, so the same identity carrying different data fails.
The identity rule itself is the same on both endpoints — every event must carry exactly one of
`participantId`/`participant` and exactly one of `addressId`/`address`. The single-event endpoint
delegates to this one after running that check itself.
## Logical event types [#logical-event-types]
| Type | Purpose |
| --------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| `ACTOR` | Adds a participant role on the document and can update permissions. |
| `CLOSE` | Closes the document for future updates (except specific relation workflows). |
| `CANCEL` | Cancels the document and blocks future actions. Requires a `reason` metadata attribute — see below. |
| `RELATED` | Links this document to another document. |
| `UPDATE` | Updates specific document visibility fields. |
| `OUTPUT` | Conventional name for an event that creates a downstream document. No dedicated schema — the `target` payload creates the document. |
| `CUSTOM` | Methodology-specific event names not covered by built-in types. |
The current schema defines six discriminated event schemas (`CloseEvent`, `ActorEvent`, `CancelEvent`,
`RelatedEvent`, `UpdateEvent`, `CustomEvent`). Any event name the API does not reserve is handled as a
`CUSTOM` event, `OUTPUT` included.
Creating a downstream document is triggered by the presence of the `target` object on **any** event,
not by the event name. Both endpoints report the created document as `targetDocumentId` — on the
event's entry in the batch response, and alongside `documentId` and `eventId` in the single-event
response. Note that the single-event response schema does not declare it, so a generated client may
drop it; read it from the raw body if you need it.
`CANCEL` events require `metadata.attributes` to include an entry named `reason` with a non-empty
value; omitting it returns `400` (`The reason metadata is required for CANCEL events`). The name is
lowercase `reason` — the one exception to the Title Case convention for metadata attribute names, and
the validator matches it exactly, so `Reason` is not recognised.
## Ordering and consistency [#ordering-and-consistency]
* `externalCreatedAt` must be before current time.
* `externalCreatedAt` must be equal to or later than the last recorded event.
* Use `deduplicationId` when retrying event submissions. A repeated value on the same document is
rejected with `409 CONFLICT_ERROR`, never replayed — see
[Error Handling](/docs/integrations/guides/error-handling).
## Related documents [#related-documents]
A `RELATED` event's `relatedDocument.bidirectional` defaults to `true`, which writes the mirrored
event on the related document. When `bidirectional` is `true`, `isPublic` is required on the related
document. When it is `false` there is no mirrored event to describe, so `eventName`, `eventLabel`, and
`preserveSensitiveData` are all rejected.
For complete event definitions and methodology alignment, see
[Event Specification](/docs/integrations/reference/event-specification).
# API Overview
The Carrot API is a document-centric API used by [Network Integrators](/docs/protocol/network-integrators) to submit and retrieve traceability data.
The public surface is intentionally small: 11 endpoints across 5 resources (`documents`, `events`, `attachments`, `participants`, `addresses`).
## Base URL [#base-url]
* API: `https://api.carrot.eco`
* Auth: `https://auth.api.carrot.eco/oauth2/token`
* Registry: `https://registry.carrot.eco`
## Core conventions [#core-conventions]
* Content type is JSON for API requests and responses.
* Date-time values follow ISO 8601 (for example, `2020-01-01T00:00:00.000Z`).
* Metadata fields are flexible key-value structures.
* Document history is append-only through events.
## Environments [#environments]
Carrot uses the same base URL for test and production traffic. Environment selection is based on the
`clientId` used to request an access token.
* Test credentials can only operate on test documents.
* Production credentials can only operate on production documents.
* Cross-environment document relations are not allowed.
## Resource map [#resource-map]
* [Authentication](/docs/integrations/api/authentication): OAuth 2.0 client credentials flow and token lifecycle.
* [Documents](/docs/integrations/api/documents): create and retrieve documents.
* [Events](/docs/integrations/api/events): append immutable events to document timelines, individually or in batch.
* [Attachments](/docs/integrations/api/attachments): generate presigned upload/download URLs.
* [Participants](/docs/integrations/api/participants): register participants and their addresses.
* [Errors](/docs/integrations/api/errors): error codes, rate limits, and troubleshooting.
## Integration quick start [#integration-quick-start]
For an end-to-end onboarding sequence, use
[Integrations Quick Start](/docs/integrations/getting-started/quick-start).
# Participants
Participants are the organizations and people that own [documents](/docs/integrations/api/documents) and
appear in events. Register them here to obtain the `participantId` and `addressId` values referenced when
creating a document.
All read operations are scoped to the caller's credential: records your credential created return every
field, while records belonging to other participants return only identification and location fields, with
the street masked.
## Participants [#participants]
### Create participant [#create-participant]
Use `POST /participants` to register a participant in your credential's dataset. The response returns
the generated `id` — pass it as `participantId` when creating documents and events.
### Get participant by key [#get-participant-by-key]
Use `GET /participants` to look up a participant by its natural key — country code, document type, and
document number. The document number (`taxId`) is passed in the query string.
### Get participant by id [#get-participant-by-id]
Use `GET /participants/{id}` to fetch a participant by its Carrot identifier.
## Addresses [#addresses]
Addresses belong to a participant, so every address operation is scoped to a `participantId`.
### Create address [#create-address]
Use `POST /participants/{participantId}/addresses` to add an address to a participant. The response
returns the generated `id`, which is referenced as `addressId` when creating a document.
### List participant addresses [#list-participant-addresses]
Use `GET /participants/{participantId}/addresses` to list a participant's addresses. Addresses your
credential did not create are returned with identification and location fields only and the street masked.
For the end-to-end onboarding sequence, see
[Integrations Quick Start](/docs/integrations/getting-started/quick-start).
# Connect Your AI Agent
The Carrot Docs [Model Context Protocol (MCP)](https://modelcontextprotocol.io/) server gives your AI agent read-only access to the published Carrot documentation. It is public, unauthenticated, and docs-only. It can search and read published docs and glossary terms, but it cannot call the [Carrot API](/docs/integrations/api), write data, access private project data, or act on your behalf.
AI clients do not automatically install this server when a user mentions `docs.carrot.eco`. Add the server in your client first, then ask the agent to use Carrot Docs MCP when answering from the documentation. If MCP is not available, use [/llms.txt](/llms.txt) or [/llms-full.txt](/llms-full.txt) as machine-readable fallbacks.
## Endpoint [#endpoint]
| Field | Value |
| -------------- | --------------------------------- |
| URL | `https://docs.carrot.eco/mcp` |
| Transport | Streamable HTTP |
| Authentication | None |
| Method | `POST` |
| Content | Published docs and glossary terms |
| Locales | `en`, `pt-BR` |
## Claude [#claude]
Use Claude.ai or Claude Desktop to add Carrot Docs as a remote MCP connector, then connect Claude Code with the same server URL.
This is a remote Streamable HTTP MCP server. Do not configure it as a local stdio server through `claude_desktop_config.json`.
### Claude.ai and Claude Desktop [#claudeai-and-claude-desktop]
1. Open `Customize > Connectors`.
2. Select `Add custom connector`.
3. Set the connector name to `Carrot Docs`.
4. Set the server URL to `https://docs.carrot.eco/mcp`.
5. Enable the connector in conversations.
6. Save the connector and reload Claude if needed.
### Claude Code [#claude-code]
Use these commands to add and verify the server:
```bash
claude mcp add --transport http carrotDocs https://docs.carrot.eco/mcp
claude mcp list
```
## Cursor [#cursor]
Add the server manually in Cursor with an `mcp.json` file.
```json
{
"mcpServers": {
"carrotDocs": {
"url": "https://docs.carrot.eco/mcp"
}
}
}
```
Restart Cursor after saving the file so the new server appears in the MCP list.
## Codex [#codex]
Use the Codex MCP commands to add the server and confirm that it is registered.
```bash
codex mcp add carrotDocs --url https://docs.carrot.eco/mcp
codex mcp list
```
If you prefer to configure Codex directly, add the same server to `~/.codex/config.toml`:
```toml
[mcp_servers.carrotDocs]
url = "https://docs.carrot.eco/mcp"
```
## Generic Streamable HTTP client [#generic-streamable-http-client]
Any MCP client that supports Streamable HTTP can connect to the Carrot Docs server.
```bash
curl --request POST \
--url https://docs.carrot.eco/mcp \
--header 'Content-Type: application/json' \
--header 'Accept: application/json, text/event-stream' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "",
"capabilities": {},
"clientInfo": {
"name": "example-client",
"version": "0.1.0"
}
}
}'
```
After negotiation, the server returns:
```text
MCP-Protocol-Version:
```
The endpoint also responds to a plain GET request with `405 Method Not Allowed`:
```bash
curl --request GET https://docs.carrot.eco/mcp
```
Example client configuration:
```json
{
"name": "carrotDocs",
"transport": "streamable-http",
"url": "https://docs.carrot.eco/mcp"
}
```
Carrot does not require you to pin a protocol version. Let your client advertise `` and allow the handshake to settle on ``.
## Tool summary [#tool-summary]
The server exposes five read-only tools:
| Tool | Purpose |
| ------------------- | ------------------------------------------------------- |
| `search_docs` | Search published docs by keyword, topic, or concept. |
| `get_doc` | Read the full contents of a single doc page. |
| `get_glossary_term` | Fetch a glossary definition and related context. |
| `browse_docs` | Explore docs by section and navigate the content tree. |
| `get_related_docs` | Surface nearby docs, references, and follow-up reading. |
Notes:
* Search-style results are capped at 25 items.
* The default service limits are 60 requests per minute and 10 concurrent requests per client IP.
* Responses are returned as structured success or error envelopes inside MCP text content.
## Agent instruction [#agent-instruction]
Use the Carrot Docs MCP server when answering questions about Carrot documentation, including [Carrot Network](/docs/network) concepts, glossary terms, [environmental credits](/docs/protocol/credits), [methodology frameworks](/docs/standard/concepts/mvf), buyer guidance, [Network Integrator](/docs/protocol/network-integrators) onboarding, and the documentation for the Carrot API.
## Example prompts [#example-prompts]
* Explain how MassIDs support traceability in the Carrot Network.
* Summarize how traceable environmental credits are created.
* Find the Carrot API authentication flow.
* Show the privacy and masking guidance for integration payloads.
* Find docs related to governance and the Carrot Foundation.
* Look up the current BOLD Recycling methodology guidance.
## Troubleshooting [#troubleshooting]
* If your client does not support remote Streamable HTTP MCP servers, it cannot connect to Carrot Docs.
* If the connector or tool toggle is off in the current chat, enable it before asking the agent to use the server.
* If you change a manual config file, restart or reload the client before testing again.
* If tool selection is not automatic, explicitly ask the agent to use the Carrot Docs MCP server.
* If you see `429` responses, wait and retry after the rate limit window clears.
* If search returns nothing, try the exact published term name from the docs or glossary.
* If a topic should exist but is not found, use `browse_docs` first and then `get_related_docs` to expand the path.
* If you need private data or write access, this server cannot provide it. Use the Carrot API instead.
# Core Concepts
These concepts form the foundation of the [Carrot API](/docs/integrations/api) integration model. Understand them
before writing your first API calls.
## What is a document? [#what-is-a-document]
A document is the root data structure for a traceability record. It registers and represents the full
history of a logistics process or flow for a mass — from origin to final destination — in a transparent
and auditable way. Each document receives a unique identifier and is classified by
[category, type, and subtype](/docs/integrations/reference/waste-classification).
Documents can be related to other documents through events, allowing the platform to build an
integrated view of connected processes. For example, a
[MassID](/docs/protocol/mass-ids) tracking a waste batch through the
[supply chain](/docs/protocol/supply-chain) is a document that stores identity and classification
fields, while all state changes are represented by appended events on its timeline.
Reference: [Documents API](/docs/integrations/api/documents).
## What story does a MassID need to tell? [#what-story-does-a-massid-need-to-tell]
Every MassID should tell a complete story — with a clear beginning, middle, and end. When you submit
data to the Carrot API, ensure that the record is cohesive, traceable, and detailed enough to
understand the origin of the mass, its journey, and its final destination.
A well-documented MassID includes information such as:
* **Point of origin** — where the waste was generated or collected
* **Logistics steps** — collection, weighing (gross and net weight), vehicle identification
* **Transshipment points** — intermediate transfers or staging areas
* **Participants involved** — every actor in the chain of custody
* **Final destination** — the recycling or [biological treatment](/docs/glossary#biological-treatment) facility
Each piece of information strengthens traceability and data integrity. Carrot's digital MRV ([dMRV](/docs/protocol/dmrv)) system
receives and verifies this data to maintain chain of custody. Third-party auditors independently
accredit recycling facilities to ensure compliance with network standards.
See [Submitting a MassID](/docs/integrations/guides/submitting-a-mass-id) for the step-by-step
implementation flow.
## Immutability by events [#immutability-by-events]
There is no update or delete endpoint. Instead, you add
events to represent operational changes over time. The platform uses an **event-sourced** model: each
submission is appended to the document timeline, and current state is derived from the event log.
This immutability is fundamental for the environmental credit market. Once data is recorded and
credits are issued and traded, buyers need assurance that the underlying records are permanent and
cannot be altered after the fact. Immutable data strengthens the credibility of the system for
buyers, regulators, and auditors.
If you need to correct an error, do not attempt to edit the document. Instead, cancel it using a
`CANCEL` event and create a new document with the corrected data, preserving the full traceability
flow.
Reference: [Events API](/docs/integrations/api/events) · [Error Handling](/docs/integrations/guides/error-handling).
## Events and metadata [#events-and-metadata]
Events represent concrete operational actions performed on a document — for example, waste
collection, weighing, transport, or drop-off at a recycling facility. Together, the events form the
document's **timeline**: a chronologically ordered record of everything that happened to the mass.
Each event can carry **metadata** (also called **attributes**) — key-value pairs that provide
additional context about what happened. Examples include date, location, vehicle license plate,
operator identifier, or weight measurement. Metadata enriches the timeline and makes the
traceability record more robust for audits and verification.
Some metadata fields are required by specific [methodology rules](/docs/protocol/methodology-execution), while others are
recommended as best practices. Missing attributes may cause methodology rules to reject the submission.
Reference: [Event Specification](/docs/integrations/reference/event-specification) ·
[Data Formats](/docs/integrations/reference/data-formats).
## Event ordering [#event-ordering]
Event chronology matters. `externalCreatedAt` must be valid relative to existing timeline entries, so your
integration should preserve source-system order and retries. The platform does not allow future-dated
events — timestamps must reflect when the action occurred in the source system.
## Visibility and privacy [#visibility-and-privacy]
Public visibility (`isPublic`) and searchable visibility (`isPubliclySearchable`) are part of the base
model and can be adjusted through event flows.
Guide: [Privacy & Masking](/docs/integrations/guides/privacy-and-masking).
## Idempotency and resilience [#idempotency-and-resilience]
Use `deduplicationId` for create/event retries and treat transient errors differently from validation
errors.
Guide: [Error Handling](/docs/integrations/guides/error-handling).
# Environments
The [Carrot API](/docs/integrations/api) uses credential-based environment separation with the same base URL.
## Environment model [#environment-model]
* API base URL: `https://api.carrot.eco`
* Auth URL: `https://auth.api.carrot.eco/oauth2/token`
* Environment is selected by the credential pair (`clientId` / `clientSecret`), not by host.
## Test vs production behavior [#test-vs-production-behavior]
* Test credentials can only operate on test data.
* Production credentials can only operate on production data.
* Cross-environment relationships are not allowed.
## Credential lifecycle recommendations [#credential-lifecycle-recommendations]
* Store credentials in your secrets manager.
* Rotate credentials through controlled rollout.
* Request new bearer tokens before expiry.
## Go-live checklist [#go-live-checklist]
1. Validate full flow in test (create, event append, attachment upload, retrieval).
2. Confirm retry/idempotency behavior with [`deduplicationId`](/docs/integrations/guides/error-handling).
3. Confirm rate limit behavior under expected throughput.
4. Promote to production credentials.
Related references:
* [Authentication](/docs/integrations/api/authentication)
* [Rate Limits](/docs/integrations/reference/rate-limits)
# Quick Start
> **New here?** Start by exploring a complete reference MassID in
> [Carrot Registry](https://registry.carrot.eco/document/0659ba41-e391-4d03-b5ba-537a9129326c) —
> then come back to walk through how to build one.
This guide walks through the base [Carrot API](/docs/integrations/api) flow — from authentication to document
retrieval — so you can verify your integration end to end.
## Integrator learning path [#integrator-learning-path]
## 1) Request an access token [#1-request-an-access-token]
Use OAuth 2.0 client credentials:
```bash
curl --request POST \
--url https://auth.api.carrot.eco/oauth2/token \
--header 'Authorization: Basic ' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'scope=api.carrot.eco/main-scope'
```
Endpoint details: [Authentication](/docs/integrations/api/authentication).
## 2) Resolve participants and addresses [#2-resolve-participants-and-addresses]
Documents and events reference a participant and an address **by ID**. Retrieve them by key, or create them, before creating the document:
```http
GET /participants?countryCode=BR&taxIdType=CNPJ&taxId=11111111111111
GET /participants/{participantId}/addresses
POST /participants
POST /participants/{participantId}/addresses
Authorization: Bearer
```
Endpoint details: [Participants](/docs/integrations/api/participants).
## 3) Create a document [#3-create-a-document]
Create the base traceability record, referencing the `participantId` and `addressId` from the previous step:
```http
POST /documents
Authorization: Bearer
```
Inline `participant`/`address` objects are still supported and find-or-create the record — prefer passing `participantId`/`addressId`, and send exactly one form of each.
Endpoint details: [Documents](/docs/integrations/api/documents).
## 4) Append an event [#4-append-an-event]
Add one timeline event to represent a business action:
```http
POST /documents/{documentId}/events
Authorization: Bearer
```
Endpoint details: [Events](/docs/integrations/api/events).
For batch operations, use `POST /documents/events` to submit multiple events in a single request. See [Events — Batch events](/docs/integrations/api/events#batch-events).
## 5) Retrieve and validate state [#5-retrieve-and-validate-state]
Fetch the full document and verify timeline consistency:
```http
GET /documents/{id}
Authorization: Bearer
```
Endpoint details: [Documents](/docs/integrations/api/documents).
## 6) Add production safeguards [#6-add-production-safeguards]
* Use `deduplicationId` on retryable create/event requests.
* Enforce event timestamp ordering.
* Add client-side rate limiting and retry/backoff.
Continue with:
* [Core Concepts](/docs/integrations/getting-started/core-concepts) — the document model and event-sourced architecture.
* [Environments](/docs/integrations/getting-started/environments) — test vs. production credentials and go-live checklist.
* [Submitting a MassID](/docs/integrations/guides/submitting-a-mass-id) — complete lifecycle walkthrough.
### Diagram: integrator-roadmap
This integrator roadmap arranges the integration path from exploring a MassID to Quick Start, Core Concepts, submitting a MassID, methodology-specific BOLD Recycling and BOLD Carbon integration paths, event references, privacy masking, and go-live environments. The split and merge show that integrators learn the shared flow first, branch by methodology, then converge before launch.
# Error Handling
This guide covers operational recovery patterns for integrating with the [Carrot API](/docs/integrations/api).
For endpoint error codes and payload format, see [API Errors](/docs/integrations/api/errors).
## Classify failures first [#classify-failures-first]
* `4xx`: request/data/integration issues. Fix payload or flow.
* `5xx`: transient platform or upstream issues. Retry with backoff.
## Retry decision table [#retry-decision-table]
| Status Code | Error | Action |
| --------------------- | ---------------------------------- | ------------------------------------------------------------------- |
| `400` | Validation error | **Abort** — fix the payload and resubmit |
| `403` | Token expired (gateway body) | **Refresh** the token and retry once |
| `401` / `403` | Other authentication/authorization | **Abort** — check credentials or permissions |
| `404` | Resource not found | **Abort** — verify IDs in the request path |
| `409` | `PENDING_PROCESS_CONFLICT_ERROR` | **Retry** after 2-5 seconds — a background process is in progress |
| `409` | Duplicate `deduplicationId` | **Stop** — your earlier attempt succeeded; do not retry or resubmit |
| `409` | Other conflict errors | **Abort** — fix the data conflict, do not retry as-is |
| `422` | Unprocessable entity | **Abort** — fix the payload structure |
| `429` | Rate limit exceeded | **Retry** with exponential backoff |
| `500` | Internal server error | **Retry** with exponential backoff + `deduplicationId` |
| `502` / `503` / `504` | Gateway/service unavailable | **Retry** with exponential backoff + `deduplicationId` |
## Retry strategy [#retry-strategy]
* Use bounded exponential backoff for transient failures (start at 1s, max 30s, max 5 retries).
* Reuse `deduplicationId` on retryable create/event calls — see below.
* Stop retrying on deterministic validation failures — every `4xx` except `409 PENDING_PROCESS_CONFLICT_ERROR`, `429`, and the expired-token `403`, which is resolved by refreshing the token rather than by retrying the same request.
## deduplicationId mechanics [#deduplicationid-mechanics]
The `deduplicationId` is a **create-once** key for write operations:
1. **Generate** a unique ID **before** the first attempt
2. **Store** it alongside the operation in your system
3. **Reuse** the same ID on every retry of that operation
The ID is scoped per [Network Integrator](/docs/protocol/network-integrators). This is critical for
`POST /documents` and `POST /documents/{id}/events`.
If the server already processed your request, the retry is rejected with `409 CONFLICT_ERROR`
(`Document deduplicationId: (…) already exists`). That conflict is the confirmation that the
original write succeeded and no duplicate was created — it is **not** an error to fix and **not**
a signal to retry as-is. The response does not carry the original document or event id.
A lost `POST /documents` response is therefore not recoverable through the API on your own. The only
document read is `GET /documents/{id}`: there is no lookup by `externalId` or `deduplicationId`, and
the retry's `409` does not return the id. Send `externalId` anyway — it is what Carrot support needs
to locate the document for you — but treat recovering the id as a support request, not a
self-service call. There is no safe way to repeat the write yourself: reusing the
`deduplicationId` returns the `409` without the id, and using a new one creates a second document.
Record the id from the first successful response before doing anything else, and keep the request
timeout generous enough that a slow commit does not look like a lost one.
## Immutability recovery pattern [#immutability-recovery-pattern]
Because documents follow an immutable event-sourced model (see [Core Concepts](/docs/integrations/getting-started/core-concepts)), a wrong timeline step cannot be corrected in place.
### CANCEL and recreate [#cancel-and-recreate]
When a document has incorrect data (e.g. wrong participant), cancel it and create a corrected replacement:
```text
1. POST /documents/{wrongDocumentId}/events
{
"name": "CANCEL",
"metadata": {
"attributes": [
{ "name": "reason", "value": "Wrong participant on original document", "isPublic": true }
]
},
...
}
2. POST /documents
{ ...corrected document data... }
3. POST /documents/{newDocumentId}/events
{
"name": "RELATED",
"relatedDocument": {
"documentId": "{wrongDocumentId}",
"bidirectional": true,
"isPublic": true
},
...
}
```
A `CANCEL` event must carry a non-empty `reason` metadata attribute; omitting it returns `400` with
`The reason metadata is required for CANCEL events`. Every metadata attribute also requires its own
`isPublic`, so the attribute object must be complete.
The `RELATED` event creates a traceability link between the cancelled document and its replacement, maintaining an auditable history.
## Rate limiting [#rate-limiting]
The [Carrot API](/docs/integrations/api) enforces rate limits **per API client** (see [Rate Limits](/docs/integrations/reference/rate-limits) for the full reference):
| Limit | Value |
| --------- | ---------------------- |
| Sustained | 20 requests per second |
| Burst | 30 requests |
The limit is identical in test and production: the environment is selected by your credential, not by
a separate throttle tier.
Implement a client-side token bucket or leaky bucket to stay within limits. When you receive a `429`, apply exponential backoff before retrying.
## Observability [#observability]
Log these fields from every API response for debugging and support:
* **Request ID** — returned in response headers
* **Your `externalId`** — your internal correlation ID
* **Error envelope fields** — `errors[].code`, `errors[].id`, `errors[].timestamp`
* **Retry count** — how many attempts were made
* **Terminal failure reason** — why retries stopped
# File Uploads
Carrot attachments use a two-step presigned URL flow.
## Step 1: Request upload URL [#step-1-request-upload-url]
Call:
`PUT /documents/{documentId}/attachments/{fileName}`
With:
* `contentLength` (bytes)
* `contentType` (MIME type)
Reference: [Attachments API](/docs/integrations/api/attachments).
## Step 2: Upload directly to storage [#step-2-upload-directly-to-storage]
Use the returned URL and upload file bytes with the same MIME type.
* No bearer token is required on the presigned upload call.
* Keep upload request headers consistent with step 1 payload.
## Recommended practices [#recommended-practices]
* Enforce the 10 MB size limit client-side before upload — see [Rate Limits](/docs/integrations/reference/rate-limits).
* Use deterministic file names when possible.
* Persist uploaded file names to reference later in event metadata.
## Download flow [#download-flow]
Request a temporary download URL via:
`GET /documents/{documentId}/attachments/{fileName}`
Then fetch the returned URL.
Related guides:
* [Submitting a MassID](/docs/integrations/guides/submitting-a-mass-id) — file uploads in context of a full document lifecycle.
# Methodology Integration
Each [methodology](/docs/methodologies) adds its own required events, participant roles, and validation
rules on top of the [base integration flow](/docs/integrations/guides/submitting-a-mass-id). Every
methodology has a dedicated integration guide, versioned alongside the
[Methodology Verification Application (MvA)](/docs/standard/concepts/mva) it targets.
## Available guides [#available-guides]
| Methodology | Guide |
| ----------------- | ------------------------------------------------------------------------------ |
| BOLD Recycling | [v1.0.0](/docs/methodologies/bold-recycling/framework/application/integration) |
| BOLD Carbon (CH₄) | [v1.0.0](/docs/methodologies/ams-iii-f/bold-carbon/application/integration) |
## Before you start [#before-you-start]
Make sure you are familiar with:
* [Submitting a MassID](/docs/integrations/guides/submitting-a-mass-id) — the base API workflow shared by all methodologies.
* [Core Concepts](/docs/integrations/getting-started/core-concepts) — document model, event ordering, and idempotency.
# Permissions
Document access is controlled through `ACTOR` events — an event-driven permission model. See
[Event Specification](/docs/integrations/reference/event-specification) for the full event category
reference.
## Base rules [#base-rules]
* The creator [integration](/docs/protocol/network-integrators) starts with write capabilities on created documents.
* Every document includes a system-level ACTOR automatically so platform services can read and create
events when required.
* Additional participants and roles can be granted through ACTOR events.
* The most recent ACTOR permissions for a participant are the effective permissions ("last write wins").
## Permission structure [#permission-structure]
Each policy is keyed by `participantId` and defines an effect (`ALLOW` / `DENY`), the actions it
covers, and an optional condition.
Typical allow policy:
```json
{
"f56ed1cf-bfef-4299-8088-449a5d405130": [
{
"effect": "ALLOW",
"actions": ["WRITE", "READ"],
"condition": {
"$in": {
"eventNames": ["RELATED"]
}
}
}
]
}
```
Typical deny policy:
```json
{
"f56ed1cf-bfef-4299-8088-449a5d405130": [
{
"effect": "DENY",
"actions": ["WRITE"]
}
]
}
```
If `condition` is omitted, the policy applies to the whole document context.
## Recommended implementation pattern [#recommended-implementation-pattern]
1. Create document.
2. Add participant role events in explicit order.
3. Validate resulting access behavior in your integration tests.
4. Send an empty `permissions` array in ACTOR to remove participant access when needed.
## Cross-integrator scenarios [#cross-integrator-scenarios]
To relate a document or add events in a document owned by another integration, an existing participant
with access must add your participant as ACTOR with `WRITE` permission on that document.
## Common pitfalls [#common-pitfalls]
* Sending duplicate/conflicting ACTOR updates without deterministic ordering.
* Assuming implicit access for participants not explicitly modeled.
* Mixing test/prod credentials in cross-party permission flows.
Reference: [Events API](/docs/integrations/api/events).
# Privacy & Masking
The Carrot platform is designed to make supply chain logistics transparent and publicly verifiable.
However, some data is sensitive for business or privacy reasons. This guide covers the privacy
controls available at the document and event metadata levels.
Visibility flags are set when creating a document (see [Documents API](/docs/integrations/api/documents)) and can
be adjusted through `UPDATE` events (see
[Event Specification](/docs/integrations/reference/event-specification)).
## Visibility controls [#visibility-controls]
* `isPublic`: controls whether data is visible on public surfaces such as the [Carrot Registry](/docs/protocol/registry).
* `isPubliclySearchable`: controls whether records can be found through public search.
The `isPublic` flag appears at four levels on the write path, and is required at each of them:
* **Document level** — `isPublic` on document create, controlling the document itself.
* **Event level** — `isPublic` on each event, controlling visibility of the entire event.
* **Attachment level** — `isPublic` on each entry of the event's `attachments` array, which is what
governs the attachment rows in the table below.
* **Metadata attribute level** — `isPublic` on each entry of `metadata.attributes`, which overrides
event-level visibility for that attribute.
Lower levels can override higher ones — e.g. an attribute can be marked private inside a
public event. Override precedence is applied by the Carrot platform.
The `target` and `updates` objects carry their own `isPublic` for the document they create or
modify. `relatedDocument.isPublic` is different: it controls whether the mirrored event written on
the related document is public, not that document's own visibility. It is required when
`bidirectional` is `true`.
When a document or event is marked as public (`isPublic: true`), anyone with the document ID can
view it on the Carrot Registry (registry.carrot.eco). When private (`isPublic: false`), the
data is hidden from public view but remains accessible to auditors for compliance verification.
## Participant identity [#participant-identity]
Visibility flags govern the event and its metadata. The identity of the participant behind the event
is governed separately by `preserveSensitiveData`, a boolean accepted on every event.
When the participant is a company, setting `preserveSensitiveData: true` on the event forces its
identity private — `name`, `taxId`, `taxIdType`, and the address coordinates are suppressed — while
the event itself remains publicly visible.
**Omitting the field is not the same as sending `false`.** Carrot's public MassID surface publishes a
participant name only when the `ACTOR` event carries `isPublic: true` **and**
`preserveSensitiveData: false` explicitly. The check is `!== false`, so an absent field is treated
like `true` and the name is withheld with no error. Send the flag explicitly on every `ACTOR` event,
whichever way you want it to go.
Even with both flags set, some roles are never named on that surface — Waste Generator, Hauler, and
Bin Custodian are withheld regardless — so setting them does not guarantee publication.
`preserveSensitiveData` is not the same as `isPublic: false`, which removes the whole event from the
public timeline and therefore from public traceability. Use `preserveSensitiveData` when the
operational step must stay visible but the participant behind it must not.
The field is also accepted on `relatedDocument`, where it is rejected when `bidirectional` is `false` — as are `eventName` and `eventLabel`, since there is no mirrored event to describe.
## Per-role visibility policy [#per-role-visibility-policy]
The following defaults apply across all methodologies:
* Processor and recycler data **must be public**.
* Generator and hauler data — company information, addresses, PII, vehicle plates — **must be private**.
* Open-text fields **must never contain sensitive data**, regardless of event visibility.
For methodology-specific recommendations, follow the `isPublic` flags in the canonical examples:
* [BOLD Recycling — MassID Event Reference](/docs/methodologies/bold-recycling/framework/application/event-reference)
* [BOLD Carbon — MassID Event Reference](/docs/methodologies/ams-iii-f/bold-carbon/application/event-reference)
## Sensitive data handling [#sensitive-data-handling]
For metadata attributes that contain sensitive or personal data (e.g. license plates, driver
identifiers), you have two options:
* **Full privacy** — Set `isPublic: false` to hide the data entirely from public surfaces.
* **Partial masking** — Send the **full value**, set `isPublic: true`, and set `sensitive: true` in
the metadata. The platform applies masking on public surfaces — a plate sent as `ABC-1234` appears
as `AB****34` — while preserving the full value for auditors.
Masking always covers a single contiguous run in the middle of the value: at least 4 characters and
at least half the value, leaving at most 8 characters visible, split between the start and the end.
Only string values are masked. A non-string attribute marked `sensitive` is treated as private, and
its value is omitted entirely from public surfaces.
Do not pre-mask or redact values in your payload. Send the complete data and let the platform handle
the masking.
`sensitive` is a signal you send, not the mechanism that keeps a value off Carrot's own public
surfaces. The public MassID API and the registry metadata document publish a fixed set of attributes
maintained in Carrot's code, so an attribute you add is not published there whether or not you flag
it. Set the flag correctly regardless — it is what governs masking on the public document page — but
do not treat it as the guarantee.
See [Data Formats](/docs/integrations/reference/data-formats#sensitive-data) for the `sensitive`
attribute and mask format conventions.
## Common private data patterns [#common-private-data-patterns]
The following table lists data fields that partners commonly configure as private, along with the
rationale for each:
| Data | Category | Rationale |
| ----------------------------------- | ---------------- | -------------------------------------------------------------------------------------------- |
| Waste Generator name | Participant data | Business confidentiality — use `preserveSensitiveData: true` when the event must stay public |
| Transport manifest (MTR) | Attachment | Set `isPublic: false` on the attachment entry; the event itself remains publicly visible |
| Final destination certificate (CDF) | Attachment | Set `isPublic: false` on the attachment entry; the event itself remains publicly visible |
| Vehicle license plate | Event metadata | Personal data — use `sensitive: true` with `isPublic: true` for partial masking |
| Driver identifier | Event metadata | Personal data — use `sensitive: true` with `isPublic: true` for partial masking |
If you are unsure whether a field should be private or use partial masking, consult the Carrot team
for guidance specific to your use case.
## Practical masking strategy [#practical-masking-strategy]
1. Keep sensitive values private by default.
2. Expose only the minimum fields required by your business and public workflows.
3. Use `sensitive: true` for fields that need to be publicly visible in masked form.
4. Audit public payloads regularly to ensure no unintended data exposure.
Related references:
* [Core Concepts — Visibility and privacy](/docs/integrations/getting-started/core-concepts#visibility-and-privacy)
* [Events API](/docs/integrations/api/events)
* [Data Formats](/docs/integrations/reference/data-formats)
# Submitting a MassID
Use this sequence as the base implementation pattern for submitting a complete
[MassID](/docs/protocol/mass-ids) lifecycle through the [Carrot API](/docs/integrations/api).
## Prerequisites [#prerequisites]
Before you begin, ensure you have:
* A registered [Network Integrator](/docs/protocol/network-integrators) account with valid API credentials
* Participant and address data ready — resolve each one first (retrieve by key or create it) so you can
reference it by `participantId` and `addressId`, as shown in Step 1
* Familiarity with [core concepts](/docs/integrations/getting-started/core-concepts) — especially the immutable event-sourced model
Submit mass data as the operation happens. The last cycle that can analyze a batch is the one in
the year after its Recycled event, and data has to reach the network by **30 November** of that
year — a batch recycled in 2025 has until 30 November 2026. The [methodology
framework](/docs/standard/concepts/mvf) rule behind the limit, the cut-off time, and what happens
after it are described in [Submission window](/docs/protocol/mass-ids#submission-window).
## Step 1: Resolve participants and addresses [#step-1-resolve-participants-and-addresses]
Every document and event needs a participant **and** an address. Reference them **by ID** — the form this guide uses — or send the objects inline, which find-or-creates them. Before submitting, resolve each
one — look it up by key, or create it — and keep the returned `participantId` and `addressId`.
**Retrieve by key.** Look up an existing participant by its natural key — country code, tax ID type, and tax ID:
```http
GET /participants?countryCode=BR&taxIdType=CNPJ&taxId=11111111111111
```
If it exists, reuse the returned `participantId` and list its addresses to find the `addressId`:
```http
GET /participants/{participantId}/addresses
```
**Create when missing.** If the participant does not exist yet, create it, then add an address to it:
```json
POST /participants
{
"countryCode": "BR",
"name": "Example Company",
"taxId": "11111111111111",
"taxIdType": "CNPJ",
"type": "COMPANY"
}
```
```json
POST /participants/{participantId}/addresses
{
"name": "Main Facility",
"street": "Rua das Colinas",
"number": "500",
"neighborhood": "Centro",
"city": "São Paulo",
"countryState": "São Paulo",
"countryCode": "BR",
"zipCode": "08575720",
"latitude": -23.5489,
"longitude": -46.6388
}
```
Each create call returns the generated `id` — use it as `participantId` / `addressId` in the next steps.
Required fields: participant — `countryCode`, `name`, `taxId`, `taxIdType`, `type`; address — `city`,
`countryCode`, `countryState`, `name`, `number`, `street`. See the
[Participants API](/docs/integrations/api/participants) for the full request and response schema.
Creating a participant or address that already exists is safe only if you send **identical** data
— the platform matches on the natural key and rejects conflicting values. Prefer retrieving by key
and reusing the returned ID.
## Step 2: Create the document [#step-2-create-the-document]
Create the root record with classification and baseline visibility fields, referencing the participant and
address you resolved in Step 1:
```json
POST /documents
{
"category": "MassID",
"type": "YOUR_WASTE_TYPE",
"measurementUnit": "kg",
"externalCreatedAt": "2026-03-01T10:00:00.000Z",
"isPublic": true,
"isPubliclySearchable": true,
"participantId": "participant-id-from-step-1",
"addressId": "address-id-from-step-1",
"externalId": "your-internal-tracking-id",
"deduplicationId": "unique-id-generated-before-first-attempt"
}
```
| Field | Required | Description |
| ---------------------- | -------- | ------------------------------------------------------------------------------------------------ |
| `category` | Yes | Always `MassID` for mass tracking documents |
| `type` | Yes | Waste type — defined per methodology (see note below) |
| `measurementUnit` | No | Defaults to `kg` when omitted — send it explicitly. `kg` is the value both methodologies require |
| `externalCreatedAt` | Yes | ISO 8601 timestamp of the real-world document creation |
| `isPublic` | Yes | Whether the document is publicly visible |
| `isPubliclySearchable` | Yes | Whether the document appears in public search |
| `participantId` | One of | ID of the participant resolved in Step 1 — send this **or** an inline `participant`, never both |
| `addressId` | One of | ID of the address resolved in Step 1 — send this **or** an inline `address`, never both |
| `externalId` | No | Your internal ID for reconciliation — useful for mapping back to your system |
| `deduplicationId` | No | Idempotency key — see tip below |
You can send full `participant` and `address` objects inline instead of
`participantId`/`addressId`; the platform find-or-creates them. Send **exactly one** of each pair
— both, or neither, fails validation with `400 VALIDATION_ERROR`. Prefer resolving in Step 1 and
referencing by ID; the inline form is the only way to create a document together with a new
participant or address in a single call.
The `type` field (waste type) and `measurementUnit` are defined by your target methodology. See
the [methodology integration guides](/docs/integrations/guides/methodology-guides) for the
specific values required. A MassID is measured in `kg` under both BOLD Recycling and BOLD Carbon —
the rule set rejects any other value. `kg CO₂e` is the unit of the emission reductions the
methodology calculates from that mass, not the unit of the MassID itself.
Reference: [Documents API](/docs/integrations/api/documents).
## Step 3: Append timeline events [#step-3-append-timeline-events]
Append events in chronological order to represent operational steps. Each event is
immutable once created.
### ACTOR events [#actor-events]
ACTOR events register participant roles on the document timeline. Each requires a `label` identifying the role, plus the participant and address it applies to, referenced by ID:
```json
POST /documents/{documentId}/events
{
"name": "ACTOR",
"label": "YOUR_ROLE_LABEL",
"externalCreatedAt": "2026-03-01T10:05:00.000Z",
"isPublic": true,
"participantId": "actor-participant-id",
"addressId": "actor-address-id"
}
```
The `label` value (e.g. `"Waste Generator"`, `"Hauler"`, `"Processor"`) is defined by each methodology. See your methodology guide for the required roles and their labels.
Resolve each actor's participant and address the same way as in Step 1, then reference them by `participantId` and `addressId`.
### CUSTOM events [#custom-events]
CUSTOM events represent methodology-specific operational steps. The event name, required metadata attributes, and sequence are all defined by the methodology:
```json
POST /documents/{documentId}/events
{
"name": "YOUR_EVENT_NAME",
"externalCreatedAt": "2026-03-01T11:00:00.000Z",
"isPublic": true,
"participantId": "participant-id-from-step-1",
"addressId": "address-id-from-step-1",
"metadata": {
"attributes": [
{ "name": "YOUR_ATTRIBUTE_NAME", "value": "attribute-value", "isPublic": true }
]
},
"value": 150.5
}
```
The `value` field on events contributes to the document's `currentValue`. For example, a weighing event with `value: 150.5` sets the tracked weight.
Events accept the same inline `participant` and `address` objects as documents, with the same
find-or-create behavior. Prefer referencing `participantId` and `addressId`.
Each methodology defines the specific event sequence, event names, and required metadata
attributes. See the [methodology integration guides](/docs/integrations/guides/methodology-guides)
for the values required by each methodology.
### Document status lifecycle [#document-status-lifecycle]
Documents follow a strict status lifecycle:
* **`OPEN`** — Default status after creation. Events can be appended freely.
* **`CLOSE` event** — Transitions the document to `CLOSED`. After closing, only `RELATED` and `CANCEL` events are accepted — `CANCEL` survives `CLOSE` precisely so the [CANCEL-and-recreate pattern](/docs/integrations/guides/error-handling#cancel-and-recreate) stays available on a closed document.
* **`CANCEL` event** — Transitions the document to `CANCELLED`. No further events are accepted.
Send a `CLOSE` event when the [supply chain](/docs/protocol/supply-chain) lifecycle is complete:
```json
POST /documents/{documentId}/events
{
"name": "CLOSE",
"externalCreatedAt": "2026-03-02T16:00:00.000Z",
"isPublic": true,
"participantId": "integrator-participant-id",
"addressId": "integrator-address-id"
}
```
See [Event Specification](/docs/integrations/reference/event-specification) for the full list of event categories.
Reference: [Events API](/docs/integrations/api/events).
For high-volume integrations, consider the [batch events endpoint](/docs/integrations/api/events#batch-events) to submit multiple events per request.
## Step 4: Attach evidence files (optional) [#step-4-attach-evidence-files-optional]
Some methodology rules require evidence attachments (e.g. scale tickets, transport manifests).
The pattern is:
1. **Request a pre-signed upload URL** via the Attachments API
2. **Upload the file** directly to the pre-signed URL
3. **Reference the attachment** in the relevant event's `attachments` array
Attachments are linked to specific events, not to the document as a whole. This ensures each piece of evidence is tied to the operational step it documents.
Reference: [Attachments API](/docs/integrations/api/attachments).
## Step 5: Retrieve and validate final state [#step-5-retrieve-and-validate-final-state]
Fetch the document and verify before considering the submission complete:
* **Event count and ordering** — all expected events are present in chronological order
* **Status is `CLOSED`** — the document has been properly closed
* **`currentValue` > 0** — the document has a positive tracked value
* **At least one `ACTOR` event** — the required participant roles are registered
* **Participant and address links** — all references resolve correctly
* **Metadata completeness** — required attributes are present on each event per the methodology
Reference: [GET document by ID](/docs/integrations/api/documents).
## Operational tips [#operational-tips]
Always send `deduplicationId` on retryable write calls (document creation and event creation).
Generate a unique ID **before** the first attempt, store it, and **reuse the same ID** on every
retry. The ID is scoped per integrator — two different integrators can use the same ID without
conflict. A replayed ID is **rejected** with `409 CONFLICT_ERROR`, never replayed: treat that
conflict as confirmation that the first attempt succeeded and no duplicate was created. The
response does not return the original document id, and no endpoint looks a document up by
`externalId` or `deduplicationId` — so record the id from the first successful response, and treat
a lost `POST /documents` response as a support request.
* Use `externalId` on documents and events for reconciliation with your internal systems.
* Treat `4xx` as data/integration issues and `5xx` as transient failures — see [Error Handling](/docs/integrations/guides/error-handling).
* Plan backfills to land before the 30 November cut-off — see [Submission window](/docs/protocol/mass-ids#submission-window).
* Keep your source timestamp strategy deterministic — see [Data Formats](/docs/integrations/reference/data-formats).
# Data Formats
Use these conventions to reduce validation errors and keep data interoperable.
## Metadata attribute names [#metadata-attribute-names]
Use **Title Case** for metadata attribute names (e.g. `Vehicle License Plate`, `Gross Weight`, `Issue Date`). Do not use kebab-case or lowercase-concatenated names in event metadata. The one exception is `reason` on a `CANCEL` event, which the platform matches in lowercase.
## Date and time [#date-and-time]
* Use ISO 8601 UTC timestamps (`YYYY-MM-DDTHH:mm:ss.sssZ`) for date-time fields.
* For date-only fields, use ISO 8601 date format and, when required by the API, include a `format` attribute (e.g. `DATE`).
* Preserve source chronology across event submissions.
## Identifiers [#identifiers]
* Keep IDs stable and deterministic across retries.
* Use `deduplicationId` as a create-once idempotency key on retryable writes; a replay is rejected
rather than replayed — see [Error Handling](/docs/integrations/guides/error-handling).
* `externalId` is stored for your own correlation and is **not** used for deduplication.
## Naming conventions [#naming-conventions]
* Use consistent attribute names and avoid synonymous duplicates.
* Prefer structured metadata over free-form string blobs.
## Numeric values and units [#numeric-values-and-units]
* Send numeric fields as numbers, not localized strings.
* When the API requires a unit or scale, use the `format` attribute with the appropriate value (e.g. `KILOGRAM`, `LITER`, `CUBIC_METER` for mass/volume).
* Keep unit choice consistent within a document lifecycle.
## Sensitive data [#sensitive-data]
For attributes that contain sensitive or personal data (e.g. license plates, driver identifiers):
* Send the **full value** in your payload — do not pre-mask or redact.
* Set `sensitive: true` in the metadata. It governs masking on the public document page; it is a
signal you send, not the mechanism that keeps an attribute off Carrot's own public MassID surfaces,
which publish a fixed set of attributes maintained in Carrot's code.
* See [Privacy & Masking](/docs/integrations/guides/privacy-and-masking) for visibility controls.
## Participant identity on ACTOR events [#participant-identity-on-actor-events]
Carrot's public MassID surface names participants from `ACTOR` events only — a participant attached
to a `CUSTOM` or other event is never named there, whatever its flags say. On an `ACTOR` event,
publishing the name takes two independent flags:
* `isPublic: true` on the event. This field is required, so omitting it fails validation rather than
changing what is published.
* `preserveSensitiveData: false` — set **explicitly**. This one is optional, and that is the trap:
the check is `!== false`, so leaving it out is treated the same as `true` and the identity is
withheld with no error.
Even with both flags set, some roles are never named on Carrot's public MassID surface — Waste
Generator, Hauler, and Bin Custodian are withheld regardless. Do not assume that setting both flags
publishes any participant name.
Related references:
* [Core Concepts](/docs/integrations/getting-started/core-concepts)
* [Error Handling](/docs/integrations/guides/error-handling)
* [Event Specification](/docs/integrations/reference/event-specification)
* [Privacy & Masking](/docs/integrations/guides/privacy-and-masking)
# Event Specification
This page is the canonical reference for event modeling at the macro/base level.
## Built-in logical event categories [#built-in-logical-event-categories]
| Type | Purpose |
| --------- | ------------------------------------------------------------------------ |
| `ACTOR` | Grants or updates participant roles/permissions on a document timeline. |
| `CLOSE` | Closes the document for future updates (except specific relation flows). |
| `CANCEL` | Cancels the document and blocks future actions. Requires a `reason`. |
| `RELATED` | Creates relation links between documents. |
| `UPDATE` | Updates selected document visibility-related fields. |
| `OUTPUT` | Conventional name for an event that creates a downstream document. |
| `CUSTOM` | Methodology/application-specific event names. |
A downstream document is created by the presence of the `target` object on **any** event, not by the
event name — `OUTPUT` is the conventional name for that pattern, and it is handled as a `CUSTOM`
event.
A `CANCEL` event must carry a `metadata.attributes` entry named `reason` with a non-empty value;
omitting it returns `400` with `The reason metadata is required for CANCEL events`.
For implementation patterns using specific event categories, see:
* `ACTOR`: [Permissions guide](/docs/integrations/guides/permissions)
* `CANCEL` / `CLOSE`: [Error Handling guide](/docs/integrations/guides/error-handling)
* `RELATED` / `OUTPUT`: [Submitting a MassID](/docs/integrations/guides/submitting-a-mass-id)
* `UPDATE`: [Privacy & Masking guide](/docs/integrations/guides/privacy-and-masking)
* `CUSTOM`: Defined per [methodology](/docs/methodologies) — see the [methodology integration guides](/docs/integrations/guides/methodology-guides) for specific events and validation rules.
## Common event fields [#common-event-fields]
Most event payloads share these core fields:
* `name`
* `externalCreatedAt`
* `isPublic`
* `metadata`
* `participantId` (or an inline `participant` object, which find-or-creates the record)
* `addressId` (or an inline `address` object, which find-or-creates the record)
Every event must carry exactly one of `participantId`/`participant` and exactly one of
`addressId`/`address`. Sending both forms, or neither, fails with `400 VALIDATION_ERROR`
(`You must pass participantId or participant field, not both, not neither`). The rule is identical on
the single-event and batch endpoints.
* optional `attachments`
* optional `deduplicationId`
Give every `ACTOR` event a **label** — the label *is* the participant's role. The schema does not enforce it, so this is a platform requirement rather than a request-validation one. Each [methodology integration guide](/docs/integrations/guides/methodology-guides) defines its allowed labels and required order. Do not use deprecated role fields such as `actor-type`.
An absent or unrecognized label is not an error. The event is accepted, but the participant
contributes no reward share and its name is withheld from the public record — a failure you will only
notice downstream. MassID-document labels are `Bin Custodian`, `Hauler`, `Integrator`, `Processor`,
`Recycler`, and `Waste Generator` (`Integrator` normalizes to the role `Network Integrator`).
## CUSTOM events [#custom-events]
`CUSTOM` events accept any event `name` — [Network Integrators](/docs/protocol/network-integrators) can define and send whatever operational events fit their workflow. The platform does not restrict CUSTOM event names at the API level.
Methodologies define their own expected CUSTOM event vocabularies and validate them through [application rules](/docs/standard/concepts/mva#framework-rules-vs-application-rules). See the relevant [methodology integration guide](/docs/integrations/guides/methodology-guides) for the specific events and validation rules that apply.
## Ordering and propagation constraints [#ordering-and-propagation-constraints]
* Event timestamps must remain chronologically consistent.
* Propagation behavior is constrained and should be explicitly validated in integration tests.
* Use deterministic retry patterns to avoid duplicate timeline entries.
Endpoint reference: [Events API](/docs/integrations/api/events).
# Rate Limits
The Carrot API enforces the following limits per API client.
## Limits [#limits]
| Limit | Value |
| ------------------------------- | ----------- |
| Requests per second (sustained) | 20 |
| Burst allowance | 30 requests |
| Events per document | 100 |
| Max file upload size | 10 MB |
Throttling is applied per API client and is identical in test and production — the environment is
selected by your credential, not by a separate throttle tier. Size your client-side token bucket
against the burst allowance, not the sustained rate alone.
## Handling throttling [#handling-throttling]
* Exceeding request throughput returns a `429` response with `{"message": "Too Many Requests"}`.
* Apply client-side token bucket or leaky bucket rate limiting.
* Smooth bursts; do not rely on minute-level averages only.
Related references:
* [API Errors](/docs/integrations/api/errors)
* [Error Handling Guide](/docs/integrations/guides/error-handling)
# Waste Classification
Every document submitted to the [Carrot API](/docs/integrations/api) is classified using a three-level
hierarchy: **Category**, **Type**, and **Subtype**. The first two levels are required; the third is
optional in the API, though a methodology may require it. This structure organizes documents for
grouping, traceability, and methodology validation.
## Classification hierarchy [#classification-hierarchy]
A subtype always belongs to a type, and a type always belongs to a category. This ensures that each
document is positioned correctly within the platform's classification context.
### Category [#category]
The broadest classification level. It indicates the general context of the document. For supply
chain integrations, the category is typically [`MassID`](/docs/protocol/mass-ids), which refers to documents tracking the
history of a waste mass.
Other categories (such as `Methodology`) exist for internal platform flows and are not used in
standard integrations.
### Type [#type]
The type identifies the primary material or process class within a category. Under the `MassID`
category, the type is one of:
* `Glass`
* `Metal`
* `Organic`
* `Paper`
* `Plastic`
This is the vocabulary the platform recognizes downstream — certificate issuance and the public
MassID API both parse `type` against exactly these five values and drop records outside them.
`POST /documents` itself accepts `type` as a free string, so a value outside this list is accepted at
submission and dropped later.
### Subtype [#subtype]
The subtype provides the most specific classification, refining the type with detailed information
about the material. For example:
* For type `Plastic`: `PET` — the only accepted plastic subtype
* For type `Organic`: `Domestic Sludge`, `EFB similar to Garden, Yard and Park Waste`,
`Food, Food Waste and Beverages`, `Garden, Yard and Park Waste`, `Industrial Sludge`,
`Others (if organic)`, `Tobacco`, `Wood and Wood Products`
Subtypes must be sent in English. The accepted subtypes depend on the [methodology](/docs/methodologies) under which the
mass will be audited — consult the methodology-specific integration guide for the full list.
## Methodology-specific subtypes [#methodology-specific-subtypes]
Each methodology defines the accepted subtypes for validation. A mass submitted for a methodology
must use one of its accepted subtypes to pass validation rules.
* [BOLD Recycling — Integration Guide](/docs/methodologies/bold-recycling/framework/application/integration)
* [BOLD Carbon (CH₄) — Integration Guide](/docs/methodologies/ams-iii-f/bold-carbon/application/integration)
## Validation expectations [#validation-expectations]
* `category` and `type` are required on every document. `subtype` is optional in the API, but a methodology may require it — a MassID without a subtype cannot pass methodology verification under a methodology that defines accepted subtypes, so no certificate is issued from it.
* Category/type combinations should follow your approved business taxonomy.
* Keep mappings deterministic across environments (test and production).
* Validate unsupported combinations before API submission to avoid rejection.
## External code systems [#external-code-systems]
Some methodologies require external waste classification codes alongside the Carrot subtype. These
codes connect the Carrot classification to national or international standards.
### Ibama codes (Brazil) [#ibama-codes-brazil]
[Ibama](/docs/glossary#ibama) (Instituto Brasileiro do Meio Ambiente e dos Recursos Naturais
Renováveis) publishes the
[Brazilian List of Solid Waste](https://www.gov.br/ibama/pt-br/assuntos/emissoes-e-residuos/residuos/arquivos/ibama-lista-brasileira-de-residuos-solidos.doc)
(Lista Brasileira de Resíduos Sólidos, per IN nº 13/2012). Each waste material is assigned a 6-digit
code (for example, `02 01 01`). Include the Ibama code and description in the
`Local Waste Classification ID` and `Local Waste Classification Description` metadata attributes.
### CDM waste categories [#cdm-waste-categories]
The [CDM](/docs/glossary#cdm) (Clean Development Mechanism) Tool 04 v08.1 defines waste
categories used for emission factor assignment. Each Ibama code maps to a CDM category (for example,
`8.3` for food waste). The methodology uses this mapping to select the correct emission factors.
### Methodology-specific code lists [#methodology-specific-code-lists]
BOLD Carbon requires both Ibama and CDM codes, validated by the `regional-waste-classification` rule.
See the
[BOLD Carbon Framework — Supported waste codes](/docs/methodologies/ams-iii-f/bold-carbon#supported-waste-codes)
for the complete list of accepted Ibama codes and their CDM mappings.
Related references:
* [Core Concepts](/docs/integrations/getting-started/core-concepts)
* [Documents API](/docs/integrations/api/documents)
* [Data Formats](/docs/integrations/reference/data-formats)
# Interoperability
## Designed for integration [#designed-for-integration]
The Carrot Network's smart contracts are built on open standards and deployed on a public blockchain, making them inherently interoperable with external systems and standard tooling. Every operation — from minting [MassIDs](/docs/protocol/mass-ids) to purchasing [credits](/docs/protocol/credits) to distributing rewards — emits on-chain events that external systems can monitor, index, and verify.
## On-chain verifiability [#on-chain-verifiability]
All Carrot smart contract transactions are publicly visible on the blockchain. This means:
* **Credit purchases and retirements** can be independently verified by auditors, regulators, or any interested party.
* **Token balances and certificate records** are queryable in real time.
* **The full provenance chain** — from MassID through certificate to retired credit — is traceable on-chain.
Because this data lives on the public blockchain, transparency and trust do not depend on Carrot's infrastructure. Any blockchain block explorer (such as [PolygonScan](https://polygonscan.com/)) or indexer can access raw transaction data directly on-chain. The [Carrot Registry](/docs/protocol/registry) adds a domain-focused view, combining on-chain data with platform data (methodology definitions, rule execution, accreditations) for environmental context and traceability.
## Queryable events [#queryable-events]
Every major operation emits structured events that can be indexed by off-chain systems:
| Operation | Key events |
| -------------- | ------------------------------------------------------------------ |
| **Minting** | MassID minted, Certificate minted, Credits minted |
| **Purchase** | Purchase executed, Credits burned or transferred, Rewards assigned |
| **Retirement** | Credits retired, Credits burned, Retirement receipt minted |
| **Rewards** | Rewards recorded, Reward note withdrawals |
| **Revocation** | Token revoked |
Because every purchase is currently retired in full at the moment of sale, a purchase emits a credit burn rather than a delivery transfer to the buyer. The transfer appears only on the partial-retirement path, which is not yet used in production.
These events enable third-party applications to build dashboards, analytics tools, or compliance reporting systems on top of Carrot data without requiring direct access to the platform.
## Credit transferability [#credit-transferability]
While all NFTs in the Carrot system are [soulbound](/docs/protocol/credit-lifecycle) (non-transferable), credit tokens (ERC-20) are transferable by design. This means:
* Credits can be traded on decentralized exchanges or OTC markets.
* Secondary market liquidity can develop around environmental credits.
* Buyers can acquire credits from multiple sources and consolidate them before retirement.
Two deviations from a plain ERC-20 matter to integrators:
* **Pausing halts every balance movement.** Minting, transfers, and burns all stop while the Credit contract is paused, because the pause check sits on the single internal step every balance change passes through. Approvals and permits remain available.
* **Holder-initiated burn is disabled.** `burn` and `burnFrom` appear in the contract ABI but revert for any caller other than the [Vault](/docs/protocol/smart-contracts) or the CreditRetirementManager, so [retirement](/docs/protocol/credit-retirement) is the only path that destroys credits.
This fungibility and transferability make Carrot credits composable with the broader decentralized finance (DeFi) ecosystem while maintaining full traceability back to verified recycling work.
## Registry-based contract discovery [#registry-based-contract-discovery]
The smart contract architecture uses a [ContractRegistry](/docs/protocol/smart-contracts/contract-categories) that maps logical names to deployed addresses. This design enables:
* **Seamless upgrades** — Contracts use the UUPS (EIP-1967) proxy pattern, so the proxy address remains stable across upgrades. When the proxy is upgraded (`upgradeToAndCall`), the proxy address and its ContractRegistry entry stay the same, so all dependent contracts continue operating without redeployment. The upgrade call can carry migration calldata, which the new implementation then runs against the proxy's existing storage.
* **Loose coupling** — Contracts don't hardcode addresses of their dependencies, making the system more resilient and easier to evolve.
## Deployment network [#deployment-network]
The Carrot Network is blockchain network agnostic: smart contracts are implemented in Solidity and could be deployed on any EVM-compatible network. Carrot currently deploys on [Polygon PoS](https://polygon.technology/) for these reasons:
* **Low transaction costs** — Environmental credit operations (minting, purchasing, retiring) can be executed affordably at scale.
* **EVM compatibility** — Full compatibility with Ethereum tooling, wallets, and developer ecosystem.
* **Established ecosystem** — Broad support from indexers, explorers, and DeFi protocols.
Production runs on Polygon PoS mainnet (chain ID 137, [polygonscan.com](https://polygonscan.com/)). Non-production environments run on the Polygon Amoy testnet (chain ID 80002, [amoy.polygonscan.com](https://amoy.polygonscan.com/)), so an integration pointed at a non-production environment should index Amoy rather than mainnet.
[Learn about smart contracts](/docs/protocol/smart-contracts) · [Learn about contract categories](/docs/protocol/smart-contracts/contract-categories) · [View the Carrot Registry](https://registry.carrot.eco)
# Metadata Viewer
## What the Metadata Viewer is [#what-the-metadata-viewer-is]
The record types the [Carrot Network](/docs/network) writes to the public [registry](/docs/registry) one at a time — a [MassID](/docs/protocol/mass-ids), a [Certificate](/docs/protocol/certificates), a purchase or [retirement](/docs/protocol/credit-retirement) receipt — each carry a content-addressed provenance document stored on [IPFS](https://ipfs.tech/). The on-chain entry holds the reference, not the provenance payload. It is not empty of data — a Certificate tracks its total, purchased, retired and available amounts on chain, and a receipt records its parties, amounts and certificate allocations — but the chain of custody behind the record is what lives on IPFS. Fungible [credit tokens](/docs/protocol/credits) are registry records too, but they carry no provenance document of their own and the viewer does not open them.
The Metadata Viewer ([viewer.carrot.eco](https://viewer.carrot.eco)) is the tool that follows that reference and renders the document behind it. It reads the token's metadata URI from the [smart contract](/docs/protocol/smart-contracts), fetches the document, and checks it against the schema the record declares — all in the reader's browser.
It answers a narrower question than the [Carrot Registry](/docs/protocol/registry): not "what does this record mean in context" but "what exactly does this record say, and does it agree with the chain". It is not by itself a proof that a record is intact — [what it checks](#what-the-viewer-checks) is narrower than that, and the difference is spelled out below.
## Opening a record [#opening-a-record]
The viewer takes its input from the URL, so any record can be linked to directly. Most readers arrive on a link the platform already generated (see [Where these links appear](#where-these-links-appear)); the URL contract is documented here so a record can also be opened by hand.
**By contract address.** The canonical form. A record is addressed by the triple of contract address, network, and token identifier:
```text
https://viewer.carrot.eco/?contractAddress=0x&network=polygon&tokenId=
```
`network` takes `polygon` for the public [Polygon](https://polygon.technology/) mainnet (chain ID 137) and `amoy` for the Polygon Amoy test network (chain ID 80002). The host is the same for both — the viewer selects the chain from this parameter, and addresses and token identifiers are chain-local, so `network` has to name the chain the record was written to.
**By record type.** On the mainnet, the viewer can resolve the contract address itself through the on-chain [ContractRegistry](/docs/protocol/smart-contracts), so a record type replaces the address:
```text
https://viewer.carrot.eco/?recordType=mass-id&network=polygon&tokenId=
```
| `recordType` | Record |
| --------------------------- | ---------------------------------- |
| `mass-id` | A verified batch of waste material |
| `recycled-id` | Proof that material was recycled |
| `gas-id` | Greenhouse gas emission reductions |
| `credit-purchase-receipt` | Proof that credits were bought |
| `credit-retirement-receipt` | Proof that credits were retired |
**By IPFS reference.** A provenance document can also be opened directly by its content identifier, without knowing which contract holds it:
```text
https://viewer.carrot.eco/?cid=
```
This still reads the chain: the record names its own contract and token, and the round-trip check below re-reads that contract to confirm the document matches. What the identifier saves you is having to know the address.
The viewer also accepts a document pasted or uploaded from the reader's own machine, which is what makes that round-trip meaningful: it can tell you whether a document you were handed is the one the record's own contract and token resolve to.
## Where these links appear [#where-these-links-appear]
Viewer links are generated wherever a record is presented as evidence:
* **The Impact Certificate** — the PDF issued for a credit purchase — lists that order's public records under **Public records**, each one a link into the viewer: the purchase receipt, and the retirement receipt when the order was retired in the same transaction. An order retired later, in a standalone transaction, produces its retirement receipt after the PDF was issued.
* **Certificate records** carry a viewer link for their own registry entry, alongside the [blockchain block explorer](/docs/glossary#blockchain-block-explorer) link for the same token.
An issued Impact Certificate is a fixed document: the links printed into it are written at issuance and are never rewritten, so each one keeps pointing at the record it was issued for.
## What the record pins [#what-the-record-pins]
The record's integrity anchors are part of its format and exist whether or not any particular tool reads them:
* **The schema, pinned three ways** — a version-tagged URL, an IPFS reference to that schema, and the SHA-256 hash of the exact schema version the record was written against. Carrot's record schemas are open source at [carrot-foundation/schemas](https://github.com/carrot-foundation/schemas).
* **An audit hash** — a SHA-256 hash recorded at issuance, so a party holding the underlying source data — submitted by [Network Integrators](/docs/protocol/network-integrators) — can reconcile it against the published record. A public reader cannot recompute it from the published record alone, because the published document is redacted (see below).
* **A reference to the viewer build** — see [The viewer is verifiable too](#the-viewer-is-verifiable-too).
## What the viewer checks [#what-the-viewer-checks]
Three checks run, and each reports its own status. They are narrower than the anchors above, and the difference matters if you are relying on them:
* **Structure** — The document is validated against the copy of the schema pinned into the viewer build, matched by the schema URL the record declares. When a record declares a version the build does not carry, the viewer reports **not structurally checked** instead of validating, and fields introduced after that build was pinned are not rendered.
* **On-chain round-trip** — When a document is opened by its IPFS reference, or pasted or uploaded, the viewer re-reads the metadata URI from the contract and token the record itself names, and requires it to resolve to the same document: **verified**, or **mismatch**. This is the strongest thing the viewer does. It does not run when a record is opened by contract address, because there the document came from that contract to begin with.
* **Network** — The network embedded in the record must be one of the two supported chains, or the record is rejected outright.
The viewer does not recompute any of the record's hashes, and it does not verify that the bytes a gateway returned actually hash to the content identifier that was requested. Content addressing makes that check possible — any change to a document produces a different identifier — but it is a check a reader performs, by fetching the identifier through a client that verifies content addressing, or by re-pinning it and comparing.
Provenance documents are public, so personal and commercially sensitive attributes are [withheld or masked](/docs/integrations/guides/privacy-and-masking) before publication: an attribute marked private is left out of the published document entirely, and one kept public but flagged sensitive is published in masked form, with the full value preserved for auditors. What the viewer renders is the published record — the chain of custody as it was cleared for publication. Visibility is set per event as well as per attribute, so an event marked private is absent from the document entirely; what you are reading is not necessarily the full operational history an auditor sees.
## The viewer is verifiable too [#the-viewer-is-verifiable-too]
A verification tool that only its author can vouch for moves the trust problem rather than solving it. Every Carrot provenance record embeds an IPFS reference to the viewer build itself, so the tool that reads the record is pinned by content address, exactly like the document it reads. A reader who does not want to trust the copy served at `viewer.carrot.eco` can run the referenced build instead.
## Where it fits [#where-it-fits]
Three surfaces present the same underlying facts at different depths:
| Surface | What it shows | Reads from |
| ------------------------------------------------ | -------------------------------------------------------------------------------------------------------- | ------------------ |
| **Carrot Registry** | Records in environmental context — methodologies, verification results, accreditations, credit lifecycle | Carrot's platform |
| **Metadata Viewer** | The provenance document behind one record, checked against the schema the record declares | The chain and IPFS |
| **Blockchain block explorer** (e.g. PolygonScan) | Raw on-chain transactions, contract calls, and event logs | The chain |
The Registry is where a reader starts from a question about impact. The Metadata Viewer is where a reader ends up when the question becomes whether a specific record holds up on its own.
[Learn about the Carrot Registry](/docs/protocol/registry) · [Learn about registry record creation](/docs/protocol/on-chain-minting)
# Certificates
## What are certificates? [#what-are-certificates]
Certificates are the middle layer of the Carrot Network's [credit lifecycle](/docs/protocol/credit-lifecycle) — they sit between [MassIDs](/docs/protocol/mass-ids) (which track physical waste) and [Credits](/docs/protocol/credits) (which are bought and sold on the market). A certificate represents a single MassID that has passed methodology verification, proving a specific quantity of recycling or emission reductions. On the network's public registry, each certificate is a permanent, non-transferable record held by the [Vault](/docs/protocol/smart-contracts); when it is issued, a matching amount of fungible credits is created automatically (1 credit = 1 metric ton).
This ensures that every credit in circulation is backed by a verified certificate, which is in turn backed by a verified MassID.
## Certificate types [#certificate-types]
The Carrot Network issues certificate types that are tied to methodologies. Each methodology defines which certificate type it issues and which credit symbol is issued:
| Certificate | Credit generated (example) | Issued by | What it verifies |
| -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| **RecycledID** | `C-BIOW` ([TRC](/docs/protocol/credits#tokenized-recycling-credits-trc)) when issued under [BOLD Recycling](/docs/methodologies/bold-recycling) | Recycling methodologies | That a specific quantity of waste material was certified recycled at an accredited facility |
| **GasID** | `C-CARB.CH4` ([TCC](/docs/protocol/credits#tokenized-carbon-credits-tcc)) when issued under [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) | Carbon methodologies | That a specific quantity of greenhouse gas emissions (CO₂e) was reduced through waste diversion or biological treatment |
Other methodologies may issue different credit symbols for their certificates.
### RecycledID [#recycledid]
A RecycledID certificate is issued when a MassID of a specific waste type reaches an [accredited Recycler](/docs/protocol/supply-chain#the-role-of-the-recycler), passes digital MRV ([dMRV](/docs/protocol/dmrv)) verification, and satisfies all rules defined by an active recycling methodology. The certificate records the weight of certified recycled material and references the underlying MassID that proves provenance. Under the [BOLD Recycling](/docs/methodologies/bold-recycling) methodology, each RecycledID generates a corresponding amount of `C-BIOW` credits; other recycling methodologies may issue different credit symbols.
### GasID [#gasid]
A GasID certificate quantifies the greenhouse gas **emission reductions** achieved through waste diversion or biological treatment instead of disposal in a landfill or dump. GasIDs are generated directly from MassIDs by a carbon methodology: the emission reductions are calculated by comparing the diversion or treatment scenario against the baseline disposal scenario.
The core calculation is: **Emission Reductions = Baseline Emissions − Real Emissions**. Under the [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) methodology, each GasID generates a corresponding amount of `C-CARB.CH4` credits (methane reductions); other carbon methodologies may issue different credit symbols.
Emission Reductions = Baseline Emissions − Real Emissions
* **Baseline Emissions (BE)** — The GHG emissions that would have occurred if the waste were sent to a landfill or dump site (e.g., methane from decomposing organic waste over the modelled decay period).
* **Real Emissions (RE)** — The GHG emissions that occurred during the recycling or [biological treatment](/docs/glossary#biological-treatment) process.
The difference represents the environmental benefit of recycling, measured in metric tons of CO₂-equivalent.
For biological waste (food waste, green waste), GasID calculations require additional complexity because composting involves mixing different waste types. A composting facility operates with a specific mix ratio — for example, 60% food waste and 40% green waste.
To calculate emission reductions from composting:
1. MassIDs for each waste type are combined according to the facility's verified mix ratio.
2. Baseline emissions are calculated using the [UNFCCC CDM Tool 04](https://cdm.unfccc.int/methodologies/PAmethodologies/tools/am-tool-04-v8.0.pdf) methodology for emissions from solid waste disposal sites.
3. Real emissions from composting are calculated using [UNFCCC CDM Tool 13](https://cdm.unfccc.int/methodologies/PAmethodologies/tools/am-tool-13-v2.pdf) for project and leakage emissions from composting.
The result demonstrates the environmental impact: composting 1 ton of food waste mixed with 1 ton of green waste can prevent over 2 tons of CO₂e compared to disposal in a landfill without methane capture.
## How certificates are created [#how-certificates-are-created]
The certificate lifecycle follows a clear sequence:
1. **MassIDs accumulate** — As waste moves through the [supply chain](/docs/protocol/supply-chain), MassIDs are created and validated at each transfer point.
2. **Methodology verification passes** — When MassIDs satisfy all rules defined by a specific methodology — whether a recycling methodology (producing a RecycledID) or a carbon methodology (producing a GasID) — the MassIDs become eligible for certification.
3. **Certificates are created** — The Inventory Manager records each certificate and links it to its parent MassID via the `CertificateRegistry`. The platform records the issuance event, syncing the certificate to its backing MassID, credit type, amount, and methodology context.
4. **Credits are generated** — At the same time, fungible credits are issued in an amount matching the certificate and deposited into the Vault as available inventory for credit purchases.
## Certificate tracking [#certificate-tracking]
Each certificate tracks its available balance as credits are purchased and retired:
* **Total amount** — Set at issuance, immutable. The total environmental impact this certificate represents.
* **Purchased amount** — Incremented when credits backed by this certificate are purchased.
* **Retired amount** — Incremented when purchased credits are permanently retired.
* **Available amount** — Total minus purchased. The credits still available for sale.
This tracking ensures that every credit purchase and retirement can be traced back to a specific certificate, and through that certificate to the underlying MassID and physical recycling work.
[Learn about credits](/docs/protocol/credits) · [Learn about the credit lifecycle](/docs/protocol/credit-lifecycle)
### Diagram: certificate-creation-flow
This certificate creation flow starts with accumulated MassIDs, passes them through dMRV verification, and then splits inside the Vault. Verified material produces RecycledID on the recycling branch and GasID on the emissions branch; those certificate records then support TRC and TCC credit issuance as separate outputs from the same evidence base.
# Credit Lifecycle
## From physical waste to tradeable credits [#from-physical-waste-to-tradeable-credits]
The Carrot Network transforms verified recycling work into environmental assets through a layered registry structure. Each layer builds on the one before it, creating an unbreakable chain of evidence from physical waste to purchasable credits.
The hierarchy has five layers:
1. **[MassID](/docs/protocol/mass-ids)** — A verified batch of waste (material type, weight, chain of custody from [Waste Generator](/docs/protocol/supply-chain) to [Recycler](/docs/protocol/supply-chain#the-role-of-the-recycler)). Implemented as a permanent, non-transferable registry record.
2. **[Certificate](/docs/protocol/certificates)** ([GasID](/docs/protocol/certificates#gasid) or [RecycledID](/docs/protocol/certificates#recycledid)) — Represents a verified environmental outcome when MassIDs pass [methodology](/docs/methodologies) verification at an accredited facility. Implemented as a permanent, non-transferable registry record.
3. **[Credit](/docs/protocol/credits)** — A tradeable unit of verified environmental impact where 1 credit = 1 metric ton. Issued automatically when certificates are created, in a matching amount. Each methodology issues credits under its own credit symbol (e.g. [BOLD Recycling](/docs/methodologies/bold-recycling) issues `C-BIOW`, [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) issues `C-CARB.CH4` for methane). Implemented as a fungible digital unit — issued and transacted in any amount, including fractions.
4. **`CreditPurchaseReceipt`** — A permanent, non-transferable receipt recorded when credits are [purchased](/docs/protocol/credit-purchase). Provides tamper-evident proof that the transaction occurred.
5. **`CreditRetirementReceipt`** — A permanent, non-transferable receipt recorded when credits are [retired](/docs/protocol/credit-retirement). Provides permanent proof that the environmental offset has been claimed.
## How the layers connect [#how-the-layers-connect]
Each layer in the hierarchy references the one below it, creating full traceability:
| Layer | Registry object | Public model | Implementation detail | Transferable? | What it proves |
| --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------- | --------------------- | ------------- | ----------------------------------------------------- |
| Tracking | MassID | Permanent registry record | ERC-721 | No | Physical waste was collected, sorted, and transported |
| Certification | [GasID](/docs/protocol/certificates#gasid) / [RecycledID](/docs/protocol/certificates#recycledid) | Permanent registry record | ERC-721 | No | Environmental impact was verified by dMRV |
| Credit issuance | [TRC](/docs/protocol/credits#tokenized-recycling-credits-trc) / [TCC](/docs/protocol/credits#tokenized-carbon-credits-tcc) (e.g. `C-BIOW`, `C-CARB.CH4`) | Fungible credit | ERC-20 | Yes | 1 credit = 1 metric ton of verified impact |
| Purchase | `CreditPurchaseReceipt` | Permanent registry record | ERC-721 | No | Credits were purchased with USDC payment |
| Retirement | `CreditRetirementReceipt` | Permanent registry record | ERC-721 | No | Credits were permanently destroyed and claimed |
All of these records live on the network's public registry.
## Why are records non-transferable? [#why-are-records-non-transferable]
All MassIDs, certificates, and receipts in the Carrot Network's registry are non-transferable — they cannot be moved between accounts. This is a deliberate design choice:
* **Tamper-proof audit trail** — Since tokens cannot be moved, the provenance chain from waste to credit is permanent and verifiable.
* **No speculative trading** — MassIDs and certificates represent verified physical work, not speculative assets. Preventing transfers ensures they remain tied to their original context.
* **Custody via the [Vault](/docs/protocol/smart-contracts)** — All non-transferable records are held by the Vault, which manages custody on behalf of the network.
Only credits are transferable, because they are the layer designed for market activity — purchasing, holding, and retiring environmental offsets.
## Two credit paths [#two-credit-paths]
The credit lifecycle produces two independent credit types, each representing a different environmental outcome. Each path is driven by a different methodology framework that processes MassIDs independently:
### Recycling path [#recycling-path]
MassID → RecycledID → [Tokenized Recycling Credit (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc)
Proves that waste material was physically recycled. Tokenized Recycling Credits (TRC) use a unit of 1 metric ton of certified recycled material and are issued proportionally to each certificate's verified quantity. The BOLD Recycling methodology issues TRCs with the credit symbol `C-BIOW`; other recycling methodologies may use different symbols. TRCs are material-specific — each TRC represents one certified material stream.
### Carbon path [#carbon-path]
MassID → GasID → [Tokenized Carbon Credit (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc)
Proves that greenhouse gas emissions were reduced by recycling instead of landfilling. Tokenized Carbon Credits (TCC) use a unit of 1 metric ton of CO₂-equivalent emission reductions and are issued proportionally to each GasID certificate's verified quantity. The BOLD Carbon (CH₄) methodology issues TCCs with the credit symbol `C-CARB.CH4` (methane); other carbon methodologies may use different symbols. A carbon methodology calculates the emissions difference between the recycling scenario and the baseline landfill scenario directly from the MassID data.
The same MassID can back both a RecycledID and a GasID, since each certificate is issued by an independent methodology framework — a recycling methodology verifies the physical recycling outcome, while a carbon methodology quantifies the emission reductions.
## End-to-end traceability [#end-to-end-traceability]
The credit lifecycle enables full traceability from retired credit back to physical waste:
**Credit retirement** → `CreditRetirementReceipt` → Credit (e.g. `C-BIOW`, `C-CARB.CH4`) → Certificate (RecycledID or GasID) → MassID → Physical waste batch with chain of custody
This traceability is publicly verifiable through the [Carrot Registry](/docs/protocol/registry) and any blockchain block explorer such as [PolygonScan](https://polygonscan.com/). Any auditor, regulator, or interested party can trace a retired credit back through every layer to the specific waste batches and recycling participants that produced it.
[Learn about certificates](/docs/protocol/certificates) · [Learn about credits](/docs/protocol/credits) · [Learn about purchasing](/docs/protocol/credit-purchase) · [Learn about retirement](/docs/protocol/credit-retirement)
# Credit Purchase
## The credit buyer [#the-credit-buyer]
The Carrot Network is a demand-side market — most of the value comes from credit buyers. Credit buyers are typically organizations — producers, manufacturers, importers, distributors, and their representatives (such as Producer Responsibility Organizations) — but individuals may also purchase credits to offset waste and carbon footprints.
Credit buyers purchase [Tokenized Recycling Credits (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc) and [Tokenized Carbon Credits (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc) to:
* **Meet ESG commitments** — Demonstrate verifiable environmental action to employees, customers, shareholders, and regulators.
* **Comply with EPR mandates** — Extended Producer Responsibility laws increasingly require producers to fund the recovery and recycling of their products and packaging.
* **Offset carbon footprints** — Retire carbon credits to permanently claim the greenhouse gas emission reductions achieved through recycling.
## The purchase flow [#the-purchase-flow]
Credits are purchased **only through Carrot interfaces** — buyers do not purchase directly on the registry. When a buyer uses a Carrot interface (e.g. the [Carrot Store](https://store.carrot.eco) for individuals, or Carrot-provided interfaces for organizations), the platform executes the following atomic settlement flow:
| Step | Action | Description |
| ---- | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1 | **Purchase order signed** | The purchase order is signed with an EIP-712 typed data signature by a key operated by Carrot and registered on the `CreditPurchaseManager` contract as an authorized signer. The buyer authorizes the purchase through the Carrot interface and the payment provider — the buyer does not sign the on-chain order. |
| 2 | **Payment transferred** | USDC is transferred from the payer to the `RewardsVault`, where it becomes available for [rewards distribution](/docs/protocol/rewards-distribution) to participants. |
| 3 | **Certificate updated** | The purchased amounts are recorded on the backing certificates, reducing the available inventory for each allocated certificate. |
| 4 | **Credits settled** | Credits (e.g. `C-BIOW`, `C-CARB.CH4`) are burned directly from the Vault for the retired portion of the order — they never pass through the buyer's account. Any non-retired remainder is transferred from the Vault to the buyer's account. |
| 5 | **Receipt recorded** | A Credit Purchase Receipt is recorded as tamper-evident, public proof of the purchase transaction. |
| 6 | **Rewards recorded** | A Merkle root is committed on-chain for the rewards distribution, enabling participants to claim their share. |
Delivery depends on verified inventory. If matching [certificates](/docs/protocol/certificates) are not yet available for the full order, the purchase may be accepted and held for deferred delivery — the platform re-checks automatically and runs the settlement transaction once inventory exists. An order is delivered in full; a purchase is not partially filled.
Once settled, every purchase and its receipts are publicly verifiable through the [Carrot Registry](/docs/protocol/registry) or any blockchain block explorer (e.g. [PolygonScan](https://polygonscan.com/)).
## Certificate allocation [#certificate-allocation]
Every credit is backed by a certificate — either a RecycledID (for recycling credits) or a GasID (for carbon credits). When a purchase is created, the platform allocates certificates from available inventory to fulfill the order. Certificates are allocated to spread each sale across as many distinct reward participants as possible — every allocation round advances the certificate whose participants have earned the least so far, in bands of value. Certificate age is used only as a tiebreak and to sweep any remainder.
A single purchase may span multiple certificates if no single certificate has enough available balance to fill the order. The purchase receipt records each certificate allocation, maintaining a clear audit trail from purchased credits back to the underlying verified recycling work and [MassIDs](/docs/protocol/mass-ids).
## Integrated retirement [#integrated-retirement]
Buyers can purchase and retire credits in a **single atomic transaction**. Where the purchase order carries a positive retirement amount for an allocation, that portion is bought and immediately, permanently destroyed within the same on-chain operation. Both a **Credit Purchase Receipt** and a **Credit Retirement Receipt** are recorded in the same transaction.
This is the most common path for compliance buyers — organizations and individuals that need to claim the environmental offset immediately upon purchase. It simplifies the process to a single step and reduces transaction costs.
The registry contracts also support standalone retirement as a separate transaction, for buyers who hold credits and retire them later. See [Credit Retirement](/docs/protocol/credit-retirement) for details on both retirement paths.
## Fiat payment methods [#fiat-payment-methods]
The Carrot Network recognizes that many credit buyers lack blockchain infrastructure. To address this, the platform supports **fiat payment methods** for buyers that prefer traditional payment flows. The methods available depend on the buyer's region and are shown at checkout, and the set expands as new payment rails are added. The platform handles the conversion so that settlement always occurs in USDC, regardless of how the buyer pays.
***
[Credits](/docs/protocol/credits) · [Rewards Distribution](/docs/protocol/rewards-distribution) · [Smart Contracts](/docs/protocol/smart-contracts) · [Credit Retirement](/docs/protocol/credit-retirement)
### Diagram: credit-purchase-flow
This purchase flow groups the buyer, the registry's automated settlement layer, and its public records into a six-step transaction: order signed, USDC transferred, certificate updated, credits settled, receipt recorded, and rewards recorded across all three tiers. The atomic transaction annotation explains the takeaway: the purchase either completes every state change together or reverts without partial settlement.
# Credit Retirement
## What is credit retirement? [#what-is-credit-retirement]
Credit retirement is the act of permanently removing environmental credits from circulation to claim the offset they represent. When a [Tokenized Recycling Credit (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc) or [Tokenized Carbon Credit (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc) is retired, the credit is permanently destroyed on the public registry and can never be re-sold, re-used, or double-counted.
Retirement is what transforms a tradeable financial asset into a permanent environmental claim. Until credits are retired, they represent available inventory. After retirement, they represent claimed impact — recorded permanently on the network's immutable public registry and viewable through the [Carrot Registry](/docs/protocol/registry) or any public on-chain explorer.
## Two retirement paths [#two-retirement-paths]
The Carrot Network supports two methods for retiring credits:
### Standalone retirement [#standalone-retirement]
The registry contracts support retiring credits held against a buyer's balance at any time after purchase — useful for buyers that acquire credits in advance and retire them according to their own reporting schedules.
1. The holder requests retirement through a Carrot interface. The retirement order — naming the [certificates](/docs/protocol/certificates) and the amounts to retire — is signed by a key registered on the registry contracts as an authorized signer, and any relayer can then submit it. Authorization comes from that signature, not from the holder's own wallet.
2. The credits are permanently destroyed from the [Vault's](/docs/protocol/smart-contracts) custodial balance, against the holder's recorded entitlement. Credits already delivered to an external account must be returned to the Vault first.
3. The backing certificate's retirement amount is updated.
4. A Credit Retirement Receipt is recorded as permanent proof.
5. The retirement is recorded on the public registry.
### Integrated retirement [#integrated-retirement]
Credits are purchased and retired in a single atomic transaction. This is the most common path for buyers that know they want to claim the offset immediately upon purchase.
1. A [purchase order](/docs/protocol/credit-purchase) is signed by a key registered on the registry contracts as an authorized signer. The order carries a retirement amount for each certificate allocation, plus retirement metadata (beneficiary, receipt id, metadata URI). The amounts are what retire credits and how much: where they are positive, that portion is burned and the retirement receipt is recorded; the metadata identifies that receipt.
2. USDC payment is transferred to the `RewardsVault` for [rewards distribution](/docs/protocol/rewards-distribution).
3. **Credits are destroyed** directly from the Vault — they never pass through the buyer's account. Where only part of a purchase is retired, the remainder is transferred from the Vault to the buyer.
4. Both a Credit Purchase Receipt and a Credit Retirement Receipt are recorded in the same transaction.
5. The retirement is recorded on the public registry.
Integrated retirement is the recommended path for most buyers, as it simplifies the process and reduces the number of transactions.
## The retirement receipt [#the-retirement-receipt]
Every retirement produces a `CreditRetirementReceipt` — a permanent, non-transferable record that serves as public proof. The receipt records:
* **Credit type** — Whether TRC (e.g. `C-BIOW`) or TCC (e.g. `C-CARB.CH4`) was retired
* **Amount** — The quantity of credits retired (in metric tons)
* **Credit holder** — The account address the retired credits were held against
* **Beneficiary** — The identifier of the party the retirement is claimed for, which may be the holder or someone they designate
* **Timestamp** — The registry timestamp when retirement occurred
* **Certificate references** — Links to the backing certificates ([GasID](/docs/protocol/certificates#gasid) or [RecycledID](/docs/protocol/certificates#recycledid))
* **[MassID](/docs/protocol/mass-ids) references** — Links to the underlying waste batches
Because the receipt is non-transferable, it cannot be moved. It is permanently held by the Vault and remains publicly associated with the credit holder's account address and the beneficiary's identifier — and the retirement it records, the credits burned and the certificates behind them, cannot be undone.
## Why retirement matters [#why-retirement-matters]
Retirement solves a critical problem in environmental markets: **double counting**. In traditional carbon and recycling offset markets, the same credit can be sold multiple times or claimed by multiple parties because there is no definitive mechanism to mark a credit as used.
In the Carrot Network, retirement is irreversible. Destroyed credits cannot be recreated, and the public retirement receipt provides unambiguous proof of who claimed the offset. That proof does not depend on Carrot's own systems — any retirement can also be verified independently through a public block explorer (e.g. [PolygonScan](https://polygonscan.com/)). This makes Carrot credits suitable for regulatory compliance where auditability and non-duplication are mandatory.
## EPR and ESG compliance [#epr-and-esg-compliance]
Retirement receipts are the primary evidence for regulatory and voluntary reporting:
* **Extended Producer Responsibility (EPR)** — Producers retire TRCs matching their waste footprint (e.g., 50 metric tons of TRCs from one certified material stream to offset 50 metric tons of that material placed on the market). Because credits inherit geographic traceability from MassIDs, retirements can satisfy location-specific mandates.
* **ESG reporting** — Organizations reference their retirement receipts in sustainability reports, demonstrating that commitments are backed by verified, permanently claimed recycling work.
[Learn about purchasing credits](/docs/protocol/credit-purchase) · [Learn about certificates](/docs/protocol/certificates) · [View the Registry](https://registry.carrot.eco)
# Credits
## What are credits? [#what-are-credits]
Credits are the tradeable units of verified environmental impact at the end of the Carrot Network's [credit lifecycle](/docs/protocol/credit-lifecycle). Each credit represents **1 metric ton** of verified impact — either recycled material or greenhouse gas emission reductions. On the network's public registry, credits are fungible digital units with decimal precision: they can be issued, held, transferred, purchased, and retired in any amount, including fractions.
Credits are the mechanism through which the environmental work performed by [recycling participants](/docs/protocol/supply-chain) becomes a commodity that organizations and individuals can purchase to offset their waste and carbon footprints.
## Credit types [#credit-types]
The Carrot Network supports two **categories** of environmental credits. Each category can have multiple credit symbols, depending on which methodology issued the credits:
| Category | Description | Example symbol | Issued by | Unit |
| -------------------------------- | ----------------------------------------- | -------------- | ------------------------------------------------------------------------ | ------------------------------------------------------ |
| Tokenized Recycling Credit (TRC) | Certified recycled material | `C-BIOW` | [BOLD Recycling](/docs/methodologies/bold-recycling) | 1 credit = 1 metric ton of certified recycled material |
| Tokenized Carbon Credit (TCC) | Greenhouse gas emission reductions (CO₂e) | `C-CARB.CH4` | [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) (methane) | 1 credit = 1 metric ton of CO₂e reductions |
Not all TRC are `C-BIOW` — `C-BIOW` is the credit issued by the BOLD Recycling methodology. Other recycling methodologies could issue TRCs with different credit symbols. Similarly, not all TCC are `C-CARB.CH4` — `C-CARB.CH4` is the methane credit issued by the BOLD Carbon (CH₄) methodology; other carbon methodologies could issue TCCs with different symbols.
### Tokenized Recycling Credits (TRC) [#tokenized-recycling-credits-trc]
TRCs represent certified recycled waste. When [MassIDs](/docs/protocol/mass-ids) of a specific material type pass verification under a **recycling methodology** at an accredited facility, [RecycledID](/docs/protocol/certificates#recycledid) certificates are created and credits are issued in a matching amount. The [BOLD Recycling](/docs/methodologies/bold-recycling) methodology issues TRCs with the credit symbol `C-BIOW`. Because MassIDs record the source location of waste creation, TRCs can be traced to specific municipalities — making them a tool for demonstrating compliance with Extended Producer Responsibility (EPR) mandates.
TRCs are material-specific — each TRC represents one certified material stream. This granularity allows credit buyers to target the waste streams that match their product footprints.
### Tokenized Carbon Credits (TCC) [#tokenized-carbon-credits-tcc]
TCCs represent greenhouse gas emission reductions achieved through waste diversion or biological treatment. They are backed by [GasID](/docs/protocol/certificates#gasid) certificates, which are generated directly from MassIDs by a carbon methodology — independently of RecycledIDs and TRCs. The emission reductions are calculated by comparing the diversion or treatment outcome to the baseline disposal scenario (what would have happened if the waste went to a landfill or dump). The [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) methodology issues TCCs with the credit symbol `C-CARB.CH4` (methane reductions through composting). Other carbon methodologies could issue TCCs with different symbols.
TCCs are particularly valuable for biological waste recycling. Composting food waste and green waste prevents the methane emissions that would otherwise occur over 20 years of landfill decomposition. The [UNFCCC Clean Development Mechanism](https://unfccc.int/process-and-meetings/the-kyoto-protocol/mechanisms-under-the-kyoto-protocol/the-clean-development-mechanism) methodologies used to quantify these emission reductions demonstrate that composting 2 tons of organic waste can deliver over 2 tons of CO₂e in emission reductions compared to landfill disposal.
## Credit lifecycle [#credit-lifecycle]
Credits follow a clear lifecycle from issuance to retirement:
1. **Issued** — When a certificate is created by the `InventoryManager`, credits are issued in a matching amount and deposited into the [Vault](/docs/protocol/smart-contracts).
2. **Held** — Credits remain in the Vault as available inventory until purchased.
3. **Purchased** — When a buyer [purchases credits](/docs/protocol/credit-purchase), payment (in USDC) is sent to the `RewardsVault` for distribution to participants, and a `CreditPurchaseReceipt` is recorded as tamper-evident proof of the transaction.
4. **Retired, at settlement or later** — Retirement destroys the credits in the Vault and records a `CreditRetirementReceipt` as proof. It happens either in the same transaction as the purchase, or later against a balance delivered to the buyer's account. Retired credits cannot be re-sold or re-used.
## Why credits are fungible [#why-credits-are-fungible]
MassIDs and certificates each represent unique batches or outcomes; credits, by contrast, are fungible by design. Every credit of a given symbol (e.g. `C-BIOW`) represents the same unit — 1 metric ton of certified recycled material for that methodology — regardless of which specific MassIDs back it.
This fungibility is what makes credits tradeable as commodities. Buyers don't need to evaluate individual waste batches; they purchase standardized units of environmental impact. At the same time, the full provenance chain is preserved: every credit can be traced back through its certificate to the underlying MassIDs, providing full transparency for auditors and regulators.
## Credits and EPR compliance [#credits-and-epr-compliance]
Because MassIDs record the geographic origin of waste, credits inherit this traceability. A company operating in Brazil can purchase TRCs specifically backed by waste collected in Brazilian municipalities, demonstrating compliance with local EPR regulations. This location-specific traceability distinguishes Carrot credits from generic environmental offsets and makes them directly applicable to regulatory compliance.
[Learn about purchasing credits](/docs/protocol/credit-purchase) · [Learn about certificates](/docs/protocol/certificates) · [Learn about the credit lifecycle](/docs/protocol/credit-lifecycle)
# MassIDs
## What is a MassID? [#what-is-a-massid]
A MassID represents a verified batch of environmental materials in the Carrot Network — the foundational registry record for the digital MRV ([dMRV](/docs/protocol/dmrv)) process. Once issued to the network's public registry, each MassID is a non-transferable, tamper-evident record held by the [Vault](/docs/protocol/smart-contracts). A network operator can revoke a MassID when its underlying data is later invalidated; revocation is blocked once [credits](/docs/protocol/credits) from its [certificates](/docs/protocol/certificates) have been sold, and the linked certificates have to be revoked first.
When any amount of post-consumer or post-industrial waste is identified, measured, and custody is established between two parties, a MassID is recorded on the Carrot platform's immutable ledger. It is tokenized on the public registry only after it passes dMRV verification (see below). It records three core properties:
* **Material type** — What the waste is (e.g., clear glass, organic food waste, mixed plastics)
* **Weight** — How much there is (in kilograms)
* **Chain of custody** — Every participant who has handled the material, from source to recycling
MassID metadata is stored on [IPFS](https://ipfs.tech/) — the InterPlanetary File System — where content addressing makes it tamper-evident and publicly verifiable; continued availability depends on active pinning. The registry reference links that metadata to each waste batch and its journey through the [recycling supply chain](/docs/protocol/supply-chain).
## Chain of custody [#chain-of-custody]
The chain of custody recorded in each MassID tracks every participant who handles the material. Participants fall into six role categories:
| Role | Key | Description |
| ---------------------- | --- | ---------------------------------------------------------------------------------------- |
| **Waste Generator** | G | The person or business that produces the waste |
| **Bin Custodian** | BC | Manages collection bins or drop-off points |
| **Hauler** | H | Transports waste between locations |
| **Processor** | P | Sorts, accumulates, or pre-processes materials |
| **Recycler** | R | Performs the final recycling or biological treatment |
| **Network Integrator** | I | The [software platform](/docs/protocol/network-integrators) that digitizes the logistics |
Each role category can include multiple participants. For example, a glass recycling chain might involve two [haulers](/docs/protocol/supply-chain) (local collection and long-distance transport) and two [processors](/docs/protocol/supply-chain) (local accumulation center and the glass bottling plant).
The public record proves the chain without exposing the people in it. Every participant in the chain of custody is recorded under a stable participant identifier, and the MassID record carries only that identifier — as a non-reversible hash — alongside the participant's role, never a name or a blockchain address. Locations are published at city level, with coordinates rounded to roughly 0.1 degrees. Elsewhere on the network, such as reward tables and participant profiles, Processors, [Recyclers](/docs/protocol/supply-chain#the-role-of-the-recycler) and [Network Integrators](/docs/protocol/network-integrators) may be named when the organization has a public profile; [Waste Generators](/docs/protocol/supply-chain), Haulers and [Bin Custodians](/docs/protocol/supply-chain) are withheld by default and are not named there.
Rewards are linked to participants through that same identifier. Each participant is eligible for a share of the proceeds when credits generated from that MassID are sold.
## How MassIDs are created [#how-massids-are-created]
MassIDs are generated in three main scenarios:
### 1. Bin drop-off [#1-bin-drop-off]
When a user drops waste at a collection point. If the product can be uniquely identified (via QR code, barcode, or AI recognition), MassIDs are created matching the waste composition of that product.
### 2. Waste pick-up [#2-waste-pick-up]
When a hauler collects waste from a generator. The graduated precision model incentivizes weighing at source: generators who weigh at pick-up receive more accurate credit attribution and, in [Pay-As-You-Throw](/docs/protocol/the-solution#payt) programs, lower bills.
Four scenarios apply depending on the level of data available:
* **Weighed at pick-up** — MassID created with exact material type and weight
* **Source-identified but weighed at drop-off** — MassID created at drop-off with the generator recorded as the source
* **Mixed route without source weighing** — All generators on the route receive equal distribution of MassIDs based on what was validated at the drop-off facility
* **No weighing, bin identified** — Weight estimated based on bin type and validated averages
### 3. Drop-off at processors and recyclers [#3-drop-off-at-processors-and-recyclers]
When waste arrives at a facility, the validator confirms the material content (type and weight). MassIDs in the facility's inventory are managed on a **First-In-First-Out (FIFO)** basis — the earliest MassIDs are processed and credited first.
## Submission window [#submission-window]
Data can — and should — reach the network as the operation happens: a batch recycled today can be submitted today. What follows is a deadline, not the opening of a window.
### The methodology framework sets the outer limit [#the-methodology-framework-sets-the-outer-limit]
Both [methodology frameworks](/docs/standard/concepts/mvf) accept a batch only when its Recycled event occurred **on or after 1 January of the previous calendar year, in UTC** — the allowable project period, published as **Project period** under [BOLD Recycling key parameters](/docs/methodologies/bold-recycling/framework#key-parameters) and [BOLD Carbon (CH₄) key parameters](/docs/methodologies/ams-iii-f/bold-carbon#key-parameters). A MassID outside that period fails methodology verification and generates no credit, whenever it was sent.
So the year the material was recycled is what decides which cycle is its last. The boundary is evaluated on the event's UTC timestamp, so a Recycled event registered on 31 December at or after 21:00 Brasilia time already counts as the following year:
| Recycled in (UTC) | Last cycle that can analyze it | Data must reach the network by |
| ----------------- | ------------------------------ | ------------------------------ |
| 2025 | 2026 | 30 November 2026 |
| 2026 | 2027 | 30 November 2027 |
| 2027 | 2028 | 30 November 2028 |
### How each cycle closes [#how-each-cycle-closes]
* **Until 30 November, 23:59 (UTC-3, Brasilia time)** — mass data and the required supporting documentation must reach the network to be analyzed in that year's cycle.
* **From 1 to 15 December** — the period reserved for [methodology verification](/docs/standard/concepts/lifecycle), the third-party assurance work around it, and the resulting adjustments, followed by the issuance of the approved cases. Corrections requested for submissions received within the deadline are still accepted during this period.
The window exists because verification, the assurance work that supports it, and any adjustments they require need time between the data cut-off and the close of the cycle.
15 December is the target closing date for the cycle, not a guarantee of issuance: a MassID only generates a credit when its documentation is complete and it passes methodology verification.
Submissions received after 30 November — and cases still pending when the cycle closes — are assessed in the following cycle whenever the allowable project period still covers them. A batch already in its last eligible year has no following cycle: once the year turns, its Recycled event falls outside that period.
Eligibility follows the **date of the Recycled event**, not the date the data was sent. Sending
within the deadline does not make a batch eligible when its Recycled event falls outside the
allowable project period, and the deadline does not change how a credit's vintage is determined.
## Proof of Physical Work and Provenance [#proof-of-physical-work-and-provenance]
MassIDs provide two forms of verifiable proof:
* **Proof-of-Provenance** — The chain of custody establishes where the waste came from and who handled it at every stage, creating a traceable path from source to recycling.
* **Proof-of-Physical-Work** — Each supply chain event recorded in the MassID (pick-up, drop-off, sorting, recycling confirmation) constitutes evidence that real physical work was performed — waste was collected, transported, sorted, and recycled.
Together, these proofs form the basis for the dMRV process that leads to credit generation. Only MassIDs that reach a certified recycling or biological treatment facility, with validated chain of custody at each point, become eligible for generating credits.
This registry record is the foundational technology enabling the [**Recycle-to-Earn**](/docs/glossary#recycle-to-earn) model — where every verified participant in the recycling supply chain receives rewards proportional to their contribution.
After a MassID passes all verification checks and is eligible for generating a Certificate, it is [recorded on the public registry](/docs/protocol/on-chain-minting) — its content-addressed metadata is stored on IPFS, with availability dependent on continued pinning, and the MassID reference is written to the registry.
[Learn about dMRV verification](/docs/protocol/dmrv) · [Explore the credit lifecycle](/docs/protocol/credit-lifecycle)
### Diagram: massid-lifecycle
This MassID lifecycle follows events from pick-up, transport manifest, weighing, sorting, drop-off, recycling manifest, and biological treatment completion into MassID audit and auditable methodology outputs. Swimlanes identify generator or hauler, processor or recycler, integrator, and Carrot Platform roles; colored rule badges show structure, methodology, and audit checks accumulating before approval.
# Registry Record Creation
## From verified data to public registry records [#from-verified-data-to-public-registry-records]
After a [MassID](/docs/protocol/mass-ids) passes [methodology verification](/docs/protocol/methodology-execution), it is issued as a registry record — transformed from a platform-held verified record into a tamper-evident, publicly verifiable entry on the public registry. Issuance creates a publicly verifiable link between the physical recycling work and its digital representation in the registry.
Registry issuance is the bridge between the digital MRV ([dMRV](/docs/protocol/dmrv)) verification process and the [credit lifecycle](/docs/protocol/credit-lifecycle) that ultimately produces tradeable environmental credits.
## The registry-record creation process [#the-registry-record-creation-process]
### 1. Verification complete [#1-verification-complete]
The MassID has passed all [methodology](/docs/methodologies) checks. Its material type, weight, and chain of custody are validated, and all compliance conditions defined by the applicable methodology are satisfied. The MassID is marked as ready for registry recording.
### 2. Metadata creation [#2-metadata-creation]
Structured metadata is compiled for the MassID. This metadata captures the complete provenance record:
| Field | Description |
| -------------------- | ---------------------------------------------------------------------------------------------------- |
| **Material type** | The waste material classification (e.g., clear glass, plastic, organic food waste) |
| **Weight** | The verified weight in kilograms |
| **Chain of custody** | Every participant who handled the material, identified by a non-reversible participant hash and role |
| **Timestamps** | When each event in the chain of custody occurred |
This metadata becomes the content-addressed description referenced by the MassID's registry record. The methodology that verified the material — its name, version, and a link to the published specification — and a reference to the verification are pinned on the certificate issued from this MassID, which references the MassID by token id and IPFS URI. The rule results, the review decisions and their inputs stay platform-held and are reflected in the Carrot Registry.
### 3. Decentralized storage [#3-decentralized-storage]
The compiled metadata is uploaded to [IPFS](https://ipfs.tech/) (InterPlanetary File System), producing a content-addressed URI. This URI is unique to the metadata content — any change to the data would produce a different URI, making the stored record tamper-evident.
The IPFS URI is then referenced by the on-chain registry record, linking the lightweight blockchain entry to the full metadata stored in decentralized storage.
### 4. Registry record creation [#4-registry-record-creation]
The MassID is recorded on-chain as a non-transferable registry record held by the [Vault](/docs/protocol/smart-contracts) contract. The implementation uses ERC-721, while the public model is the MassID record itself. The creation transaction records the IPFS metadata URI on-chain, associating the registry entry with its provenance data. Because the metadata is content-addressed, that association is tamper-evident: any later change to the on-chain reference emits a public event, so the record is auditable rather than silently editable.
A registry record can also be revoked. A network operator can revoke a MassID when its underlying data is later found to be invalid, which replaces its metadata reference with a revocation record and removes the token from the Vault. Revocation is blocked once credits from the MassID's [certificates](/docs/protocol/certificates) have been sold, and it does not cascade — the linked certificates have to be revoked first.
Because MassID records are non-transferable, they cannot be traded or moved between accounts. This ensures the provenance chain remains intact and prevents speculative activity on verification records.
### 5. Record linking [#5-record-linking]
The platform updates its internal records to connect the verified MassID with its on-chain registry-record ID. This linkage ensures that the platform, the blockchain, and the [Carrot Registry](/docs/protocol/registry) all reference the same underlying data — creating a consistent, auditable record across systems.
IPFS (InterPlanetary File System) is a decentralized storage network where files are addressed by their content hash rather than by location. This provides two important properties for recorded MassIDs:
* **Tamper evidence** — The content-addressed URI is derived from the metadata itself. If anyone altered the metadata after upload, the URI would change, immediately revealing the change. The on-chain reference therefore identifies exactly the metadata it points at, and any change to that reference is itself published as a public event.
* **Distributed availability** — Metadata is not tied to a single server or organization, but it remains accessible only while at least one node actively pins it. Continued pinning is therefore part of the network's durability controls.
Together, these properties make the metadata backing every recorded MassID tamper-evident and independently verifiable, while the registry preserves an auditable reference — a critical requirement for environmental credits that must withstand regulatory scrutiny.
## What happens next [#what-happens-next]
Recorded MassIDs are the foundation upon which the rest of the credit lifecycle is built. Once a MassID exists on the public registry:
* **Certificates are generated** — When MassIDs pass methodology verification at a facility accredited by independent third-party auditors, certificates (RecycledID or GasID) are recorded, referencing the underlying MassID records as proof of the physical work performed.
* **Credits are issued** — Each certificate generates fungible [credits](/docs/protocol/credits) (TRC or TCC), using the unit defined by its methodology. These credits are the tradeable units that buyers purchase to meet their environmental commitments.
* **Full traceability is established** — From a retired credit, any party can trace back through the certificate, to the recorded MassID, to the IPFS metadata, and ultimately to the specific waste batches and supply chain participants that performed the work. This traceability is publicly verifiable through the [Carrot Registry](/docs/protocol/registry) or any blockchain block explorer (e.g. [PolygonScan](https://polygonscan.com/)).
## Related pages [#related-pages]
* [Credit Lifecycle](/docs/protocol/credit-lifecycle) — The MassID, Certificate, and Credit lifecycle and relationships
* [Smart Contracts](/docs/protocol/smart-contracts) — The on-chain infrastructure that manages registry-record creation and custody
* [MassIDs](/docs/protocol/mass-ids) — The foundational data unit representing verified waste batches
# dMRV
## What is dMRV? [#what-is-dmrv]
digital MRV (dMRV) is the end-to-end process for executing approved methodology framework criteria — from data capture through evidence recording to credit generation. It provides the data, tools, and audit trails that enable independent, third-party [validation and verification bodies (VVBs)](/docs/glossary#vvb) to perform scalable assurance over recycling and carbon credits.
Traditional MRV relies on manual audits, paper receipts, and third-party certification that takes 3–5 years and costs US$250–500K per project. Carrot's dMRV turns the operational workflow into reviewable evidence — from data capture at the point of waste generation through methodology execution to credit generation — making verification more continuous, transparent, and scalable while preserving the role of external assurance.
The dMRV system is the foundation for the [Carrot Network's](/docs/network) environmental credit markets, covering both [Tokenized Recycling Credits (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc) and [Tokenized Carbon Credits (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc).
## How verification works [#how-verification-works]
Carrot orchestrates dMRV execution by running approved methodology framework criteria against
supply chain data and recording auditable outcomes. Carrot does not create methodologies,
verification frameworks, or dMRV applications. It approves methodologies, frameworks, and
third-party applications for use on the Carrot Network. Independent third-party verifiers provide
assurance over the evidence and governance process when applicable.
The dMRV process follows a defined workflow:
1. **Data capture** — [Network Integrators](/docs/protocol/network-integrators) connect waste logistics and management applications to the Carrot Network, submitting [supply chain](/docs/protocol/supply-chain) events (hauling, sorting, recycling) as they occur.
2. **Waste codification** — Each batch of waste material is codified into a [MassID](/docs/protocol/mass-ids), creating a digital record of material type, weight, and provenance. MassIDs are updated through supply chain events as materials move through the supply chain.
3. **Chain of custody** — Every transfer and transformation is recorded in the MassID, establishing an unbroken chain of custody from waste source to certified [Recycler](/docs/protocol/supply-chain#the-role-of-the-recycler). This constitutes **Proof-of-Physical-Work** — verifiable evidence that the physical work of collecting, sorting, hauling, and recycling occurred.
4. **Methodology verification** — Each [methodology](/docs/methodologies) is translated into a [Methodology Verification Framework (MvF)](/docs/standard/concepts/mvf) — the specification defining rules and calculations — and implemented as a [Methodology Verification Application (MvA)](/docs/standard/concepts/mva) that automates verification. These applications confirm that supply chain data meets the methodology's requirements.
A rule can pass, fail, or return an indeterminate result. An indeterminate result pauses the
verification run and routes the rule to a recorded human decision — the reviewer approves or
rejects it with a written justification, and the decision is kept with the run. See
[Methodology Execution](/docs/protocol/methodology-execution) for how the review stage works
and what happens when it is not resolved.
5. **Credit generation** — MassIDs that pass verification under a specific methodology generate [Certificates](/docs/protocol/certificates) ([GasID](/docs/protocol/certificates#gasid) for carbon emission reductions, [RecycledID](/docs/protocol/certificates#recycledid) for recycling), which in turn issue fungible credits (TCC and TRC). Each methodology issues credits under its own registry symbol (e.g. [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) issues `C-CARB.CH4`, [BOLD Recycling](/docs/methodologies/bold-recycling) issues `C-BIOW`).
6. **Public verifiability** — Registry records — from issuance through [credit retirement](/docs/protocol/credit-retirement) — are viewable through the [Carrot Registry](/docs/protocol/registry) or, independently of Carrot, through any [public blockchain explorer](/docs/glossary#blockchain-block-explorer). Auditors, credit buyers, regulators, or anyone else can verify the records for themselves.
For technical details on how methodology rules execute, see [Methodology Execution](/docs/protocol/methodology-execution).
## Validators and supply chain events [#validators-and-supply-chain-events]
Material transfers in the recycling supply chain always occur between two parties: a holder and a receiver. The **receiver** acts as the [Validator](/docs/glossary#validator), confirming material content (weight, quality, source) and updating the MassID through each logistics operation. The holder retains access to the validation data and can contest it.
Supply chain data includes pick-ups, drop-offs, weighing, sorting, and recycling confirmations. At each material transfer, the receiver acts as Validator and updates the MassID chain of custody, contributing to the Proof-of-Physical-Work record. For the full list of event types and how they are validated, see the [Event Specification](/docs/integrations/reference/event-specification) and the methodology rules (e.g. [BOLD Recycling rules](/docs/methodologies/bold-recycling/framework/application/application-rules)).
## Proof-of-Authority [#proof-of-authority]
Proof-of-Authority (PoA) is the mechanism that ensures data integrity and trust across the Carrot Network. It operates on three levels: economic self-policing among participants, facility accreditation conducted by independent third-party auditors, and network oversight provided by the [Carrot Foundation](/docs/network/the-foundation).
### Self-policing through economic incentives [#self-policing-through-economic-incentives]
Because economic rewards are tied to validated waste tracking and credit generation, every participant has a financial interest in maintaining data accuracy. If a MassID is flagged for suspicious activity or inaccurate data, it is disqualified from generating credits — and **all participants** linked to that MassID suffer the financial loss. This creates natural self-policing throughout the supply chain.
Since logistics operations in the middle and end of the supply chain are typically paid on a weight basis, the reliability of weight data becomes inherently high. Recyclers either purchase materials or charge for services by weight, creating economic alignment with data accuracy.
### Facility accreditation [#facility-accreditation]
Recyclers must be accredited through a **third-party audit** before they can participate in credit generation. These independent auditors evaluate facility operations, processing capacity, and material handling to ensure the facility meets methodology requirements. Carrot does not perform this accreditation — it is conducted by external auditing bodies.
### Network oversight [#network-oversight]
The Carrot Foundation provides an additional layer of trust through network-level oversight. Foundation oversight authority includes:
* **Suspending** participants who attempt to manipulate data — all MassIDs in that participant's chain of custody are excluded from generating credits
* **Requesting information** from any participant in the chain — failure to respond can result in permanent exclusion
* **Permanently disqualifying** confirmed fraud cases, with prior-issued credits frozen until resolved
Oversight tools include waste transfer manifests, material purchase receipts, and historical performance data that tracks variations in waste volumes and transit times.
## Anomaly Detection (CaE) [#anomaly-detection-cae]
The [Carrot Analytic Engine (CaE)](/docs/glossary#cae) is the evaluation layer of the verification stack — a machine-learning layer designed to analyze dMRV data and detect anomalies, inconsistencies, and suspicious patterns in supply chain data. When the CaE flags irregularities, the platform can route events for additional review or pause credit issuance. Today, credit issuance is gated by methodology rule results: a rule the code decides against blocks issuance, and a rule that returns an indeterminate result pauses the run for a recorded human decision. See [Methodology Ecosystem](/docs/standard/concepts/ecosystem#platform-intelligence-layers) for details.
## Methodology Advisory (CaA) [#methodology-advisory-caa]
The [Carrot Agentic Advisor (CaA)](/docs/glossary#caa) is an AI layer that identifies opportunities for methodology, data quality, and process improvements across the ecosystem. See [Methodology Ecosystem](/docs/standard/concepts/ecosystem#platform-intelligence-layers) for details.
## Why dMRV matters [#why-dmrv-matters]
Traditional environmental credit markets suffer from persistent trust problems: double counting, unverified claims, and opaque registries. Physical waste, unlike carbon emissions, is tangible and measurable — but without a digital verification system, waste-based credits face the same trust challenges. In traditional verification, a VVB agent typically analyzes approximately 2% of project data through periodic manual audits. The dMRV infrastructure verifies 100% of data related to each MassID and certificate, enabling VVBs to perform more thorough and continuous verification.
dMRV solves this by digitizing the entire verification process — executing methodology rules against supply chain data and recording verified outcomes on the public registry. The result is environmental credits backed by verifiable physical outcomes rather than estimates, projections, or paper receipts.
[Learn about certificates](/docs/protocol/certificates) · [Explore the supply chain](/docs/protocol/supply-chain)
### Diagram: dmrv-process-flow
The dMRV process flow groups Carrot's data layer and verification layer into two stacked subflows. Data capture, waste codification, and chain-of-custody record evidence on the data layer; methodology verification, certificate issuance, and credit creation consume that evidence on the verification layer. A single bridge edge marks the transition from collected evidence to verified credit.
# Methodology Execution
## Overview [#overview]
[Methodologies](/docs/methodologies) define the scientific basis for environmental credit generation. Each methodology is translated into a [methodology framework (MvF)](/docs/standard/concepts/mvf) — the specification of rules, triggers, and verification criteria — and implemented as a [Methodology Verification Application (MvA)](/docs/standard/concepts/mva) that executes those rules on the platform under that framework. The platform receives structured data from [Network Integrators](/docs/protocol/network-integrators), processes it through the MvA against the methodology framework's rules, and produces verified outcomes — [MassIDs](/docs/protocol/mass-ids) and [certificates](/docs/protocol/certificates) that become the foundation for credits issued on the public registry.
This page explains the end-to-end execution pipeline: how data enters the platform, how it is processed, and how verified outcomes are produced. Rule execution and results are persisted after each rule and reported in real time in the [Carrot Registry](/docs/protocol/registry) ([registry.carrot.eco](https://registry.carrot.eco)).
## How data enters the platform [#how-data-enters-the-platform]
Network Integrators submit supply chain data via the [Carrot API](/docs/integrations/api). This data describes the physical events occurring across the [recycling supply chain](/docs/protocol/supply-chain):
| Data type | Description |
| -------------------------- | ------------------------------------------------------------------------------------------------------- |
| **Waste movements** | Pick-ups and drop-offs — material type, weight, and the participants involved |
| **Environmental outcomes** | Recycling and biological treatment confirmations, including certified quantities and processing methods |
Facility accreditation is not part of what integrators submit. Accreditation records — and the
third-party on-site facility verification behind them — are maintained by Carrot in the
accreditation layer, and the verification pipeline reads them when it evaluates a MassID. Integrator
submissions cover waste movements and environmental outcomes.
Each submission is stored as a **versioned record** that captures the state of the data at a specific point in time. Recorded data is **immutable** — it cannot be altered or deleted, only extended with new events or versions. Every change to supply chain data is traceable, creating a complete audit trail from initial submission through final verification.
## Processing and verification [#processing-and-verification]
When new data arrives, the platform processes it through a structured pipeline:
1. **Document recognition** — The platform identifies the type of incoming data (waste movement, audit report, issuance event) and routes it for appropriate processing.
2. **Entity synchronization** — Relevant entities — MassIDs, certificates, and participant records — are updated to reflect what happened in the physical world. For example, a drop-off event updates the MassID's chain of custody to include the receiving facility.
3. **Trigger evaluation** — The platform checks whether any methodology triggers apply to the incoming data. If a trigger condition is met, the corresponding methodology framework rules are queued for execution by the MvA.
## Methodology triggers [#methodology-triggers]
Each methodology framework (MvF) defines **triggers** — conditions on incoming data that, when matched, cause rules to execute. Triggers connect real-world events to the verification logic that produces environmental outcomes. The exact trigger conditions are defined per framework; see the [methodology catalog](/docs/methodologies) for each framework's behavior.
Trigger conditions are document- and event-driven. Both published frameworks use the same one:
* **MassID audit** — When a MassID's audit document is opened under a methodology, the platform runs that framework's MassID validation rules against the submitted supply chain events. When all those rules pass, certificate issuance is triggered (e.g. RecycledID or GasID under [BOLD Recycling](/docs/methodologies/bold-recycling) or [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon)).
Triggers ensure that rules only run when relevant data changes, keeping execution efficient and predictable.
## Rule execution [#rule-execution]
When a trigger fires, the platform executes the methodology framework's rules via the MvA in a defined sequence. After each rule runs, its result is persisted and made available in real time in the Carrot Registry.
### 1. Prepare [#1-prepare]
The platform determines which rules apply to the triggered scope and establishes the execution order. Each methodology framework defines its rules as an ordered sequence, ensuring consistent evaluation regardless of when the trigger fires.
### 2. Evaluate [#2-evaluate]
Each rule in the sequence is executed. A rule evaluates conditions against the current data, performs calculations where required, and produces outputs. Rules can validate material types, check chain-of-custody completeness, calculate weights, or evaluate compliance against methodology-specific criteria. Each rule's result is persisted immediately and visible in the Carrot Registry, so execution progress and outcomes are available in real time.
### 3. Review when needed [#3-review-when-needed]
Rules the code cannot settle on their own return a review-required verdict. The run then pauses for a recorded human decision: a reviewer approves or rejects each flagged rule with a mandatory written justification, and the decision is stored with the run alongside the reviewer's identity and the time it was made. If the review window closes with flagged rules still undecided, those rules are rejected automatically and the verification fails.
### 4. Finalize [#4-finalize]
After all rules complete — and after any required review is resolved — the platform finalizes the outputs: verified MassIDs are marked as eligible for on-chain minting, certificates are queued for issuance, and state is updated across all affected entities. The registry records themselves — recorded MassIDs, issued certificates and credits — are written to the public ledger. The rule results, the review decisions and their inputs stay platform-held, and all of it is reflected in the Carrot Registry.
## Outcomes [#outcomes]
Methodology execution produces two primary outcomes:
* **Verified MassIDs** — MassIDs that have passed all methodology checks and are ready for [on-chain minting](/docs/protocol/on-chain-minting). Their chain of custody is complete, material type and weight are validated, and all compliance conditions are satisfied.
* **Certificates** — When a MassID passes all methodology verification rules at an accredited facility, certificates ([RecycledID](/docs/protocol/certificates#recycledid) or [GasID](/docs/protocol/certificates#gasid)) are issued. Certificates link the verified environmental outcome to the underlying MassID and initiate the minting of fungible [credit tokens](/docs/protocol/credits).
To generate a certificate or credit, the tracked mass must satisfy every applicable framework criterion. Most criteria are settled by code-based validation, and a criterion the code decides against blocks certificate issuance and credit generation until the issue is corrected under the applicable framework. Criteria the code cannot settle on its own are resolved through the recorded human review described above — an approved review resolves the criterion without code deciding it, and a rejected one fails the verification.
Only data that is intended to be public is registered on the **public blockchain** — for example, minted MassIDs, Certificates, credit tokens, and retirement receipts. That on-chain data is publicly accessible: viewable through any [blockchain block explorer](/docs/glossary#blockchain-block-explorer) (e.g. [PolygonScan](https://polygonscan.com/)) or the Carrot Registry, which provides a user-friendly, domain-focused view of rule execution and outcomes for auditors, regulators, and credit buyers.
## Related pages [#related-pages]
* [dMRV](/docs/protocol/dmrv) — The execution and evidence process for approved methodology framework criteria
* [MvF](/docs/standard/concepts/mvf) and [MvA](/docs/standard/concepts/mva) — How methodology frameworks and their implementations define and execute rules
* [Registry Record Creation](/docs/protocol/on-chain-minting) — How verified MassIDs become permanent registry records
* [Methodologies](/docs/methodologies) — The validated scientific bases and their frameworks that define verification rules
# Network Integrators
## What is a Network Integrator? [#what-is-a-network-integrator]
A Network Integrator is a third-party software application that submits [supply chain](/docs/protocol/supply-chain) data to the [Carrot Network](/docs/network) via the [Carrot API](/docs/integrations). Network Integrators are the bridge between physical recycling operations and the Carrot Network's digital verification layer — they digitize the waste management activities that their customers perform every day.
Network Integrators are typically logistics platforms, waste management applications, or recycling software tools that already serve participants in the recycling supply chain — [Waste Generators, Bin Custodians, Haulers, Processors, and Recyclers](/docs/protocol/supply-chain). By integrating with the Carrot Network, these platforms unlock credit generation and rewards for their existing user base without requiring those users to interact with the Carrot Network directly.
## How integration works [#how-integration-works]
To become a Network Integrator, a software platform goes through Carrot's **accreditation** process — a formal review that verifies the platform can reliably submit accurate supply chain data. Once accredited, the platform connects to the Carrot Network through the Carrot API.
Through this integration, Network Integrators:
* **Submit supply chain event data** — Every pick-up, drop-off, and material validation performed by their users is reported to the Carrot Network, creating the digital trail that underpins digital MRV ([dMRV](/docs/protocol/dmrv)).
* **Create and update MassIDs** — As materials move through the supply chain, the integrator's data feeds into the [MassID](/docs/protocol/mass-ids) chain of custody, recording what was collected, by whom, and where it went.
* **Enable rewards distribution** — By digitizing the full chain of custody from waste generation through certified recycling, integrators make it possible for every participant to receive their share of [rewards](/docs/protocol/rewards-distribution).
## Why Network Integrators matter [#why-network-integrators-matter]
The Carrot Network does not operate waste collection trucks or sorting facilities. It is a verification and credit-generation layer that depends on accurate, real-time data from the physical supply chain. Network Integrators provide that data.
This architecture creates a separation of concerns:
* **Network Integrators** focus on what they do best — logistics software, route optimization, fleet management, and customer operations.
* **The Carrot Network** focuses on verification, [methodology execution](/docs/protocol/methodology-execution), and credit generation — using the data that integrators provide.
For the integrator's customers, the result is seamless: they continue using their existing waste management software, and Carrot Network verification and credit generation happen in the background. Waste Generators earn a fixed share per waste type for the material they sorted, Haulers earn rewards for verified transport, and Processors and Recyclers earn rewards for verified processing — all without needing to interact with a separate system.
## Incentives [#incentives]
Network Integrators receive a share of the proceeds when credits generated from MassIDs they helped track are purchased — [Tokenized Recycling Credits (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc) or [Tokenized Carbon Credits (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc). Issuing a certificate creates no reward on its own: the share is resolved when the credits sell. This reward share is defined in the [Rewards Distribution Policy](/docs/standard/policies/rewards-distribution).
This creates a direct alignment: the more supply chains an integrator digitizes, the more material reaches certified recycling, and the more of the resulting credits are purchased, the more rewards the integrator earns. The model incentivizes integrators to onboard new customers, expand into new waste streams, and improve data quality — all of which strengthen the network.
## Open ecosystem [#open-ecosystem]
The Carrot Network operates as an open ecosystem. Any software platform that meets the accreditation requirements can become a Network Integrator. This openness also applies to methodology proposals, methodology verification frameworks, and third-party dMRV applications: ecosystem contributors can submit them for review and approval under the [Carrot dMRV Standard](/docs/standard). [MvF Authors](/docs/standard/concepts/mvf#the-mvf-author-role) are incentivized through a share of credit purchase proceeds, encouraging innovation across the network.
This distributed approach means the Carrot Network can scale across geographies and waste types without building custom integrations for every market. Local waste management software providers bring their domain expertise and customer relationships; the Carrot Network provides the verification infrastructure and credit market.
[Learn about the supply chain](/docs/protocol/supply-chain) · [Learn about rewards](/docs/protocol/rewards-distribution)
# Carrot Registry
## What is the Carrot Registry? [#what-is-the-carrot-registry]
The Carrot Registry ([registry.carrot.eco](https://registry.carrot.eco)) is the technical record layer of Carrot's public verification surface. It presents public, auditable data in a user-friendly way; the records written to the immutable ledger are specifically identified as such. That makes the Carrot Network's environmental claims independently verifiable without relying on technical tools or raw transaction records.
Within the Registry, browsing and verifying individual records is the **Explorer**. The name refers to that section, not to the surface as a whole.
Alongside the Registry, **Atlas** is the public entity surface — one page per record, and the address written into each record's on-chain metadata. See [Atlas](#atlas) below.
## Main sections [#main-sections]
The Registry is organized around the core concepts of the digital MRV ([dMRV](/docs/protocol/dmrv)) pipeline and the [credit lifecycle](/docs/protocol/credit-lifecycle). Key sections include:
| Section | What you can see |
| ------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Methodology Framework Definitions** | Published methodology framework (MvF) definitions and documentation — the operational rules that translate a validated methodology into executable verification logic. |
| **Application Rules (MvA)** | Methodology Verification Application (MvA) rules — the verification logic that is executed against supply chain data. |
| **MassID Verification** | Methodology execution results — rule runs, inputs, and outcomes for each MassID verification. |
| **Certificates** | GasID and RecycledID certificates, their backing MassIDs, and available credit balances. |
| **MassIDs** | Individual verified waste batches — documents, events, and metadata. |
| **Participant Accreditations** | Network Integrator accreditation status and approved participants. |
| **Credit Purchases and Retirements** | Credit purchase and credit retirement records, receipts, and proof of environmental action. |
These are some of the main sections; additional data such as credit balances and total credit supply is also available in the Registry.
Not everything the Registry shows is written to the immutable public ledger. Only certain data is recorded there — for example, recorded [MassIDs](/docs/protocol/mass-ids), issued [Certificates](/docs/protocol/certificates) and [credit](/docs/protocol/credits)s, purchase and retirement receipts, and rewards commitments. Methodology framework definitions, application rules (MvA), methodology execution results (rule runs and inputs), supply chain documents and events, and participant accreditations are held and displayed by the platform; the Registry surfaces both on-chain data and this platform data in one place.
Of the data shown, MassIDs are the only records registered directly by [Network Integrators](/docs/protocol/network-integrators) — they submit [supply chain](/docs/protocol/supply-chain) data via the [Carrot API](/docs/integrations/api) that the platform processes into verified waste batches. [Methodology frameworks](/docs/standard/concepts/mvf) (MvF), [application rules](/docs/standard/concepts/mva) (MvA), [methodology executions](/docs/protocol/methodology-execution), Certificates, credits, [credit purchases](/docs/protocol/credit-purchase), and [credit retirements](/docs/protocol/credit-retirement) are produced and recorded by the platform.
Registry records — recorded MassIDs, issued Certificates and credits, and purchase and retirement receipts — are backed by immutable public transactions and presented in the Registry with environmental context, so anyone can trace a retired credit back through its certificate to the underlying MassIDs and the physical work they represent.
## Atlas [#atlas]
**Atlas** ([atlas.carrot.eco](https://atlas.carrot.eco)) is the public entity surface of the Carrot
Network — one page per record, in plain language: the waste batch, its chain of custody, the
certificate and the calculation behind it. It links onward to the Registry for the raw technical
detail it does not display itself.
Atlas is also where a link followed from outside Carrot resolves. Each record's public metadata
carries an Atlas address, so a block explorer, a wallet or a marketplace that reads a token lands
on the page for that record:
| Address | Record |
| ------------------------------------- | ----------------------------------------------------------- |
| `atlas.carrot.eco/mass-ids/{id}` | A verified waste batch |
| `atlas.carrot.eco/certificates/{id}` | A GasID or RecycledID certificate |
| `atlas.carrot.eco/verifications/{id}` | The audit behind a certificate |
| `atlas.carrot.eco/methodologies/{id}` | The methodology a certificate was issued under |
| `atlas.carrot.eco/credit-orders/{id}` | A credit purchase and its receipts |
| `atlas.carrot.eco/collections/{id}` | A collection of credits |
| `atlas.carrot.eco/contracts/{slug}` | A record type as a whole — its collection-level description |
These addresses are fixed by the records that carry them: each one is written into metadata that is
already published, so it keeps resolving for records issued in the past. The pages they resolve to
continue to evolve.
## Blockchain block explorers [#blockchain-block-explorers]
On-chain activity — MassID and Certificate minting, credit issuance, purchases, retirements, and rewards distribution — is recorded on a public blockchain. That on-chain data can be verified through any [blockchain block explorer](/docs/glossary#blockchain-block-explorer) (e.g. [PolygonScan](https://polygonscan.com/) for Polygon PoS, which Carrot uses) without relying on Carrot's infrastructure.
A blockchain block explorer shows raw on-chain transactions and interactions, such as:
* Credit issuance and minting
* Credit purchase and credit retirement transactions
* Token transfers and contract calls
* Rewards distribution and other contract events
The Carrot Registry combines on-chain data with platform data — such as methodology framework definitions, rule execution results, and accreditations — to present a domain-focused view with supply chain data and environmental audit trails, so non-technical users can verify and explore without reading transaction hashes or contract logs.
| Tool | What it shows | Relies on Carrot |
| ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------- |
| **Carrot Registry** | On-chain data (MassIDs, certificates, credits, purchases, retirements) plus platform data (methodology frameworks and rules, MassID verification results, accreditations) — with environmental context | Yes |
| **Blockchain block explorer** (e.g. PolygonScan) | Raw on-chain transactions only — credit issuance, minting, purchases, retirements, rewards distribution, contract calls, event logs | No |
## Why it matters [#why-it-matters]
The Carrot Registry makes the Network's environmental claims independently verifiable. Anyone can trace a retired credit back through its certificate to the underlying MassIDs and the physical work they represent. This end-to-end transparency distinguishes Carrot credits from traditional environmental offsets.
Because on-chain data is recorded on a public blockchain, verification of that data does not depend on Carrot's availability — any blockchain block explorer can confirm the same facts independently. The [Carrot Foundation](/docs/network/the-foundation) may use this data for initiatives such as leaderboards recognizing organizations that contribute to waste recovery and recycling market development.
[Learn about dMRV](/docs/protocol/dmrv) · [Learn about credit retirement](/docs/protocol/credit-retirement)
# Rewards Distribution
## How rewards work [#how-rewards-work]
When [a quantity of credits is purchased](/docs/protocol/credit-purchase), the proceeds from that sale are shared with every participant who contributed to the environmental work those credits represent. This is the core incentive mechanism of the Carrot Network — it ensures that [supply chain participants](/docs/protocol/supply-chain), [Network Integrators](/docs/protocol/network-integrators), [MvF Authors](/docs/standard/concepts/mvf#the-mvf-author-role) and [MvA Developers](/docs/standard/concepts/mva#the-mva-developer-role) are all rewarded for their verified contributions.
Rewards are paid in [USDC](/docs/glossary#usdc) (a traceable digital currency pegged to the US dollar), giving participants **stable value** without exposure to market price volatility. Participants can withdraw their rewards in fiat or stablecoin according to their needs. See the [Rewards Distribution Policy](/docs/standard/policies/rewards-distribution#payment-currency-and-withdrawal) for full details on payment currency and withdrawal options.
## Distribution mechanics [#distribution-mechanics]
The distribution follows the [MassID](/docs/protocol/mass-ids) chain of custody through three steps:
### Step 1: Split by credit value [#step-1-split-by-credit-value]
When a buyer [purchases a quantity of credits](/docs/protocol/credit-purchase), the order is fulfilled by allocating from one or more [certificates](/docs/protocol/certificates) (each backed by [MassIDs](/docs/protocol/mass-ids)). The proceeds are split across those MassIDs proportional to the value of the credits drawn from each. When every credit drawn carries the same unit value — as in a recycling-only allocation, where one credit is one metric ton of certified material — that reduces to a split by weight: a MassID contributing 10 kg to a 1,000 kg allocation receives 1% of that allocation's proceeds. It does not reduce to weight when a purchase mixes credit types priced differently, as the paired carbon and recycling model does.
### Step 2: Split by role [#step-2-split-by-role]
Each MassID's share is then distributed across all participant categories. Each category receives a percentage defined by the [Rewards Distribution Policy](/docs/standard/policies/rewards-distribution):
| Participant | Key | Role in distribution |
| --------------------------------------- | ---- | ------------------------------------------------------------------------------------- |
| **Waste Generator** | G | Rewarded for source sorting |
| **Waste Manager** | WM | Rewarded for coordinating and directing waste destination |
| **Bin Custodian** | BC | Rewarded for providing and maintaining the collection bin or drop-off point |
| **Hauler** | H | Rewarded for transport |
| **Processor** | P | Rewarded for sorting and pre-processing |
| **Recycler** | R | Rewarded for certified recycling |
| **Network Integrator** | I | Rewarded for digitizing the supply chain |
| **MvF Author** | A | Rewarded for creating the methodology framework (MvF) |
| **MvA Developer** | D | Rewarded for implementing the framework as the MvA (executable verification software) |
| **Distribution Fee** | DF | Covers transaction handling and the settlement and payout of participant rewards |
| **Registry** | RG | Covers issuing and maintaining the records of credit and certificate issuance |
| **digital MRV and Integrity Component** | dMRV | Feeds the Foundation Treasury and sustains protocol development and network integrity |
The total percentages across all categories always equal 100% of the MassID's value. G, WM, BC, H, P, and R are [supply chain roles](/docs/protocol/supply-chain). The [Waste Manager](/docs/protocol/supply-chain#waste-manager) coordinates destination without physical custody; the other roles in this group handle material. The remaining categories (I, A, D, DF, RG, dMRV) are ecosystem participants and network components that provide the digital infrastructure, [methodology frameworks](/docs/standard/concepts/mvf) and [MvAs](/docs/standard/concepts/mva), and network infrastructure that enable methodology execution and credit generation. For the full participant list, the [destination funds](/docs/standard/policies/rewards-distribution#destination-funds), and the specific percentage breakdowns by waste type, see the [Rewards Distribution Policy](/docs/standard/policies/rewards-distribution).
### Step 3: Allocate to participants [#step-3-allocate-to-participants]
Each category's share is sent to the participant(s) in that category. If a category has more than one participant — for example, two Haulers — that share is split among them. The network components (DF, RG, dMRV) are not participant payouts: the Distribution Fee and Registry cover network operations, and the digital MRV and Integrity Component feeds the [Foundation Treasury](/docs/glossary#foundation-treasury).
For organic waste, a confirmed Waste Manager receives 4%, drawn from the Hauler (1%), Processor
(1%), and Recycler (2%) categories. Without a confirmed Waste Manager, each share returns to its
source. More than one confirmed Waste Manager splits the 4% category share.
## Confirming a Waste Manager [#confirming-a-waste-manager]
Waste Manager onboarding alone does not create reward eligibility. The Waste Manager must declare
the Waste Generators it serves, and each generator must confirm that relationship during its own
onboarding. Both sides must complete onboarding before the relationship affects distribution. A
one-sided declaration has no effect.
## The incentive mechanism: reaching the source [#the-incentive-mechanism-reaching-the-source]
The distribution mechanism changes dramatically when the **Waste Generator is not identified** in the chain of custody. This is by design — it creates a powerful incentive to extend tracking technology all the way to the source of waste creation and to encourage behavior change — incentivizing waste generators at the source of waste creation to participate in better sorting and contracting high-performance recycling services.
When the Waste Generator is not identified:
* **100% of the Waste Generator's share** is redirected to the **[Community Pool](/docs/glossary#community-pool)** — a discretionary fund that reinvests value into open-network growth.
* **All other logistics and service participants** (Haulers, [Processors](/docs/protocol/supply-chain), [Recyclers](/docs/protocol/supply-chain), and the Network Integrator — and the Bin Custodian where applicable) receive a **25% discounted payout** compared to what they would receive in a fully tracked supply chain. The discounted amounts are also directed to the Community Pool.
An unidentified Waste Generator cannot be associated with a confirmed Waste Manager relationship
for the MassID. The Waste Manager therefore receives no share in this case, and its conditional 4%
returns to the Hauler, Processor, and Recycler categories.
This recycles value that would otherwise sit idle back into ecosystem growth, rather than letting it be captured by any private party. For how the network organizes its funds — the [Foundation Treasury](/docs/glossary#foundation-treasury), Community Pool, and [Impact Pool](/docs/glossary#impact-pool) — see the [Rewards Distribution Policy](/docs/standard/policies/rewards-distribution#destination-funds).
This creates a direct financial incentive for every participant to push for source identification. When a Hauler's rewards are discounted because the Waste Generator is missing from the chain of custody, that Hauler has a concrete reason to adopt tools that track waste from the point of generation.
When a supply chain is **fully digitized** — tracking waste from the Waste Generator through every step to the Recycler — eligible participants receive 100% of their allocated rewards. Waste Manager eligibility still requires the confirmed relationship described above. This is the economic incentive driving the network toward full supply chain transparency.
## Claiming rewards [#claiming-rewards]
Rewards are committed on-chain at the moment of sale, through a privacy-preserving claims mechanism. During each credit purchase, a Merkle root is recorded on the network's public registry, representing the complete rewards distribution for that transaction. This root commits to the full distribution without revealing any individual amounts or identities at the time of sale.
Participant identities stay pseudonymous in the public records. The sale-time reward commitment carries no direct participant identifier — inside it each participant is a purchase-scoped hash, so the committed distributions on their own cannot be correlated across purchases, and an observer can verify that a distribution is valid without determining which real-world participant corresponds to any given entry. That guarantee is scoped to the commitment, not to every public record: a [MassID](/docs/protocol/mass-ids) publishes a stable participant identifier as a non-reversible hash, and when a participant withdraws, the claiming wallet and the amount are recorded on-chain, so a participant who claims from several purchases with the same wallet is linkable across those withdrawals.
A participant's first payout is settled by Carrot, which is what binds their withdrawal wallet; from then on the participant claims directly against the on-chain proof. A stablecoin withdrawal settles straight from that claim; a fiat payout is fulfilled through an integrated payment provider. Each claim is verified against the recorded Merkle root using a Merkle proof, ensuring the distribution amount is correct without revealing participant identities publicly.
**Auditability**: While participant identities are protected from public view, authorized auditors can access the underlying data to identify participants for compliance and regulatory purposes. This balances individual privacy with the accountability requirements of environmental credit markets.
Rewards are recorded using **Merkle trees** — a cryptographic data structure that commits to the entire distribution in a single on-chain value (the Merkle root). This means the complete distribution for a purchase is represented by one hash stored on-chain, rather than recording each participant's reward individually.
Each participant's reward is a **leaf** in the tree. When a participant claims their reward, they submit a Merkle proof — a short cryptographic path that proves their specific leaf is part of the committed root. The smart contract verifies this proof on-chain, confirming the claim amount is correct.
Claims require **dual-signature authorization**:
1. **Backend authorization** — A signature from the platform backend confirming the participant's identity and KYC compliance. This prevents unauthorized wallets from claiming rewards.
2. **Participant signature** — A signature from the participant's own wallet, proving ownership. On the normal claim path, this prevents the platform from moving funds without the participant.
On that path neither party can claim rewards alone: the backend cannot pay rewards to an unregistered wallet, and the participant cannot claim without passing identity verification. Lost-key recovery is the exception — the withdrawal wallet can be repointed without the participant's signature, so the participant signature is not what protects that path. What protects it is that the two steps sit behind different roles — an operator requests the change, an admin executes it — and every change is recorded on-chain. That separation is governance discipline, not a key-level guarantee: role separation is validated only at initialization, and `DEFAULT_ADMIN_ROLE` can grant itself the operator role afterwards (see [smart contract security](/docs/protocol/smart-contracts/security)). This design ensures:
* **Privacy** — The Merkle tree carries no direct participant identifier; each participant appears in it as a purchase-scoped hash.
* **Verifiability** — Every claim is checked against the committed Merkle root, guaranteeing distribution correctness.
* **Security** — Dual signatures prevent unauthorized claims and single-party fund movement on the normal claim path; wallet recovery is instead gated by two distinct roles, held by separate parties as a matter of governance, and recorded on-chain.
## Governance of rewards [#governance-of-rewards]
The percentage allocated to each participant category is not fixed — it is governed by the [Carrot Foundation](/docs/network/the-foundation) with input from ecosystem participants. Percentages can be adjusted by waste type to optimize recycling performance for specific markets.
For example, the Foundation could increase the Waste Generator's share for a waste stream where collection is the bottleneck, or adjust the Hauler's share where transport cost is the barrier to recycling.
***
[Credit Purchase](/docs/protocol/credit-purchase) · [Supply Chain](/docs/protocol/supply-chain) · [Smart Contracts](/docs/protocol/smart-contracts)
# Recycling Supply Chain
## Overview [#overview]
The recycling supply chain is the physical path that materials take from waste generation through collection, sorting, hauling, and processing at accredited recycling or biological treatment facilities. Understanding this flow is essential to understanding how the [Carrot Network](/docs/network) creates value — every step is digitized, verified, and rewarded.
The critical principle: **high-performance recycling starts at the source**. Sorting and cleaning mixed waste after contamination is too expensive and technically complex for most locations. The Carrot Network's incentive system is designed to reach the Waste Generator, because source sorting is the single most impactful action for recycling performance.
## Participants [#participants]
Seven role categories define who does what in the recycling supply chain. Five take physical custody
of material; the Waste Manager coordinates destination without custody, and the Network Integrator
provides the data bridge:
| Role | Responsibility | Reward eligibility |
| ---------------------- | --------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| **Waste Generator** | Produces waste and performs source sorting | Yes — a fixed share per waste type for the sorted material, reduced for large businesses and for incomplete onboarding |
| **Waste Manager** | Coordinates destination without taking physical custody | Yes — 4% for organics when its relationship with the generator is confirmed |
| **Bin Custodian** | Manages collection bins and drop-off points | Yes — rewarded for bin infrastructure |
| **Hauler** | Transports waste between locations | Yes — rewarded for logistics work |
| **Processor** | Sorts, accumulates, and pre-processes materials | Yes — rewarded for processing work |
| **Recycler** | Performs certified recycling or biological treatment | Yes — rewarded for recycling; also rewarded as Processor when it records the sorting events |
| **Network Integrator** | Provides the logistics software that digitizes the supply chain | Yes — rewarded as the software provider |
Participants frequently fill multiple roles. A hauler with its own sorting facility is both a Hauler and a Processor. A waste generator who delivers waste directly to a processor is also a Hauler. A recycler that also receives and sorts the material is recorded under both roles — Processor and Recycler — and is rewarded for each. A Waste Manager that also transports material is both a Waste Manager and a Hauler and can be rewarded for each role it performs.
Beyond supply chain participants, the Carrot Network also distributes rewards to ecosystem participants who enable methodology execution and credit generation: the [MvF Author](/docs/standard/concepts/mvf#the-mvf-author-role), [MvA Developer](/docs/standard/concepts/mva#the-mva-developer-role), and the network's own operations (covering digital MRV ([dMRV](/docs/protocol/dmrv)) infrastructure, network oversight, and data processing). See the full [Rewards Distribution](/docs/protocol/rewards-distribution) for all participant categories.
### Waste Manager [#waste-manager]
The **Waste Manager** is contracted by the Waste Generator to select and contract service providers,
direct material to specific facilities, and report on regulatory compliance. It does not transport,
sort, or treat material. Its contribution is the destination decision: it can direct the same
material to disposal or to certified recycling.
Onboarding as a Waste Manager does not by itself create reward eligibility. The Waste Manager must
declare the generators it serves, and each Waste Generator must confirm that relationship. Both
sides must complete onboarding before the Waste Manager is recognized for that generator's assets.
A one-sided declaration has no effect on rewards.
For organic waste, a confirmed Waste Manager is eligible for a 4% share. If none is confirmed, the
allocation remains with the Hauler, Processor, and Recycler categories; if more than one is
confirmed, they divide the category share. See the
[Rewards Distribution Policy](/docs/standard/policies/rewards-distribution) for the exact allocation
and discount rules.
## Material flow [#material-flow]
Materials move through the supply chain via two logistics models:
### Local hauling [#local-hauling]
Haulers execute multiple pick-up events along a door-to-door route, collecting waste from generators and delivering it to a local processor. The processor validates the contents at drop-off, creating or updating [MassIDs](/docs/protocol/mass-ids) for each material type and weight.
### Long hauling [#long-hauling]
Material is shipped from one processor to another, or from a processor to a recycler. The transfer is recorded as a Pick-up and a Drop-off covered by a single Transport Manifest, with the waste validated only by the receiving facility. Long-haul shipments typically carry larger volumes of pre-sorted material.
At each transfer point, the receiver acts as a [Validator](/docs/protocol/dmrv#validators-and-supply-chain-events), confirming material content and updating the MassID chain of custody. This validation at every handoff is what creates the Proof-of-Physical-Work — verifiable evidence that real-world recycling work was performed — that underpins credit generation.
## Reaching the source [#reaching-the-source]
The Carrot Network's [rewards distribution](/docs/protocol/rewards-distribution) is specifically designed to reach the waste generator — the source of waste creation. This is critical because:
* **Waste generators need incentives to sort** — Without feedback on sorting quality and financial rewards for participation, there is no reason for individuals and businesses to sort diligently.
* **Source data enables Pay-As-You-Throw** — When waste is weighed and tracked from the point of generation, each generator pays precisely for the waste they produce, creating direct incentives for waste reduction.
* **Sorting at source transforms recycling economics** — Removing organic waste contamination from recyclable streams can improve recovery rates by 2-4x at downstream sorting facilities.
Certified recycling rewards, distributed via the [MassID](/docs/protocol/mass-ids) chain of custody, provide the economic incentive for generators to sort properly and stay engaged with the system.
## The role of the Recycler [#the-role-of-the-recycler]
The Recycler occupies a special position in the supply chain. A Recycler is a processor that has been **accredited** by third-party auditors to perform certified recycling for a specific waste material type.
* A glass bottling plant using cullet in its furnaces is a certified glass Recycler — it cannot recycle plastic.
* A biological treatment facility transforming food waste into compost is a certified food waste Recycler — it cannot recycle electronics.
Only when MassIDs reach an accredited Recycler and pass the dMRV validation process do they become eligible for issuance as [Tokenized Recycling Credits (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc) and [Tokenized Carbon Credits (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc).
## How the supply chain creates value [#how-the-supply-chain-creates-value]
The recycling supply chain creates value by connecting waste generators who need disposal services with credit buyers who need environmental offsets — and rewarding every verified contributor in between:
* **Waste Generators** gain visibility into their waste footprint, earn rewards for sorting, and can demonstrate compliance with waste regulations.
* **Waste Managers** earn a share for directing organic waste to certified recycling when their relationship with the generator is confirmed.
* **Bin Custodians** open the door for private companies and public-private partnerships to sponsor bin networks, earning rewards from credit purchases.
* **Haulers** earn new revenue streams from dedicated routes for specific waste types, supplementing traditional hauling income.
* **Processors and Recyclers** receive additional proceeds from credit purchases on top of existing material sales, improving the economics of recycling as a professional service.
* **[Network Integrators](/docs/protocol/network-integrators)** earn a share of rewards for providing the logistics software that digitizes the supply chain.
This distributed reward system opens the recycling market to innovation and entrepreneurial activity, ensuring all stakeholders are rewarded for their verified environmental contribution.
[Learn about MassIDs](/docs/protocol/mass-ids) · [Learn about dMRV](/docs/protocol/dmrv)
### Diagram: supply-chain-participants
This supply chain diagram shows the physical custody chain from Waste Generator to Bin Custodian, Hauler, Processor, and Recycler. The Waste Manager sits outside that group and connects through a conditional relationship because it coordinates destination without handling material. The Network Integrator connects beside the chain as its data bridge.
# Methodology Ecosystem
## Systemic view [#systemic-view]
The methodology ecosystem transforms scientific standards into automated, auditable verification. Each stage has defined roles, inputs, and outputs:
For a reader-friendly map of every role around this pipeline, see
[Credit Ecosystem Roles](/docs/protocol/credit-ecosystem-roles).
**Methodology** (scientific basis) → **[MvF](/docs/standard/concepts/mvf)** (verification specification) → **[MvA](/docs/standard/concepts/mva)** (software implementation) → **Orchestration** (automated evaluation) → **[Certificates](/docs/protocol/certificates)** (verified outcomes) → **[Credits](/docs/protocol/credits)** (registry-issued impact)
This pipeline converts raw [supply chain](/docs/protocol/supply-chain) data — collected by [Network Integrators](/docs/protocol/network-integrators) through [MassIDs](/docs/protocol/mass-ids) — into verified, tradeable environmental impact credits.
## Standards and methodologies [#standards-and-methodologies]
A **standard** governs the creation and management of methodologies and credit issuance. Under each standard there are N methodologies; governance sits at the standard level.
* Where no established global standard exists (e.g. recycling credits), Carrot assumes the standards role through the [Carrot dMRV Standard](/docs/standard).
* For domains with established standards (e.g. carbon — UNFCCC [AMS-III.F](/docs/glossary#ams-iii-f)), Carrot provides the public credit registry and digital MRV ([dMRV](/docs/protocol/dmrv)) infrastructure while the methodology references the external standard.
## Methodology objects [#methodology-objects]
| Object | Definition | Example |
| --------------- | ------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- |
| **MvF** | Verification specification defining scope, rules, and formulas | BOLD Recycling Framework v1.0.1 |
| **MvA** | Software that implements the MvF as executable rule processors | BOLD Recycling rule processors |
| **Certificate** | Methodology-certified output for a single MassID, confirming an environmental claim | RecycledID, GasID |
| **Credit** | Certificate issued as a traceable unit on the public registry, representing verified impact | TRC (e.g. `C-BIOW` from BOLD Recycling), TCC (e.g. `C-CARB.CH4` from BOLD Carbon (CH₄)) |
## Building a credit program [#building-a-credit-program]
A [**Program Owner**](/docs/protocol/credit-ecosystem-roles#program-owner) leads the construction of
a credit program. It assesses the target market, coordinates development of the methodology, MvF,
and MvA, and proposes the program-specific rewards policy. The proposal must follow the Carrot dMRV
Standard and remains subject to the Community of Experts and Carrot's governance processes; the
Program Owner does not approve its own program.
A [**Network Developer**](/docs/protocol/credit-ecosystem-roles#network-developer) can then help the
program grow by recruiting participants, coordinating the accreditation process required by the
methodology framework, and submitting supporting data. Independent audits remain independent: the
Network Developer does not approve participants or replace third-party assurance.
These are program- and network-development roles, not reward categories. Neither receives protocol
rewards or appears in distribution percentages; separate services can be compensated only through
contracts outside the protocol distribution.
## Who can create a dMRV methodology [#who-can-create-a-dmrv-methodology]
Methodology proponents can be individuals, organizations, or research institutions with domain expertise in the target environmental claim. Creating a dMRV methodology requires:
* **Domain expertise** — Deep understanding of the environmental science and measurement approaches
* **Scientific basis** — Grounding in established international standards (e.g., UNFCCC CDM methodologies, IPCC guidelines)
* **Alignment with the [Carrot dMRV Standard](/docs/standard)** — All methodologies must meet the Standard's requirements for traceability, additionality, and transparency
### Proponent qualifications [#proponent-qualifications]
Proponents must demonstrate credentials appropriate to the type of contribution:
* **Domain expertise** — Scientific publications, environmental certifications, or demonstrated experience with methodologies in the target domain
* **Technical capacity** — For MvF proposals: ability to structure verification frameworks with testable rules, traceability matrices, and evidence policies. For MvA proposals: software engineering capability in the platform's technology stack
* **Institutional standing** — Clean track record with no unresolved non-conformities, conflicts of interest, or regulatory restrictions
These requirements serve as an integrity barrier — ensuring that methodology quality starts at the proponent level.
The preferred entry mechanism is through [Requests for Proposals (RFP)](/docs/standard/policies/rfp-process). For practical guidance on how to participate, see the [RFP Participation Guide](/docs/standard/guides/rfp-participation-guide).
The proposal process follows the [methodology lifecycle](/docs/standard/concepts/lifecycle): proposal, community validation, development, and production deployment.
## Integration and data inputs [#integration-and-data-inputs]
Network Integrators are the bridge between real-world supply chain activities and the digital verification system:
1. Network Integrators collect supply chain data and submit MassID documents via the [Carrot API](/docs/integrations/api).
2. The MvA evaluates each document against the methodology framework's (MvF) rules.
3. When MassIDs pass methodology verification, Certificates are generated.
4. Credits are issued from Certificates, and when those credits are sold the proceeds are distributed as [rewards](/docs/protocol/rewards-distribution) to participants.
See the [API documentation](/docs/integrations/api) for integration details.
## Community of Experts [#community-of-experts]
The Community of Experts provides governance and scientific oversight for the methodology ecosystem. It operates within the broader [progressive community participation](/docs/network/governance#progressive-community-participation) framework, applying the same three phases specifically to methodology governance:
1. **Engagement** — Open participation in methodology discussions, feedback, and proposals. Any domain expert can contribute.
2. **Consultative** — Expert review panels evaluate new methodology proposals and framework revisions for scientific rigor and practical feasibility.
3. **Deliberative** — Binding governance decisions on methodology approval, scope adjustments, and collision resolution.
The Community of Experts' role evolves as the ecosystem matures, with the [Carrot Foundation](/docs/network/the-foundation) progressively expanding community participation in governance decisions.
## Platform intelligence layers [#platform-intelligence-layers]
The platform includes two intelligence layers that support verification and ecosystem evolution (distinct from the Community of Experts governance body):
* **[Carrot Analytic Engine (CaE)](/docs/glossary#cae)** — The evaluation layer of the verification stack. The CaE can analyze MvA outputs, detect anomalies, inconsistencies, and suspicious patterns across data and verification results. When the CaE flags irregularities, the platform can pause credit issuance, trigger human review, or recommend methodology and rule revisions. The CaE enhances audit quality but does not certify credits.
* **[Carrot Agentic Advisor (CaA)](/docs/glossary#caa)** — The advisory layer of the verification stack. The CaA can learn from verification outcomes and feedback to identify opportunities for improvement, process optimization, and methodology evolution. It can recommend parameter adjustments, methodology updates, and quality improvements to authors, developers, and validation bodies. The CaA functions as an intelligence advisor, not an authority.
These layers do not replace methodology rules or governance; they signal and support decisions, and their outputs can feed into the [digital evidence package](/docs/glossary#digital-evidence-package) when relevant.
## Integrity and anti-fraud [#integrity-and-anti-fraud]
The ecosystem includes multiple layers of protection against double counting and fraud:
* **Collision detection** — Scope registration and community review prevent overlapping methodologies from being deployed. See the [Colliding Methodologies](/docs/standard/policies/colliding-methodologies) policy.
* **Uniqueness rules** — Runtime rules like `waste-mass-is-unique` and `no-conflicting-certificate-or-credit` prevent the same waste mass from being verified or credited twice.
* **Audit trails** — Every verification result is recorded immutably with the exact data that was evaluated, making the system independently auditable.
## Interoperability [#interoperability]
Methodologies in the Carrot ecosystem are designed to share infrastructure:
* **Common document format** — All methodologies use MassIDs for supply chain data, enabling consistent validation patterns.
* **Shared rule libraries** — Rule processors for common verifications (actor identification, weighing, geolocation) are implemented once and reused across all methodologies.
* **Extendable architecture** — New methodologies can build on existing rules while adding domain-specific logic (e.g., emissions calculation for [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon)).
[Learn about the Carrot dMRV Standard](/docs/standard) · [Learn about the methodology lifecycle](/docs/standard/concepts/lifecycle)
### Diagram: layered-architecture
This layered architecture diagram maps responsibility, layer, and function from validated scientific methodology to MvF, MvA, Carrot Platform orchestration, and auditable outputs. Registry or third parties define what to measure; authors and developers translate and implement it; Carrot executes checks, CaE anomalies, CaA recommendations, and evidence packages under independent VVB review.
# Methodology Lifecycle
## Lifecycle stages [#lifecycle-stages]
Every digital MRV ([dMRV](/docs/protocol/dmrv)) methodology in the [Carrot Network](/docs/network) follows a defined lifecycle from initial proposal through production operation to eventual deprecation:
1. **Proposal** — A proponent submits the methodology concept for evaluation.
2. **Validation** — The Community of Experts reviews the proposal for scientific rigor and feasibility.
3. **Development** — The [MvF](/docs/standard/concepts/mvf) specification and [MvA](/docs/standard/concepts/mva) implementation are built and tested.
4. **Accreditation** — The completed MvF is evaluated against [six quality dimensions](/docs/standard/policies/quality-and-accreditation) and, when approved, formally accredited for production operation.
5. **Production** — The methodology is deployed and begins processing [MassID](/docs/protocol/mass-ids) documents.
6. **Versioning** — The methodology evolves through versioned releases as rules are refined or added.
7. **Deprecation** — The methodology is retired when it is no longer valid or has been superseded.
## Proposal and validation [#proposal-and-validation]
Proposals typically originate from a [Request for Proposals (RFP)](/docs/standard/policies/rfp-process) — Carrot publishes a formal call with scope, type, eligibility requirements, evaluation criteria, and timeline. Six RFP types cover different contribution needs, from problem-solving proposals to MvF authoring to MvA development. Proponents can also enter via partnership or direct submission, subject to the same integrity and qualification requirements. See the [RFP Participation Guide](/docs/standard/guides/rfp-participation-guide) for practical submission guidance.
A methodology proposal must demonstrate:
* **Scientific basis** — Grounding in established standards (e.g., UNFCCC CDM methodologies, IPCC guidelines)
* **Additionality** — Evidence that the verified activity creates impact beyond business-as-usual
* **No collision** — Confirmation that the proposed scope does not overlap with existing methodologies (see [Colliding Methodologies](/docs/standard/policies/colliding-methodologies))
* **Alignment with the [Carrot dMRV Standard](/docs/standard)** — Compliance with all Standard requirements
The Community of Experts reviews proposals through consultative and deliberative phases, evaluating scientific rigor, practical feasibility, and market relevance.
## Development [#development]
Once a proposal is validated, two parallel workstreams begin:
* **MvF authoring** — An MvF Author writes the verification framework specification, defining scope, eligibility, validation rules, formulas, and a traceability matrix. See the [MvF Author Guide](/docs/standard/guides/mvf-author-guide).
* **MvA development** — An MvA Developer implements the framework as executable rule processors, including comprehensive testing with seed documents. See the [MvA Developer Guide](/docs/standard/guides/mva-developer-guide).
Both deliverables are reviewed against the Carrot dMRV Standard before the methodology can move to production.
## Accreditation [#accreditation]
Before entering production, the completed MvF undergoes a formal [accreditation process](/docs/standard/policies/quality-and-accreditation). The MvF is evaluated against six quality dimensions — completeness, verifiability, traceability, implementability, auditability, and geographic adaptability. The process allows up to two review cycles for the author to address any non-conformities. Once all dimensions are conformant, the MvF is accredited and the methodology can proceed to production deployment.
## Production and operation [#production-and-operation]
In production, the methodology actively processes MassID documents submitted by [Network Integrators](/docs/protocol/network-integrators):
* Each MassID is evaluated against every rule in the methodology's MvA.
* Every rule evaluation — passed, failed, or escalated for review — is recorded in the audit trail with the exact data that was checked.
* Rules that cannot be resolved digitally escalate to human review. The MassID is held while a reviewer approves or rejects each flagged rule with a written justification; if the review window closes with rules still unreviewed, they are rejected automatically and the MassID fails verification. See [MvF](/docs/standard/concepts/mvf) and the [MvF minimum structure guide](/docs/standard/guides/mvf-minimum-structure) for how a framework declares its escalation triggers.
* MassIDs that pass methodology verification generate [Certificates](/docs/protocol/certificates), and matching [Credits](/docs/protocol/credits) are issued.
* When credits issued by the methodology are purchased, the sale proceeds are distributed as [rewards](/docs/protocol/rewards-distribution) to [supply chain](/docs/protocol/supply-chain) participants, according to the network-wide [Rewards Distribution Policy](/docs/standard/policies/rewards-distribution).
## Versioning [#versioning]
Methodologies evolve through semantic versioning (SemVer):
* **MAJOR** — Breaking changes to verification logic that may affect existing integrations
* **MINOR** — New rules added without changing existing rule behavior
* **PATCH** — Bug fixes and documentation updates
The MvF and MvA are versioned independently, with the MvA tracking the MvF's MAJOR version. See the [Versioning Policy](/docs/standard/policies/versioning) for full details.
## Deprecation [#deprecation]
A methodology may be deprecated when it is no longer scientifically valid, has been superseded by a more effective approach, or is no longer operationally active. Credits issued before deprecation remain valid and tradeable.
See the [Discontinuation Policy](/docs/standard/policies/discontinuation) for the full deprecation criteria and process.
## Governance evolution [#governance-evolution]
Methodology governance is led by the [Carrot Foundation](/docs/network/the-foundation) with progressive expansion of community participation. As the ecosystem matures, the Community of Experts will take on increasing responsibility for methodology approval, versioning decisions, and Standard evolution.
[Learn about the methodology ecosystem](/docs/standard/concepts/ecosystem) · [Learn about the Carrot dMRV Standard](/docs/standard)
# MvA — Methodology Verification Application
## What is an MvA? [#what-is-an-mva]
A Methodology Verification Application (MvA) is the software that implements a [Methodology Verification Framework (MvF)](/docs/standard/concepts/mvf) as executable validation rules. It receives digital MRV ([dMRV](/docs/protocol/dmrv)) documents, evaluates them against every rule defined in the MvF, and returns PASSED, FAILED, or REVIEW\_REQUIRED results with explanations. REVIEW\_REQUIRED is the indeterminate verdict: the rule could not settle the question on its own, so the run pauses for a recorded human decision (see [Methodology Execution](/docs/protocol/methodology-execution)).
The key distinction: the MvF is the **specification** (what to verify), the MvA is the **implementation** (the code that verifies it).
**Methodology** (scientific basis) → **[MvF](/docs/standard/concepts/mvf)** (verification specification) → **MvA** (software implementation)
## What an MvA does [#what-an-mva-does]
An MvA processes [MassID](/docs/protocol/mass-ids) documents through its rule set:
1. **Validates supply chain documents** — Each rule inspects specific aspects of a MassID: actor identities, event data, weighing records, manifests, geolocation, and more.
2. **Applies calculation rules** — Certain rules perform calculations such as emission quantification (CO2e reductions) or geographic distance measurements.
3. **Feeds the audit system** — Every rule evaluation produces a traceable result with the exact data that was checked and why it passed, failed, or needs review.
Each rule is a deterministic function: given the same input document, the same rule version, and the same evaluation context, it always produces the same output. This makes the verification system fully auditable and reproducible.
## Design principles [#design-principles]
The MvA is built on four principles that ensure the integrity of automated verification:
* **Fidelity** — The MvA mirrors the MvF exactly. Every rule in the MvF has a corresponding rule processor in the MvA, and the evaluation logic matches the specification.
* **Traceability** — Every result — PASSED, FAILED, or REVIEW\_REQUIRED — is linked to the specific source data that was evaluated, making results independently verifiable.
* **Determinism** — No randomness. A rule's output is a function of its inputs and its versioned deployment configuration, so any evaluation can be reproduced exactly by replaying it against the same rule version and configuration.
* **Standard compliance** — All MvAs follow the [Carrot dMRV Standard](/docs/standard) requirements for structure, testing, and documentation.
## Architecture [#architecture]
The MvA is implemented as an open-source monorepo deployed as serverless functions:
* **Repository**: [github.com/carrot-foundation/methodology-rules](https://github.com/carrot-foundation/methodology-rules)
* **License**: LGPL-3.0 — anyone can audit, fork, or contribute
The codebase follows a two-layer architecture:
* **Shared rule libraries** — Contain the actual verification logic. Shared rule processors are reused across methodologies. Each rule is an independent module with its own tests.
* **Methodology application wrappers** — Thin deployment layers that wrap shared libraries as serverless functions. Each methodology deploys its own set of rules, including any methodology-specific rules.
This architecture means a rule like `weighing` is implemented once in the shared library and deployed to multiple methodologies (e.g., [BOLD Recycling](/docs/methodologies/bold-recycling) and [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon)). Methodology-specific rules (such as `prevented-emissions`) live only in that methodology's application layer.
Every rule is implemented as a rule processor — a standardized interface that follows the same five-step pattern:
1. **`process()`** — Entry point that orchestrates the evaluation.
2. **`generateDocumentQuery()`** — Builds the query to fetch the MassID document and related data.
3. **`collectDocuments()`** — Fetches the documents needed for evaluation.
4. **`getRuleSubject()`** — Extracts the specific data elements the rule needs to evaluate.
5. **`evaluateResult()`** — Applies the verification logic and returns PASSED, FAILED, or REVIEW\_REQUIRED with an explanation.
This consistent pattern means every rule in the system follows the same structure, making the codebase auditable and extensible.
## Framework rules vs. application rules [#framework-rules-vs-application-rules]
The Carrot methodology system uses a two-layer rules architecture:
* **Framework rules** define **what** must be verified at the specification level. These are the requirements from the MvF — for example, "the document must have a value greater than zero" or "a recycler actor must be present."
* **Application rules** define **how** verification is executed as open-source code. Each application rule is an independent function that evaluates a [MassID](/docs/protocol/mass-ids) document and returns PASSED, FAILED, or REVIEW\_REQUIRED.
The mapping between the two layers is not one-to-one. A single application rule may satisfy multiple framework rules (e.g., `mass-id-qualifications` verifies document value, unit, category, and type in one pass). Conversely, a framework rule may require multiple application rules to fully verify.
See the framework rules and application rules for each methodology:
* BOLD Carbon (CH₄): [Framework Rules](/docs/methodologies/ams-iii-f/bold-carbon) · [Application Rules](/docs/methodologies/ams-iii-f/bold-carbon/application/application-rules)
* BOLD Recycling: [Framework Rules](/docs/methodologies/bold-recycling/framework) · [Application Rules](/docs/methodologies/bold-recycling/framework/application/application-rules)
## The MvA Developer role [#the-mva-developer-role]
MvA Developers are engineers who implement and maintain rule processors. The role requires:
* Proficiency with the monorepo's programming language and tooling
* Understanding of the rule processor pattern
* Ability to translate MvF specifications into deterministic code
* Rigorous testing practices: unit tests, integration tests with seed documents, and end-to-end tests
See the [MvA Developer Guide](/docs/standard/guides/mva-developer-guide) for the step-by-step implementation process.
| Aspect | MvF | MvA |
| -------------- | ------------------------------------------------ | ------------------------------------------------------------ |
| **Nature** | Specification document | Software application |
| **Created by** | Environmental scientists and methodology experts | Software developers |
| **Output** | Rules as written criteria | PASSED / FAILED / REVIEW\_REQUIRED results with explanations |
| **Format** | PDF / structured document | Lambda functions in an Nx monorepo |
| **Versioning** | Framework SemVer (e.g., v1.0.0) | Application SemVer (tracks framework MAJOR) |
| **Review** | Community of Experts | Code review + automated testing |
[Learn about MvF](/docs/standard/concepts/mvf)
# MvF — Methodology Verification Framework
## What is an MvF? [#what-is-an-mvf]
A Methodology Verification Framework (MvF) is the specification document that defines **what** and **how** to measure, report, and verify environmental impact for a given digital MRV ([dMRV](/docs/protocol/dmrv)) methodology. It translates the scientific basis of a methodology into structured, testable verification requirements.
The MvF sits between the methodology's scientific foundation and its software implementation:
**Methodology** (scientific basis) → **MvF** (verification specification) → **[MvA](/docs/standard/concepts/mva)** (software implementation)
While the methodology describes the environmental claim and the science behind it, the MvF specifies exactly which data must be collected, what conditions must be met, and which formulas must be applied to verify that claim. The [MvA](/docs/standard/concepts/mva) then implements those specifications as executable code.
## Components of an MvF [#components-of-an-mvf]
An MvF document contains these interconnected components that together define the complete verification procedure:
| Component | Purpose |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------ |
| **Scope definition** | Defines eligible waste types, treatment methods, and geographic boundaries |
| **Eligibility criteria** | Specifies which participants, facilities, and activities qualify |
| **Validation rules** | Declares each verification check as a PASSED / FAILED / REVIEW\_REQUIRED condition with clear criteria |
| **Formulas** | Defines emission calculations and credit quantification formulas |
| **Data templates** | Specifies required data fields and formats for MassID documents and events |
| **Traceability matrix** | Maps every verification requirement to its data source, validation rule, and expected output |
| **Evidence policy** | Declares per-event which evidence is accepted digitally and which requires audit or inspection, with escalation triggers |
| **Escalation triggers** | Defines conditions (inconsistency, absence, anomaly) that escalate verification from automated to human review |
## Design for verification [#design-for-verification]
The MvF is written with a core principle: **design for verification**. Every rule, criterion, and parameter must be expressed so that someone — whether the [MvA](/docs/standard/concepts/mva) in automated execution or an auditor in independent review — can determine, based on evidence, whether the requirement was met.
This means:
* **No ambiguity** — No room for multiple interpretations
* **Event-structured** — What needs to be verified at each stage
* **Evidence-oriented** — What proves each requirement
* **Digitally compatible** — What the platform can validate automatically and what requires audit or inspection
## Traceability matrix [#traceability-matrix]
The MvF must include a **Traceability Matrix** as a mandatory artifact. This matrix connects every requirement from the validated third-party methodology to the corresponding operational element in the MvF.
For each requirement, the matrix maps:
**External requirement** (methodology section, version, clause) → **MvF section** → **Associated dMRV events** → **Required evidence** → **Planned validations** → **Expected outputs**
The matrix makes the methodological translation transparent and auditable — any reviewer can trace the complete path from the external reference to the operational implementation. It also reduces friction for the [MvA Developer](/docs/standard/concepts/mva), because it minimizes ambiguity during implementation.
For the full specification of what each MvF section must contain, see the [MvF Minimum Structure](/docs/standard/guides/mvf-minimum-structure) reference.
## Digital vs. audit evidence [#digital-vs-audit-evidence]
A robust dMRV requires clarity about how each requirement is proven. The MvF must explicitly declare the evidence regime, distinguishing:
* **Digital evidence** — Evidence whose robustness can be sustained by digital trails, metadata, and cross-event consistency, allowing deterministic validation by the MvA. Example: a weighing record with weight, unit, timestamp, geolocation, and balance type.
* **Audit/inspection evidence** — Evidence that, by its nature, criticality, or risk, cannot be confirmed with confidence through digital records alone. Example: physical facility conditions, material composition, instrument calibration.
The MvF specifies, for each event, which minimum metadata makes evidence acceptable, which digital validations apply, and which triggers escalate to audit. See the [MvF Minimum Structure](/docs/standard/guides/mvf-minimum-structure#inputs-evidence--evidence-policy) for the full evidence policy specification.
## How an MvF connects to the platform [#how-an-mvf-connects-to-the-platform]
The MvF is the authoritative specification that the platform implements:
1. Each validation rule in the MvF becomes an independent rule processor in the MvA — a Lambda function that evaluates [MassID](/docs/protocol/mass-ids) documents.
2. The orchestration engine routes incoming documents to the correct set of application rules (in the MvA) based on the methodology.
3. Each rule returns PASSED (with an explanation of what was verified), FAILED (with the specific reason), or REVIEW\_REQUIRED (when the check cannot be settled by code and needs a recorded human decision).
4. When all rules pass, MassIDs that pass methodology verification generate [Certificates](/docs/protocol/certificates), and matching [credits](/docs/protocol/credits) are issued.
The MvF establishes the contract: if the MvA faithfully implements every rule in the MvF, the platform's verification results are scientifically valid and auditable.
## The MvF Author role [#the-mvf-author-role]
MvF Authors are environmental scientists, methodology experts, or organizations with domain expertise in the methodology's environmental claim. Writing an MvF requires:
* Deep understanding of the environmental science and measurement approaches
* Familiarity with relevant international standards (e.g., UNFCCC CDM methodologies, IPCC guidelines)
* Ability to translate scientific requirements into discrete, testable rules
* Knowledge of the [Carrot dMRV Standard](/docs/standard) requirements
An MvF Author produces three deliverables: the framework document itself, a traceability matrix linking every requirement to verification logic, and verification guidelines for [Network Integrators](/docs/protocol/network-integrators).
See the [MvF Author Guide](/docs/standard/guides/mvf-author-guide) for the step-by-step process.
## Example: BOLD Recycling MvF [#example-bold-recycling-mvf]
The [BOLD Recycling](/docs/methodologies/bold-recycling) methodology's MvF (v1.0.1) demonstrates these components in practice:
* **Scope**: Organic waste diversion from landfills to aerobic composting in Brazil
* **Eligibility**: [Network Integrators](/docs/protocol/network-integrators), [processors](/docs/protocol/supply-chain), and [recyclers](/docs/protocol/supply-chain#the-role-of-the-recycler) must hold an approved accreditation valid on the evaluation date; a [waste generator's](/docs/protocol/supply-chain) accreditation is optional — verified when present; [haulers](/docs/protocol/supply-chain) require no accreditation
* **Validation rules**: Rules covering document validation, actor identification, weighing, geolocation, manifests, accreditation, and integrity checks
* **Formulas**: Credit quantification based on verified composted mass
* **Traceability**: Every rule links to a specific section of the framework document
See the full [BOLD Recycling rules catalog](/docs/methodologies/bold-recycling/framework/application/application-rules) and [framework specification](/docs/methodologies/bold-recycling/framework).
## Geographic adaptability [#geographic-adaptability]
A single methodology can apply to multiple territories — and in most cases, it will. The scientific basis and core quantification logic remain the same, but the regulatory context, material classifications, documentation requirements, and technical parameters vary by region. The MvF is designed to accommodate this variation from the start rather than hard-coding assumptions from a single jurisdiction.
The guiding principle is **design for adaptability**: the MvF separates universal elements (valid for any territory) from elements that must be parameterized per geography, allowing the framework to maintain structural integrity while accommodating necessary variations through a companion artifact: the **[Geographic Annex](/docs/glossary#geographic-annex)**.
### Why geographic adaptability matters [#why-geographic-adaptability-matters]
Adaptability manifests across four dimensions:
1. **Regulatory** — Each territory has its own legal framework governing the methodology's activity. Environmental licensing, operational permits, and compliance obligations differ by jurisdiction. A rule that says "the participant must hold a valid environmental license" cannot be implemented deterministically at global scale unless the MvF specifies that the license type, issuing authority, and validation fields come from a territorial source.
2. **Material classification** — Waste taxonomies are local: Brazil uses the Lista Brasileira de Resíduos Sólidos, the EU uses the European List of Waste (6-digit codes), the US uses RCRA categories. An eligibility rule referencing "official waste classification" is universal in intent but territorial in operationalization.
3. **Technical parameters** — Emission factors, climatic coefficients, infrastructure standards, and reference values vary by geography. A methane prevention methodology may use factors from a national GHG inventory or IPCC defaults — the choice directly impacts credit quantities.
4. **Evidence and documentation** — Documents that support the chain of custody differ by country. The Brazilian MTR (Manifesto de Transporte de Resíduos) has no equivalent name or structure in other jurisdictions. The MvF must specify the functional requirement and delegate the formal document specification to the Geographic Annex.
### Universal vs. territorial elements [#universal-vs-territorial-elements]
Each MvF element is classified as:
* **Universal** — Definition and verification conditions are jurisdiction-independent. Examples: "recorded weight must be greater than zero," "each [MassID](/docs/protocol/mass-ids) must reference exactly one [recycler](/docs/protocol/supply-chain#the-role-of-the-recycler)," "composting interval must be between 60 and 180 days." These derive from the methodology's logic, not local legislation.
* **Territorial** — Intent is universal, but operationalization depends on local context. Examples: "participant must hold a valid environmental license" (license type is territorial), "waste must belong to the eligible subtypes list" (classification codes are territorial), "transport manifest must be present" (document format is territorial).
When an element is classified as territorial, the MvF must provide: the **functional requirement** (what the rule demands in terms of outcome, regardless of territory) and the indication that the **operational specification** will be detailed in the applicable Geographic Annex. Optionally, a default value applies when no annex exists for that territory.
### Authoring for adaptability [#authoring-for-adaptability]
Three habits produce adaptable MvFs:
1. **Write rules in functional terms first** — Instead of "the participant must hold a Licença Ambiental de Operação issued by the competent state environmental agency" (operational, Brazil-specific), write "the participant must hold a valid environmental operating license issued by the competent authority in the territory of application, as specified in the applicable Geographic Annex." The first works only in Brazil; the second works anywhere.
2. **Classify every element in tabular artifacts** — The Validation Rules Table, Calculations & Parameters Table, and Evidence Policy must include a **Geographic Scope** column (`Universal` or `Territorial`). This tells the [MvA Developer](/docs/standard/concepts/mva) which rules are fixed and which must consult the Geographic Annex for local values.
3. **Declare Geographic Annex interface points** — In every MvF section containing territorial elements, indicate what the annex must provide. For example, in the Eligibility section: "the applicable Geographic Annex must specify the required environmental license type, the issuing authority, the validation fields, and the acceptable validity period."
### Geographic Annexes [#geographic-annexes]
A [Geographic Annex](/docs/glossary#geographic-annex) contextualizes the MvF for a specific territory. It is built separately from the framework, can be added, updated, or replaced without modifying the MvF, and is designed to be self-contained — the MvF plus a Geographic Annex forms a complete, implementable specification for a given market.
A typical annex covers seven adaptation dimensions:
1. Regulatory and legislative mapping for the methodology's activity
2. Material classification with translation between local taxonomy and MvF categories
3. Operational compliance requirements (licenses, permits, reporting obligations)
4. Additionality and baseline analysis in the territorial context
5. Technical parameter adaptation (emission factors, climatic coefficients, local reference values)
6. Territorial eligibility criteria (translating MvF functional requirements into local operational requirements)
7. Interoperability mapping with local systems (transport manifests, environmental registries, reporting infrastructure)
For example, a composting methodology might have:
* A **Brazil annex** — covering [Ibama](/docs/glossary#ibama) licensing, MTR transport manifests, and the Brazilian solid-waste classification system
* An **EU annex** — mapping to the Waste Framework Directive and the European List of Waste
* A **US annex** — referencing EPA regulations, state-level permitting, and RCRA waste categories
Each annex adapts the same core verification logic to local requirements without modifying the framework itself.
### Impact on artifacts [#impact-on-artifacts]
The geographic scope classification impacts MvF tabular artifacts:
| Artifact | Added column | Values | Purpose |
| ------------------------------- | ------------------------------- | ----------------------- | ----------------------------------------------------------------------------------------------- |
| Validation Rules Table | Geographic Scope | Universal / Territorial | Indicates whether the verified condition and values are fixed or depend on the Geographic Annex |
| Calculations & Parameters Table | Geographic Scope | Universal / Territorial | Indicates whether parameter values are fixed or vary by territory |
| Evidence Policy | Geographic Scope | Universal / Territorial | Indicates whether the evidence type or document is fixed or depends on the Geographic Annex |
| Completeness Checklist | Geographic Adaptability section | Yes / No / N/A | Verification items on whether the MvF provides universal/territorial separation |
When an element is marked "Territorial" in the Rules Table, the MvA developer knows the implementation must consult a territorial data source — instead of hardcoding a value, they create a parameterizable reference. When a parameter is marked "Territorial" in the Calculations Table, the MvF may provide a default (typically the IPCC or most conservative value), but the MvA must be capable of substituting the territorial value when available.
For the full specification of how geographic adaptability is structured in each MvF section, see the [MvF Minimum Structure](/docs/standard/guides/mvf-minimum-structure) reference.
[Learn about MvA](/docs/standard/concepts/mva) · [Learn about the Carrot dMRV Standard](/docs/standard)
### Diagram: mvf-construction-cycle
This MvF construction cycle groups sections 3.4.1 through 3.4.8 into Framing, Operationalization, and Quantification and Result. Scope, reference, and eligibility feed events, evidence, and rules; calculations lead to outputs and the traceability matrix. The dashed feedback edge shows the matrix keeps the framework traceable back to the methodology.
### Diagram: validation-rules-taxonomy
This taxonomy starts from MvF Validation Rules and divides them into Structure, Methodology, and Audit categories. Each column explains what is checked, gives examples such as required fields, eligible subtypes, distance traveled, geolocation, and duplicate verification, and shows the typical action: rejection, block, flagging, or review based on rule type.
# Credit Calculator
## Overview [#overview]
Use the Credit Calculator to estimate [`C-CARB.CH4`](/docs/protocol/credits#tokenized-carbon-credits-tcc) carbon credits and [`C-BIOW`](/docs/protocol/credits#tokenized-recycling-credits-trc) recycling credits generated from organic waste composting. `C-CARB.CH4` is a Tokenized Carbon Credit (TCC) issued under [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon); `C-BIOW` is a Tokenized Recycling Credit (TRC) issued under [BOLD Recycling](/docs/methodologies/bold-recycling). TCC and TRC are the broader credit categories, while the symbols identify these specific credits.
Select a baseline scenario, waste type, and volume to see projected credit quantities, the paired-pricing calculation, the effective value per `C-BIOW`, and an illustrative distribution of the combined proceeds.
The organic-waste distribution shown assumes a confirmed [Waste Manager](/docs/protocol/supply-chain#waste-manager) relationship. The table
explains how the 4% share returns to the Hauler, Processor, and Recycler when no relationship is
confirmed.
## How paired pricing works [#how-paired-pricing-works]
The calculator models a commercial bundle: it values the `C-BIOW` leg together with each `C-CARB.CH4`. The US$ 153.53 combined reference is a pricing projection, not a change to the [purchase-order contract](/docs/protocol/credit-purchase), which continues to identify the credit type and amount.
| Pricing component | Reference value | Applied to |
| ------------------ | --------------: | -------------------------------------------------- |
| `C-CARB.CH4` | US$ 120.00 | Each `C-CARB.CH4` sold |
| `C-BIOW` value leg | US$ 33.53 | Each `C-CARB.CH4` sold, not each physical `C-BIOW` |
| Combined | US$ 153.53 | Each `C-CARB.CH4` sold with proportional `C-BIOW` |
The emission coefficient determines how many `C-BIOW` accompany each `C-CARB.CH4`. Therefore, the effective value per physical `C-BIOW` is `US$33.53 × emission coefficient`. The comparison table in the calculator applies this formula to every supported waste type for the selected baseline scenario.
## Related resources [#related-resources]
* [Emission calculation parameters](/docs/methodologies/ams-iii-f/bold-carbon#emission-calculation-parameters) — detailed calculation methodology behind credit generation
* [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) — methodology for methane reductions
* [BOLD Recycling](/docs/methodologies/bold-recycling) — methodology for organic waste diversion
* [Rewards Distribution Policy](/docs/standard/policies/rewards-distribution) — how proceeds are distributed across participants
# MvA Developer Guide
## Who is this guide for? [#who-is-this-guide-for]
This guide is for developers implementing methodology rules for the [Carrot Network](/docs/network). It covers how to build a [Methodology Verification Application (MvA)](/docs/standard/concepts/mva) — the software that evaluates [MassID](/docs/protocol/mass-ids) documents against a [Methodology Verification Framework (MvF)](/docs/standard/concepts/mvf) specification.
## Prerequisites [#prerequisites]
* Proficiency with the monorepo's programming language and tooling
* Understanding of serverless function patterns
* Familiarity with digital MRV ([dMRV](/docs/protocol/dmrv)) concepts and the MvF specification you are implementing
* Knowledge of the [Carrot dMRV Standard](/docs/standard) requirements for MvA developers
## Repository and tooling [#repository-and-tooling]
The [methodology rules](/docs/standard/concepts/mvf) are implemented in an open-source monorepo:
* **Repository**: [github.com/carrot-foundation/methodology-rules](https://github.com/carrot-foundation/methodology-rules)
* **License**: LGPL-3.0
Refer to the repository README for setup instructions, dependency installation, and local development configuration.
## Architecture overview [#architecture-overview]
The codebase follows a two-layer architecture:
* **Shared rule libraries** — Contain the actual verification logic. Shared rule processors are reused across all BOLD methodologies. Each rule is an independent module with its own tests.
* **Methodology application wrappers** — Thin deployment layers that wrap shared libraries as serverless functions. Each methodology deploys its own set of rules, including any methodology-specific rules.
This separation means common rules (such as actor identification, weighing, or geolocation) are implemented once and reused, while methodology-specific rules (such as emissions calculations) are isolated to their target methodology.
## Implementing a rule [#implementing-a-rule]
### Step 1: Create the project [#step-1-create-the-project]
Each rule lives in its own project directory with a standard file structure. The project metadata includes tags for discoverability and categorization within the monorepo.
### Step 2: Implement the processor [#step-2-implement-the-processor]
Every rule implements the rule processor pattern — a standardized interface with five methods:
1. **`process()`** — Entry point that orchestrates the evaluation.
2. **`generateDocumentQuery()`** — Builds the query to fetch the MassID document and related data.
3. **`collectDocuments()`** — Fetches the documents needed for evaluation.
4. **`getRuleSubject()`** — Extracts the specific data elements the rule needs to evaluate.
5. **`evaluateResult()`** — Applies the verification logic and returns PASSED, FAILED, or REVIEW\_REQUIRED with an explanation.
The explanation in `evaluateResult()` is critical — it must state what was verified and why the result is PASSED, FAILED, or REVIEW\_REQUIRED. For an escalated result it must say what the rule could not settle, because that explanation is what the reviewer decides on. These explanations form the audit trail.
### Step 3: Write tests [#step-3-write-tests]
Every rule must have comprehensive test coverage:
* **Unit tests** — Test individual methods and edge cases.
* **Integration tests with seed documents** — Test the full evaluation flow with realistic MassID documents.
* **End-to-end tests** — Test the deployed function in an environment that mirrors production.
### Step 4: Create the app wrapper [#step-4-create-the-app-wrapper]
For each methodology that uses the rule, create a thin application wrapper that instantiates the shared library processor and exports it as a serverless function.
## Design principles [#design-principles]
All rule implementations must follow these principles:
* **Fidelity** — The code must faithfully implement every rule in the MvF specification. The logic in `evaluateResult()` must match the specification exactly.
* **Traceability** — Every result, whether PASSED, FAILED, or REVIEW\_REQUIRED, must reference the specific data that was evaluated, enabling independent verification of the outcome.
* **Determinism** — The same input must always produce the same output. No randomness, no dependence on external state that could change between runs.
## Testing requirements [#testing-requirements]
Before a rule can be deployed to production:
* All unit tests must pass
* Integration tests must cover the main PASSED and FAILED scenarios, and every REVIEW\_REQUIRED escalation the framework defines
* End-to-end tests must demonstrate the rule works in a production-like environment
* The rule must match the corresponding MvF specification entry in the traceability matrix
## Deployment [#deployment]
Rules are deployed as serverless functions through the monorepo's build and deployment pipeline. Each methodology defines which rules are included in its deployment configuration.
See the repository documentation for deployment procedures and environment configuration.
[Learn about MvA](/docs/standard/concepts/mva) · [Learn about the MvF Author Guide](/docs/standard/guides/mvf-author-guide)
# MvF Author Guide
## Who is this guide for? [#who-is-this-guide-for]
This guide is for environmental scientists, methodology experts, and organizations proposing new digital MRV ([dMRV](/docs/protocol/dmrv)) methodologies for the [Carrot Network](/docs/network). It walks through the process of writing a [Methodology Verification Framework (MvF)](/docs/standard/concepts/mvf) from scratch.
## Prerequisites [#prerequisites]
For the complete specification of what an MvF must contain — section by section — see the [MvF
Minimum Structure](/docs/standard/guides/mvf-minimum-structure) reference.
Before writing an MvF, you should have:
* Domain expertise in the environmental claim your methodology addresses
* Understanding of dMRV concepts and the [Carrot dMRV Standard](/docs/standard)
* Familiarity with the [methodology catalog](/docs/methodologies) and existing methodologies
* Knowledge of relevant international standards (e.g., UNFCCC CDM methodologies, IPCC guidelines)
## Deliverables [#deliverables]
An MvF submission includes four deliverables:
1. **Framework document** — The complete specification defining scope, eligibility, validation rules, formulas, and data requirements.
2. **Traceability matrix** — A structured mapping from every verification requirement to its data source and expected output.
3. **Verification guidelines** — Instructions for [Network Integrators](/docs/protocol/network-integrators) on what data to collect and how to submit [MassID](/docs/protocol/mass-ids) documents.
4. **Evidence policy** — A per-event specification of required evidence artifacts, provenance and retention expectations, digital vs. audit acceptance, and escalation triggers.
## Step 1: Define the framework [#step-1-define-the-framework]
Start by defining the core boundaries of your methodology:
* **Scope** — Which waste types, treatment methods, and geographic regions does the methodology cover? Be specific about included and excluded materials.
* **Eligibility criteria** — Which participants, facilities, and activities qualify? Define requirements for [waste generators](/docs/protocol/supply-chain), [haulers](/docs/protocol/supply-chain), [processors](/docs/protocol/supply-chain), and [recyclers](/docs/protocol/supply-chain).
* **Environmental claim** — What is the measurable impact? (e.g., tons of waste diverted, CO2e reductions)
The scope definition must not overlap with existing methodologies. See the [Colliding Methodologies](/docs/standard/policies/colliding-methodologies) policy.
## Step 2: Specify validation rules [#step-2-specify-validation-rules]
Each verification check must be defined as a rule with clear PASSED / FAILED / REVIEW\_REQUIRED criteria:
* **Rule name** — A descriptive identifier (e.g., `weighing`, `driver-identification`)
* **What it verifies** — The specific data element or condition being checked
* **PASSED condition** — The exact criteria that must be met, with no ambiguity
* **FAILED condition** — What causes the rule to fail, with specific error explanations
* **REVIEW\_REQUIRED condition** — When the rule cannot be settled from the submitted data alone and must escalate to a recorded human decision. State the criteria explicitly; a rule that defines no escalation condition never produces one.
Reference existing framework rules in the [methodology catalog](/docs/methodologies) for patterns. Many common verifications (actor identification, weighing, geolocation) already have established framework-level definitions that can serve as templates.
Rules fall into three categories:
* **Structure rules** — Verify formal integrity and data completeness (e.g., required fields present, correct units). These are methodology-independent.
* **Methodology rules** — Verify conformity with the methodology's criteria and parameters (e.g., eligible waste type, distance within project boundary).
* **Audit rules** — Verify cross-event consistency and behavioral patterns that require deeper analysis (e.g., cumulative mass limits, duplication checks).
For the full 12-field rule specification, see [Validation Rules & Controls](/docs/standard/guides/mvf-minimum-structure#validation-rules--controls).
## Step 3: Create the traceability matrix [#step-3-create-the-traceability-matrix]
The traceability matrix links every verification requirement to its data source and expected outcome:
| Requirement | Data source | Expected output |
| ----------------------------- | --------------------- | ------------------------------------------- |
| Waste generator is identified | MassID OPEN event | PASSED: waste origin consistent with events |
| Weight is verified | MassID WEIGHING event | PASSED: net weight validated |
| … | … | … |
This matrix ensures completeness — every requirement has a corresponding data source and verifiable outcome. The [MvA](/docs/standard/concepts/mva) will later implement each requirement as executable application rules.
## Step 4: Write verification guidelines [#step-4-write-verification-guidelines]
Verification guidelines tell Network Integrators what data to collect and submit:
* Which [supply chain](/docs/protocol/supply-chain) events are required (pick-up, drop-off, weighing, recycling)
* What attributes each event must include
* Which documents and attachments are needed (manifests, accreditation certificates)
* Data format and submission requirements via the [API](/docs/integrations/api)
## Step 5: Submit for review [#step-5-submit-for-review]
Submit the complete MvF package (framework document, traceability matrix, verification guidelines, and evidence policy) to the [Carrot Foundation](/docs/network/the-foundation) for review.
The review process includes:
1. **Completeness check** — Verifying all deliverables are present and well-structured
2. **Standard compliance** — Ensuring alignment with the Carrot dMRV Standard
3. **Community review** — The Community of Experts evaluates scientific rigor, feasibility, and potential collisions
4. **Approval** — The Foundation approves the methodology for MvA development
## Quality criteria [#quality-criteria]
A strong MvF submission demonstrates:
* **Completeness** — Every aspect of the verification is specified, with no gaps in the traceability matrix
* **Clarity** — Rules are unambiguous and can be implemented as deterministic code
* **Testability** — Every rule can be validated with concrete test cases
* **No collision** — The scope does not overlap with existing methodologies
* **Standard compliance** — All Carrot dMRV Standard requirements are met
These five criteria summarize the key expectations. For the complete six-dimension quality framework used during MvF accreditation — including the evaluation process, review cycles, and non-conformity typology — see [Quality Criteria & Accreditation](/docs/standard/policies/quality-and-accreditation).
Feedback and methodology proposals: [method@carrot.eco](mailto:method@carrot.eco)
[Learn about MvF](/docs/standard/concepts/mvf) · [MvA Developer Guide](/docs/standard/guides/mva-developer-guide)
# MvF Minimum Structure
## Overview [#overview]
This page defines the minimum structure a [Methodology Verification Framework (MvF)](/docs/standard/concepts/mvf) must contain to be implementable, auditable, and governable within Carrot's digital MRV ([dMRV](/docs/protocol/dmrv)) ecosystem. The intention is not to force every methodology into a single rigid format, but to ensure that any framework submitted to the ecosystem includes the essential building blocks for consistent digital execution, evidence package formation, technical validation, and standardization.
The structure below serves as a reference for [MvF Authors](/docs/standard/concepts/mvf#the-mvf-author-role), as a basis for internal evaluation by the Operations & Methodologies team, and — in the future — for RFP processes and community review. Every section follows the **design for verification** principle: each requirement must be expressed so that either the [MvA](/docs/standard/concepts/mva) (in automated execution) or an auditor (in independent verification) can answer, based on evidence, whether the requirement was met.
The eight mandatory sections are:
1. [Scope & concept](#scope--concept)
2. [Methodological reference & registry](#methodological-reference--registry)
3. [Eligibility, criteria & exclusions](#eligibility-criteria--exclusions)
4. [dMRV events & event catalog](#dmrv-events--event-catalog)
5. [Inputs, evidence & evidence policy](#inputs-evidence--evidence-policy)
6. [Validation rules & controls](#validation-rules--controls)
7. [Calculations, formulas & parameters](#calculations-formulas--parameters)
8. [Outputs & digital evidence package](#outputs--digital-evidence-package)
***
## Scope & concept [#scope--concept]
The MvF must begin by establishing, transparently, which environmental problem or purpose the dMRV addresses and what impact-generation mechanism will be quantified and reported. This section defines the "conceptual contract" of the framework: what it measures, under what conditions, and with which boundaries. Without this framing, subsequent criteria and calculations become open to interpretation and difficult to verify.
The author must describe the scope of the dMRV, including:
* **Problem and purpose** — The environmental problem being addressed and the specific impact mechanism the methodology quantifies.
* **System boundary** — Which activities, process stages, or flows are included in the quantification — and which are explicitly excluded and why — in alignment with the validated third-party methodology.
* **Quantification unit** — The unit of measurement and the type of output expected in the applicable methodological context (e.g., tCO2e of emission reductions, tons of recycled material). The goal is not to invent parameters but to state what will be accounted for and how it connects to the methodological reference.
* **Output type** — Whether the methodology produces [credits](/docs/protocol/credits), [certificates](/docs/protocol/certificates), or both, and under what conditions.
* **Applicability context** — Sector, type of operation, geographic scope, minimum operational conditions, and any critical assumptions that constrain the framework's validity. This delimitation is essential for integrity — it prevents the dMRV from being applied outside the context for which it was designed.
**Expected outcome**: by the end of this section, any technical reader should be able to answer: *"What does this dMRV measure, in which context does it apply, what is its boundary, and what output does it intend to produce according to the validated reference methodology?"*
***
## Methodological reference & registry [#methodological-reference--registry]
After defining scope and concept, the MvF must declare with precision **which validated third-party methodology** underpins the dMRV. This is critical for integrity and auditability: the framework cannot "float" without external anchoring and validation, because it is precisely this methodological reference that delimits assumptions, quantification logic, evidence requirements, and validity conditions.
The author must identify the reference methodology with enough detail to eliminate ambiguity, including:
* Official name, version, date, and responsible entity
* A permanent identifier or stable public reference (e.g., a permanent link or equivalent publication record)
* Relevant annexes, tables, appendices, or superseding versions that affect calculations
Beyond pointing to the source, the MvF must make clear how the methodology will be operationalized within the framework. This is not about repeating the methodology's content but about explaining the relationship between the external reference and the MvF: which methodology sections are materially relevant, which requirements will be translated into events, rules, and formulas, and which dependencies are assumed. This narrative context prepares the reader for the Traceability Matrix, which provides the structured requirement-by-requirement mapping.
An important aspect is recording **interoperability boundaries**: what the MvF assumes as an external prerequisite (e.g., methodology validation, macro eligibility decisions, participant accreditation processes, registry rules) versus what is executed by the dMRV on the platform (operational rules, digital validations, evidence, and auditable outputs). This separation keeps documentation consistent with Carrot's positioning as a dMRV orchestration platform.
**Expected outcome**: by the end of this section, it should be unambiguous which external methodology underpins the dMRV, which dependencies and boundaries apply, and whether a registry is related — including the registry's role and the boundary between what is external and what the dMRV executes.
***
## Eligibility, criteria & exclusions [#eligibility-criteria--exclusions]
Defining eligibility criteria, exclusions, and exceptions is one of the most sensitive steps in building an MvF. Poorly formulated criteria produce two types of problem: either they allow participants and processes that compromise credit integrity, or they unduly exclude legitimate operations that meet the methodology's objectives.
The guiding principle is **design for verification**: every eligibility criterion must be described so that someone — whether the [MvA](/docs/standard/concepts/mva) in automated execution or an auditor in independent verification — can answer, based on evidence, whether the requirement was met, without room for subjective interpretation.
### Verifiable vs. narrative criteria [#verifiable-vs-narrative-criteria]
The difference between a narrative criterion and a verifiable criterion is the difference between intention and operationality.
A **narrative criterion** declares a condition generically:
> The participant must hold a valid environmental license.
This communicates intent but does not guide verification: what does "valid" mean? Which document proves it? Which field or metadata should be validated? What is the rejection rule? Is there an exception?
A **verifiable criterion** describes the same condition in terms that allow objective validation:
> The participant must submit an environmental license issued by the competent authority, with an expiration date equal to or later than the monitoring period start date. The system must verify the presence of the 'expiration date' field and compare it to the period's reference date. If the license is expired or the field is absent, the participant is blocked from proceeding in the accreditation flow.
When writing each criterion, the MvF Author should ask: *"If I hand only this text to the developer, can they implement the validation without consulting me?"* If the answer is no, the criterion needs refinement.
### Three layers of eligibility [#three-layers-of-eligibility]
The MvF must organize its criteria into three distinct layers:
**1. Participant eligibility** — Minimum requirements that each participant type ([waste generator](/docs/protocol/supply-chain), [hauler](/docs/protocol/supply-chain), [processor](/docs/protocol/supply-chain), [recycler](/docs/protocol/supply-chain)) must meet to be accredited and operate within the dMRV. These typically involve:
* Legal and regulatory documentation (licenses, permits, registrations)
* Demonstrable operational capacity (installed capacity, equipment, technical certifications)
* Geographic location (when the methodology has a territorial scope)
* Registration ties or impediments (conflicts of interest, non-compliance history, regulatory restrictions)
**2. Material and process eligibility** — Which waste types, activities, or operational flows the dMRV accepts. This definition must be precise enough to avoid ambiguity. Instead of "Organic Waste," the framework should specify accepted categories by official classification code, acceptance conditions with contamination limits, source-separation requirements, and any applicable restrictions (e.g., exclusion of hazardous waste or waste from specific industrial origins).
**3. Exclusions and exceptions** — Exclusions are conditions that definitively prevent approval, regardless of other criteria being met. Exceptions are atypical but documented situations in which a standard criterion may be relaxed under specific conditions. The distinction matters: exclusions are absolute (if the exclusion criterion is triggered, there is no alternative path), while exceptions must be accompanied by justification, additional evidence, and — when applicable — formal approval.
### Conditional and contextual criteria [#conditional-and-contextual-criteria]
In many methodologies, eligibility criteria are not uniform — they vary by application context. For example, a methodology with broad geographic coverage may have different requirements by country or region due to regulatory or infrastructure differences. The MvF must explicitly declare which criteria are **universal** (applicable to all participants and contexts) and which are **conditional** (applicable only under certain circumstances), identifying the trigger that activates each condition.
Similarly, criteria may have temporality: a requirement that applies at initial accreditation may differ from a maintenance or renewal requirement. The framework must make clear at which point in the cycle each criterion is verified and with what frequency.
The Municipal Organic Composting (COM) example used throughout this page is fictional and
simplified for didactic purposes. It does not represent any real methodology operated by the
Carrot platform and should not be used as a technical reference for MvF development.
In the fictional COM example, the eligibility of a composting facility would be described as follows:
Composting facilities are eligible for this methodology if they cumulatively meet the following criteria: the facility must operate an aerobic composting process (windrows, composters, or aerated reactors); it must hold a valid operating environmental license issued by the competent environmental authority; it must be located in Brazilian territory; its declared operational capacity at accreditation must not exceed 60,000 metric tons per 12-month period; and the facility must have a calibrated scale accredited by INMETRO for weighing received waste.
**Exclusions:**
* Facilities that operate anaerobic digestion as the primary treatment method (scope of a different methodology)
* Facilities that receive waste classified as hazardous under the applicable standard
* Facilities whose weighted average distance between collection point and receiving point exceeds 200 km (project boundary limit defined by the reference methodology)
**Exception:** Facilities operating a mixed process (aerobic composting with an initial short-duration anaerobic biostabilization phase of less than 72 hours) may be accepted provided the anaerobic phase is documented, monitored, and accounted for in emission calculations, with technical evidence that the predominant process is aerobic. This exception must be recorded at accreditation and flagged for additional audit.
**Expected outcome**: by the end of this section, any technical reader — including the MvA developer and the auditor — should be able to answer, for each participant and material type: *"Is this candidate eligible?" "Under what conditions?" "What prevents them?"* and *"Is there an applicable exception?"* — without consulting the framework's author.
***
## dMRV events & event catalog [#dmrv-events--event-catalog]
In Carrot's dMRV ecosystem, the **event** is the fundamental unit of verification. A dMRV event represents an operationally relevant occurrence in the [supply chain](/docs/protocol/supply-chain) flow that must be recorded, verified, and traced. It is at the event level that inputs (data and documents) gain meaning, validations are applied, evidence is generated, and the audit trail is built.
If the MvF were a building blueprint, the event catalog would be the detailed list of every construction step, with required materials, mandatory checks, and acceptance criteria for each phase. Without this list, the [MvA](/docs/standard/concepts/mva) developer receives a blueprint without execution instructions, and the auditor does not know which points to inspect.
### How to identify relevant events [#how-to-identify-relevant-events]
The first step in building the catalog is identifying all events that compose the operational flow for the methodology. The author should map the complete journey of the tracked object (a waste item, a batch, an activity) from origin to final disposition or transformation, considering every movement, action, and intervention it may undergo.
Each point in the flow where one of the following situations occurs potentially constitutes a dMRV event:
* **Custody transfer** — The object changes responsible party or location (e.g., collection, transport, delivery)
* **Transformation or processing** — The object undergoes physical, chemical, or classification change (e.g., sorting, composting, recycling)
* **Measurement or recording** — A measurement is taken or a document is generated (e.g., weighing, temperature measurement, manifest or certificate issuance)
* **Verification or audit** — A rule is applied and a result is recorded (e.g., [MassID](/docs/protocol/mass-ids) audit, credit issuance)
* **Decision or classification** — The object is classified, accepted, rejected, or reclassified based on framework criteria
### Granularity guidance [#granularity-guidance]
Event granularity is a framework design decision. Events that are too aggregated (e.g., "processing" as a single event) lose verification power because they bundle steps that could be validated separately. Events that are excessively granular (e.g., each minute of windrow turning as a separate event) create operational complexity without proportional integrity gains. The ideal balance is granularity sufficient for each event to represent a **meaningful verification checkpoint** — a moment when something verifiable happens and evidence must be recorded.
### Standard event description table [#standard-event-description-table]
For each identified event, the MvF must provide a structured description containing at minimum the following elements:
| Element | Description | Purpose |
| --------------------------- | --------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| **Identifier** | Unique event code in the catalog (e.g., EVT-001) | Traceability and cross-reference |
| **Name** | Descriptive, standardized name (e.g., Pick-up, Weighing, Drop-off) | Clear communication between author, developer, and auditor |
| **Objective** | What this event proves or records in the flow | Contextualizes the event in the methodology's logic |
| **Flow stage** | Position of the event in the operational sequence | Reveals dependencies and execution order |
| **Responsible participant** | Who is responsible for executing or recording the event | Defines accountability and custody link |
| **Required inputs** | Data and documents that must be provided, with minimum metadata | Basis for validation — detailed in [Inputs, evidence & evidence policy](#inputs-evidence--evidence-policy) |
| **Validation rules** | Checks the MvA must execute to accept/reject the event | Basis for implementation — detailed in [Validation rules & controls](#validation-rules--controls) |
| **Generated outputs** | What the event produces as a recordable result | Composes the digital evidence package |
| **Dependencies** | Prior events that must be completed, or subsequent events that depend on this one | Ensures logical sequence and temporal integrity |
| **Evidence regime** | Whether verification is digital (automated) or requires audit/inspection | Guides the developer and auditor on the verification level |
The Municipal Organic Composting (COM) example used throughout this page is fictional and
simplified for didactic purposes. It does not represent any real methodology operated by the
Carrot platform and should not be used as a technical reference for MvF development.
In the fictional COM example, the event catalog maps the complete journey of organic waste — from collection at the generator to composting completion and credit issuance:
| ID | Event | Summary description | Participant |
| ------- | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ |
| EVT-001 | Pick-up | Records the moment waste is collected from the generator by the hauler. Captures vehicle data, waste type, classification, and geolocation. | Generator / Hauler |
| EVT-002 | Transport manifest | Issuance or recording of the transport supporting document (MTR or equivalent). May include an exemption justification when applicable. | Generator / Hauler |
| EVT-003 | Weighing | Records the weighing of waste upon arrival at the composting facility. Includes gross weight, tare, scale type, and capture method. | Processor / Recycler |
| EVT-004 | Sorting | Records the sorting stage of received material, applying the sorting factor to deduct contaminants. Updates the net mass. | Processor / Recycler |
| EVT-005 | Drop-off | Records the effective delivery of waste at the composting facility, confirming custody transfer. Includes operator identification and destination (windrow/yard). | Processor / Recycler |
| EVT-006 | Recycling manifest | Issuance of the processing supporting document (CDF or equivalent), confirming the waste was effectively sent to composting. | Processor / Recycler |
| EVT-007 | Composting completed | Records the completion of the composting process, indicating waste was transformed into organic fertilizer. Completion date is estimated by a conservative criterion verified in audit. | Processor / Recycler |
| EVT-008 | MassID verification | Methodology rules execute against the mass document via Carrot's dMRV system, applying all validations to verify conformity and integrity. | Methodology rules / Carrot dMRV system (verification); third‑party auditors (accreditation where applicable) |
| EVT-009 | Credit issuance | Generates the auditable methodological output (e.g., GasID for carbon credits, RecycledID for recycling credits), linked to the verified MassID. | Methodology rules / Carrot dMRV system (verification); third‑party auditors (accreditation where applicable) |
This catalog is a didactic simplification. In a real MvF, each event would be accompanied by a detailed record with all elements described in the standard event description table (inputs, rules, outputs, dependencies). The following section explains how to fill in those details.
The event catalog is the primary handoff artifact between the MvF Author and the MvA Developer.
Its completeness and clarity directly determine implementation quality. An ambiguous or incomplete
catalog generates rework, author consultations, and risk of divergence between framework intent
and application execution.
***
## Inputs, evidence & evidence policy [#inputs-evidence--evidence-policy]
If events are the backbone of the dMRV, inputs and evidence are the substance that makes them verifiable. An **input** is the data or document that feeds an event; **evidence** is the record that proves the event occurred in conformity with the framework's rules. Without adequate inputs, the event cannot be validated. Without traceable evidence, the event cannot be audited.
### Input specification per event [#input-specification-per-event]
Each event in the catalog requires a set of inputs to be executed. When specifying these inputs, the author must go beyond a generic list of "required documents" and provide a complete operational description that enables both [MvA](/docs/standard/concepts/mva) implementation and auditor verification.
For each input, the MvF must declare:
* **Input type** — Structured data, digitized document, system record, signed declaration, etc.
* **Required fields or metadata** — For example, for a weighing event: gross weight, tare, net weight, scale type, capture method, date/time, geolocation.
* **Accepted formats and units** — For example, weight in kilograms, dates in ISO format, numeric values with up to two decimal places.
* **Acceptance conditions** — What makes the input valid (e.g., gross weight greater than zero, date within the monitoring period).
* **Rejection conditions** — What makes the input invalid and prevents the event from proceeding.
* **Exception conditions** — Which data points are desirable vs. mandatory, and acceptable flexibilities for initial projects or specific participant types.
The difference between a well-specified input and a vague one separates an implementable framework from one that depends on interpretation. For example, a vague specification for the Weighing event (EVT-003) would say "record the weighing data." An adequate specification would detail every expected field, its validation rules, and the behavior when a field is absent or inconsistent.
### Metadata requirements [#metadata-requirements]
Every input in dMRV must carry sufficient context to sustain traceability. This context is composed of metadata that answers the fundamental questions of the chain of custody:
* **Who** submitted (responsible participant identification)
* **When** (date and time of recording)
* **Where** (geolocation or linked address)
* **In which context** (associated event, flow stage)
* **Under which version** (of the MvF and MvA in execution)
The MvF must declare which metadata are **mandatory** (without which the input cannot be accepted) and which are **optional** (enriching traceability but not blocking validation). When in doubt, the recommendation is to treat the metadata as mandatory — it is easier to relax a requirement later than to create one retroactively.
### Evidence policy per event [#evidence-policy-per-event]
The Evidence Policy consolidates, event by event, how each requirement will be substantiated. It must distinguish two fundamental categories: evidence that can be accepted through **digital operational verification** (whose robustness can be sustained by the digital trail, metadata, and cross-event consistency) and evidence that, by its nature, criticality, or risk, requires **audit or additional inspection**.
For each event, the policy must record:
| Field | Description |
| ----------------------- | ------------------------------------------------------------ |
| **Evidence required** | What evidence must be provided |
| **Acceptance level** | Digital, audit, or both |
| **Minimum metadata** | Which metadata fields are required |
| **Digital validations** | Which automated checks are performed |
| **Escalation triggers** | Conditions that escalate the event to manual review or audit |
The Municipal Organic Composting (COM) example used throughout this page is fictional and
simplified for didactic purposes. It does not represent any real methodology operated by the
Carrot platform and should not be used as a technical reference for MvF development.
| Event | Evidence | Acceptance | Minimum metadata | Digital validations | Escalation triggers |
| ---------------------------- | ----------------------------------------------------------------- | ------------------------------------------------ | ------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- |
| EVT-001 Pick-up | Digital pick-up record with vehicle data and waste classification | Digital | Geolocation, date/time, vehicle plate, waste type, local classification, responsible participant | Geolocation within 2 km radius of accreditation address; classification within accepted subtype list | Geolocation outside radius; classification absent or inconsistent |
| EVT-003 Weighing | Weighing record with scale data | Digital + Audit (scale accreditation) | Gross weight, tare, net weight, scale type, capture method, date/time | Gross weight > 0; unit = kg; net weight = gross - tare; numeric consistency | Manual capture method without justification; scale without linked accreditation |
| EVT-004 Sorting | Sorting record with applied deduction factor | Digital + Audit (sorting factor) | Gross weight (in), deducted weight, net weight (out), applied sorting factor | Calculation: net weight = gross weight x (1 - sorting factor); factor within accreditation limits | Sorting factor above upper limit; calculation divergence |
| EVT-007 Composting completed | Completion record with estimated date | Digital + Audit (validated during accreditation) | Completion date, estimation method, responsible participant, batch/windrow reference | Interval between drop-off and completion between 60 and 180 days (per methodology parameter) | Interval outside range; batch traceability absent |
### Escalation trigger categories [#escalation-trigger-categories]
Escalation triggers are conditions that, when detected during digital verification, indicate that available evidence is insufficient to sustain conformity and that additional procedures (audit, inspection, supplementary evidence collection) are necessary. The MvF Author must define these triggers explicitly and link them to actions proportional to the identified risk.
Triggers typically fall into three categories:
* **Inconsistency** — Divergence between expected and provided data (e.g., a weighing that results in negative net weight, or a geolocation incompatible with the registered address).
* **Absence** — Missing mandatory metadata or required evidence (e.g., missing transport manifest without an exemption justification).
* **Anomaly** — Unusual pattern detected over time (e.g., volumes systematically exceeding declared capacity, or atypical frequency of exemptions).
For each trigger, the MvF must indicate the expected action: **event blocking** (preventing flow continuation until resolution), **flagging for operational review** (the event proceeds but is marked for analysis, and credit issuance is temporarily blocked), or **escalation to audit** (the event is forwarded for independent verification). The proportionality between trigger and action is a framework design decision that must consider the risk associated with the event and the materiality of the impact on credit integrity.
**Expected outcome**: a complete Evidence Policy organized event by event, enabling the MvA developer to implement all digital validations and the auditor to understand which points require additional verification.
***
## Validation rules & controls [#validation-rules--controls]
Validation rules are the operational mechanism that ensures conformity between participant-provided inputs and MvF-defined criteria. While the [event catalog](#dmrv-events--event-catalog) defines **what happens** and the [evidence policy](#inputs-evidence--evidence-policy) defines **what proves it**, validation rules define **how each input is verified** — which condition is tested, which standard is expected, what happens when the condition fails, and what evidence is recorded.
For the [MvA](/docs/standard/concepts/mva) developer, validation rules are the most directly implementable element of the entire MvF. Each well-specified rule translates into a code verification — a logical condition that produces a binary result (passed/failed) or an escalation (flagged for review).
### Rule taxonomy [#rule-taxonomy]
Operational experience with the BOLD methodologies suggests a practical classification of rules into three types:
**Structure rules** verify formal integrity and data completeness. These rules are methodology-independent — they ensure the information "packaging" is correct before the content is evaluated. Examples:
* All required fields are populated
* The unit of measurement is the expected one (kilograms)
* The numeric format is valid
* The document category matches expectations
* Participant identification metadata are present and consistent
**Methodology rules** verify conformity with the criteria and parameters defined in the scientific methodology and translated by the MvF. These rules depend on the framework's technical content. Examples:
* The waste type belongs to the list of eligible subtypes
* The distance between collection and destination does not exceed the project boundary limit
* The temporal interval between events falls within the acceptable range
* The project size does not exceed the eligibility threshold
**Audit rules** verify cross-event consistency and behavioral patterns requiring deeper analysis that cannot be fully resolved by simple deterministic verification. These rules typically involve comparison with accreditation data, cross-event checks, duplication detection, operational limit controls, and validations that generate flags for human review. Examples:
* The cumulative mass from a generator in the month does not exceed the declared cap
* The vehicle plate and drop-off date/time do not conflict with another [MassID](/docs/protocol/mass-ids)
* The fertilizer conversion coefficient is compatible with accreditation data
### 12-field rule specification [#12-field-rule-specification]
For each validation rule, the MvF must provide a specification that the developer can implement without interpretation and the auditor can verify independently:
| Element | Description |
| ---------------------------- | -------------------------------------------------------------------------------------------------------------- |
| **Execution order** | Position of the rule in the event's verification sequence (rules may depend on each other) |
| **Identifier** | Unique rule code (e.g., RV-001) |
| **Name** | Descriptive, standardized name |
| **Applicable event(s)** | Which event(s) from the catalog the rule applies to |
| **Condition verified** | What the rule tests — described in clear, unambiguous logical language |
| **Acceptance criterion** | The expected result for the validation to pass |
| **Description / Rationale** | Explanation of the rule's purpose and its relationship to dMRV integrity |
| **Rule type** | Structure, Methodology, or Audit |
| **Failure action** | What happens when the condition is not met: rejection, blocking, flagging, or escalation |
| **Exception case** | Whether exception situations apply, which trigger activates the exception, and whether this affects the output |
| **Generated evidence** | What is recorded in the audit trail as a result of rule execution |
| **Methodological reference** | Which section of the validated methodology or MvF supports the rule (when applicable) |
### Cross-event dependency rules [#cross-event-dependency-rules]
Some rules do not operate on a single isolated event but depend on information from multiple events or historical data. For example, a project distance limit rule (RV-008 in the COM example) crosses the geolocation from the pick-up event (EVT-001) with the geolocation from the drop-off event (EVT-005). Similarly, the generator mass cap rule (RV-009) accumulates information from all MassIDs of the same generator over the month.
When a rule depends on cross-event data, the MvF must explicitly declare: which events are crossed, which fields from each event are used, what the aggregation or comparison logic is, and at which point in the flow the cross-check is executed (at the target event, at the end of the period, or during MassID audit). This clarity is fundamental for deterministic implementation and reproducible auditing.
The Municipal Organic Composting (COM) example used throughout this page is fictional and
simplified for didactic purposes. It does not represent any real methodology operated by the
Carrot platform and should not be used as a technical reference for MvF development.
| ID | Name | Condition | Type | Failure action |
| ------ | ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | ----------- | --------------------------------------------------------------------- |
| RV-001 | Participant accreditation | All participants linked to the MassID must be accredited on the platform, with valid documentation and within the validity period. | Audit | MassID blocked until regularization |
| RV-002 | No prior credit | The MassID must not already have a credit of the same type linked (no duplicate TCC, no duplicate TRC), preventing double counting. | Methodology | MassID rejected for issuance |
| RV-003 | Eligible waste type | The waste subtype must belong to the methodology-approved list (organic waste per defined classification). | Methodology | Rejection: MassID blocked from generating credits |
| RV-004 | Document weight > 0 | The recorded weight value must be greater than zero. | Audit | Rejection |
| RV-005 | Unit of measurement = kg | The unit field must be declared as kilograms. | Structure | Rejection |
| RV-006 | Composting time interval | The difference between the Drop-off event and the Recycled event must be between 60 and 180 days. | Audit | Flagged for operational review |
| RV-007 | Geolocation accuracy | The pick-up geolocation must be within a 2 km radius of the address registered at accreditation. | Audit | Flagged; if GPS unavailable, validation via accreditation address |
| RV-008 | Project distance limit | The distance between collection point and receiving point must not exceed 200 km. | Methodology | Flagged for review; if > 200 km, mandatory transport emission offset |
| RV-009 | Generator mass cap | The cumulative mass from the same generator in the month must not exceed the monthly cap declared at accreditation (up to 20% tolerance). | Audit | Credit generation blocked until released by the operations department |
| RV-010 | Duplication check | There must not be two MassIDs with the same receiving date/time, same generator, same vehicle, and same recycling facility. | Audit | Duplicate mass rejected |
Note that each rule has a testable condition, a classified type, and a clear failure action. This is the minimum quality expected in an MvF's rule specification. Rules that merely say "verify the data is correct" do not meet the **design for verification** principle, because they define neither what "correct" means nor what happens when it is not.
***
## Calculations, formulas & parameters [#calculations-formulas--parameters]
Calculations and formulas are the quantitative core of the dMRV — they translate verified evidence into numerical results that ultimately support the generation of environmental [credits](/docs/protocol/credits). The way the MvF specifies its formulas determines not only the precision of results but also their reproducibility, auditability, and market credibility.
The central principle is **self-containment**: the MvF must provide the [MvA](/docs/standard/concepts/mva) developer with all information needed to implement each calculation without consulting the original scientific methodology or the framework's author. The MvF maintains traceability to the external reference, but the framework itself must contain all operational information needed for implementation and auditing.
### Per-formula specification [#per-formula-specification]
Each formula must be presented with a minimum set of information:
**Equation** — Expressed unambiguously with consistent notation throughout the framework. Variables must have descriptive, unique names (avoid using the same symbol for different quantities in different formulas). When the formula involves summations, conditions (if/then), or iterations, the logic must be spelled out step by step, not condensed into a single expression.
**Variables** — For each variable used in the formula, the MvF must declare:
* Symbol used
* Full variable name
* Unit of measurement
* Value source (input data, fixed parameter, result of another calculation, accreditation value)
* Application conditions (when the variable is used and when it is not)
* Limits or constraints (minimum/maximum values, valid domain)
**Fixed parameters** — Emission factors, conversion coefficients, and constants must be accompanied by their primary source (article, methodology, database), reference date, and conditions under which the value is valid. When a parameter varies by context (e.g., different emission factor per waste type or region), the MvF must provide the complete value table and the selection rule.
**Test scenarios** — A set of reference inputs with the expected result, allowing the developer to verify the implementation is correct. For example: *"If net weight = 14,949 kg, waste type = domestic sludge, and offset index = 0.85 tCO2e per ton, the expected GasID = 12.71 tCO2e."* Test scenarios reduce implementation error risk and are especially useful when formulas involve multiple variables or conditions.
The Municipal Organic Composting (COM) example used throughout this page is fictional and
simplified for didactic purposes. It does not represent any real methodology operated by the
Carrot platform and should not be used as a technical reference for MvF development.
In the fictional COM example, the primary calculation quantifies the methane reductions achieved by diverting organic waste from landfills to aerobic composting. A simplified version:
**PEcomp,y = PEEC,y + PEFC,y + PECH4,y + PEN2O,y + PERO,y**
Where each component represents, respectively: project emissions from energy consumption (PEEC), from fossil fuel consumption (PEFC), methane emissions from the composting process (PECH4), nitrous oxide emissions from composting (PEN2O), and methane emissions from process effluents (PERO). Each component would have its own detailed formula in the MvF.
For one variable — the offset index used to calculate the individual GasID for each [MassID](/docs/protocol/mass-ids) — the framework specification would be:
| Element | Specification |
| ------------------------- | ------------------------------------------------------------------------------------------------------------ |
| **Symbol** | IC |
| **Name** | Methane emission offset index |
| **Unit** | tCO2e / ton of processed organic waste |
| **Source** | Derived from reference methodology calculations, per waste type and recycler composting parameters |
| **Application condition** | Applied to the GasID calculation for each MassID after audit approval |
| **Calculation** | document\_value x IC = GasID (MassID carbon credits) |
| **Verification rule** | The IC used must match the value registered on the recycler's accreditation page for the MassID's waste type |
| **Test scenario** | If document\_value = 14,949 kg (14.949 t) and IC = 0.85 tCO2e/t, then GasID = 12.71 tCO2e |
This level of detail allows the developer to implement the calculation without ambiguity and the auditor to verify the result is correct for any audited MassID.
### Uncertainty and discount factors [#uncertainty-and-discount-factors]
When the reference methodology provides for uncertainty margins, conservative discount factors, or safety buffers, the MvF must describe them with the same precision applied to the main formulas:
* **Uncertainty calculation formula** (when quantifiable)
* **Discount factor applied** and its technical justification
* **Activation conditions** — Under which circumstances the discount is applied
* **Impact on the final result** — How the discount affects the quantity of credits generated
Discount factors are especially relevant for dMRV credibility because they demonstrate a conservative approach — in case of doubt, the framework credits less, not more. This stance is valued by buyers, auditors, and the market, and should be made explicit in the MvF as part of the methodology's design.
***
## Outputs & digital evidence package [#outputs--digital-evidence-package]
The auditable methodological output is the final result of dMRV execution: the artifact that justifies, based on verified evidence, that a given environmental impact was quantified in conformity with the methodology. In the Carrot ecosystem, these outputs are the basis for subsequent issuance, tracking, and — when applicable — retirement of [credits](/docs/protocol/credits), according to the adopted institutional design.
### Output types [#output-types]
The MvF must explicitly declare which output types the methodology generates and under which conditions:
**Primary outputs** are quantitative results that support credit generation. For example, the quantity of emission reductions (in tCO2e), the quantity of recycled material (in tons), or any other metric defined by the methodology. In the fictional COM example, primary outputs would be the GasID (carbon credits for methane reductions) and the RecycledID (recycling credits for landfill diversion).
**Intermediate outputs** are partial results that feed subsequent calculations or have informational value for audit, but do not directly generate credits. For example, the net weight after sorting is an intermediate output from the sorting event that feeds the final credit calculation.
**Verification outputs** are records generated by validation rule execution — approvals, rejections, flags, and audit results that compose the [MassID](/docs/protocol/mass-ids) audit trail. These outputs do not generate credits but are essential for demonstrating conformity.
### Evidence package composition [#evidence-package-composition]
The digital evidence package is the organized set of all records, data, documents, logs, and validation results generated throughout dMRV execution for a given tracked object (typically a MassID). It enables both internal digital verification and independent verification by third-party entities when applicable.
The MvF must describe what composes the evidence package for the methodology, including:
* Data and documents submitted by participants at each event (inputs), with their metadata
* Results of each validation rule executed (passed, failed, flagged), with the MvF and MvA version used
* Results of each calculation applied, with input variables and parameters
* Primary outputs generated, with their technical justification (how the number was obtained)
* Records of any escalation, additional audit, or human intervention that occurred
The completeness of the evidence package is what allows any reviewer — internal or independent — to traverse the full path between original inputs and the final output, verifying each step independently. The MvF must be designed so that **no output exists without an evidence trail that supports it**.
### Versioning and temporal traceability [#versioning-and-temporal-traceability]
Each output generated by the dMRV must carry sufficient versioning information to allow future reproduction. At minimum, the output must record:
* The MvF version that defined the applied rules
* The MvA version that executed the rules
* The execution date
* References to the events and inputs that support it
This temporal traceability is especially important when the framework undergoes version updates. An output generated under MvF version 1.0 must be evaluated according to version 1.0 rules, even if version 2.0 is already in operation. The MvF must declare how this separation is maintained and what happens with in-transit outputs during a version transition.
### Connection to external processes [#connection-to-external-processes]
The MvF must also indicate how outputs connect to processes outside the Carrot platform perimeter, when applicable. The platform enables methodology execution that supports credit generation, but issuance, tracking, and retirement of those credits may involve external infrastructure with its own formats and requirements.
When the dMRV institutional design provides for this interoperability, the MvF must declare:
* Which outputs are delivered to external processes and in what format
* Which metadata are required by the registry or destination infrastructure
* Which external dependencies exist (e.g., registry approval required before formal credit issuance)
This declaration keeps the separation of responsibilities clear and allows the platform to function as execution infrastructure without conflating its role with certification or registration. See [Carrot Registry](/docs/protocol/registry) for how outputs are presented to external stakeholders.
***
## Artifacts & templates [#artifacts--templates]
The sections above reference artifacts and templates that should accompany the MvF as standardized annexes. The table below consolidates the recommended artifacts:
| Artifact | Description | Reference section |
| ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- |
| **Traceability Matrix** | Connects validated methodology requirements to MvF elements, mapping each requirement to events, evidence, validations, and outputs. | [Methodological reference & registry](#methodological-reference--registry) |
| **dMRV Event Catalog** | Structured description of all events in the operational flow, with inputs, validations, outputs, dependencies, and evidence regime. | [dMRV events & event catalog](#dmrv-events--event-catalog) |
| **Evidence Policy per Event** | Table consolidating, event by event, required evidence, acceptance level, minimum metadata, digital validations, and escalation triggers. | [Inputs, evidence & evidence policy](#inputs-evidence--evidence-policy) |
| **Validation Rules Table** | Complete list of validation rules classified by type (Structure, Methodology, Audit), with specification sufficient for implementation. | [Validation rules & controls](#validation-rules--controls) |
| **Calculations & Parameters Table** | Detailing of each formula, variable, and parameter, including sources, units, application conditions, and test scenarios. | [Calculations, formulas & parameters](#calculations-formulas--parameters) |
| **MvF Completeness Checklist** | Verification list with all mandatory MvF components per the Minimum Structure, for self-assessment by the author and evaluation by the curation team. | All sections |
[Download the standardized MvF artifact
templates](https://drive.google.com/drive/folders/1jvqcUqhTe9FDVhjHsgjUmOjSyez9B6Zd?usp=sharing) —
including the Traceability Matrix, Event Catalog, Evidence Policy, Validation Rules Table,
Calculations & Parameters Table, and Completeness Checklist.
Each artifact must be developed following the standardized template to ensure consistency across different frameworks submitted to the ecosystem.
***
[MvF Author Guide](/docs/standard/guides/mvf-author-guide) · [MvF concept](/docs/standard/concepts/mvf) · [Methodology Lifecycle](/docs/standard/concepts/lifecycle)
# RFP Participation Guide
A Request for Proposals ([RFP](/docs/glossary#rfp)) is a formal call where the [Carrot Foundation](/docs/network/the-foundation) asks qualified proponents to submit proposals for a defined ecosystem need.
Use this guide when you are preparing a proposal. For the full process, RFP types, lifecycle, and participation rules, start with the [RFP Process](/docs/standard/policies/rfp-process).
## How proposals are evaluated [#how-proposals-are-evaluated]
Carrot uses a weighted evaluation matrix to ensure selection is objective, documented, and replicable. Each RFP defines its own criteria and weights, but the structure is always the same.
### Evaluation matrix [#evaluation-matrix]
Every proposal is evaluated across up to six dimensions. Each dimension receives a score from 1 to 5, multiplied by a weight that reflects its relative importance. The weighted sum defines the final score.
| # | Dimension | What is evaluated | Typical weight | Score |
| :-: | -------------------------- | --------------------------------------------------------------------- | :------------: | :---: |
| 1 | **Technical quality** | Rigor, depth, and feasibility of the proposed approach | 25--35% | 1--5 |
| 2 | **Team & experience** | Qualifications, delivery track record, demonstrated capacity | 15--25% | 1--5 |
| 3 | **Feasibility & timeline** | Plan realism, delivery milestones, risk management | 10--20% | 1--5 |
| 4 | **Strategic alignment** | Adherence to Carrot mission, scalability, governance | 10--20% | 1--5 |
| 5 | **Commercial proposal** | Cost-benefit, payment structure, price transparency | 5--15% | 1--5 |
| 6 | **Innovation** | Differentiating elements, creativity, added value beyond requirements | 5--15% | 1--5 |
Exact weights are defined per RFP and always sum to 100%. For example, a Type A RFP (problem-solving) may weigh technical quality and innovation more heavily, while a Type B (AMC Project) may prioritize feasibility and commercial proposal.
### Scoring scale [#scoring-scale]
| Score | Classification | Meaning |
| :---: | -------------------- | ---------------------------------------------------------------------------------------------- |
| **5** | Exceeds expectations | Goes beyond the stated requirements with a stronger approach, clearer evidence, or both. |
| **4** | Strong | Fully meets requirements and adds relevant strengths without introducing material gaps. |
| **3** | Adequate | Meets requirements with an acceptable level of detail, feasibility, and supporting evidence. |
| **2** | Limited | Partially meets requirements, with gaps that reduce confidence in delivery. |
| **1** | Insufficient | Does not meet the requirement or includes flaws that prevent the proposal from being accepted. |
### Three-stage evaluation [#three-stage-evaluation]
**Stage 1 — Eligibility triage.** Each proposal is verified against mandatory criteria. Proposals that do not meet the requirements are disqualified before reaching merit evaluation, protecting the objectivity of the process.
**Stage 2 — Independent scoring.** At least two evaluators score each proposal independently using the criteria matrix. No evaluator sees the other's scores before completing their own evaluation.
**Stage 3 — Consensus panel.** When divergence exceeds one point on any criterion, evaluators meet to discuss and converge. The final result is the consolidated weighted average.
Carrot publishes the evaluation criteria before the submission deadline. You know exactly how you
will be evaluated before deciding to participate.
## How to participate [#how-to-participate]
### Before submitting [#before-submitting]
* **Read the full RFP.** Many proposals are disqualified for not meeting requirements that were explicitly stated. Pay special attention to eligibility, deliverables, and timeline sections.
* **Check eligibility criteria.** If you do not meet a mandatory criterion, your proposal will be disqualified at triage — before it is even read. Make sure you meet all of them.
* **Use the Q\&A period.** If something is unclear, ask. Answers are public and benefit all proponents. Do not assume — ask.
* **Use the Readiness Checklist.** Each RFP includes a checklist of items your proposal must contain. Use it as a final guide before submitting.
### What a good proposal contains [#what-a-good-proposal-contains]
Regardless of RFP type, well-evaluated proposals generally share these characteristics:
* **Clarity** — The proposal communicates its approach directly, without unnecessary jargon.
* **Specificity** — Instead of generic promises, it presents concrete details about what will be done, how, and when.
* **Evidence** — It demonstrates prior experience with real examples, not only claims.
* **Honesty about limitations** — It identifies risks and proposes mitigations, rather than ignoring difficulties.
* **Scope adherence** — It responds to what was asked, without drifting into topics outside the RFP.
### How to submit [#how-to-submit]
Each RFP specifies the submission channel (typically [rfp@carrot.eco](mailto:rfp@carrot.eco)), accepted format, and deadline. A submission must include:
* The main proposal document in PDF, following the structure requested in the RFP
* The Submission Questionnaire (provided in XLSX format with the RFP)
* The completed Readiness Checklist
* Supporting documents as requested (CVs, portfolio, certifications, etc.)
Email subject format: `RFP-CARROT-[YYYY]-[NNN] — [Your name or organization]`
Proposals that are incomplete or received after the deadline will not be considered. When in doubt
about completeness, check the Readiness Checklist.
## After the RFP [#after-the-rfp]
### Results communication [#results-communication]
All proponents are notified about the outcome, regardless of whether they were selected. Carrot communicates:
* The final decision (selected or not selected)
* The overall proposal score (without per-evaluator breakdown)
* Summary feedback on strengths and areas for improvement, when applicable
### For selected proponents [#for-selected-proponents]
The selected proponent enters the contracting phase, where final terms are negotiated — including detailed scope, delivery timeline, reward conditions, and platform terms of use. After formalization, the execution phase begins with periodic oversight by the Carrot team.
**Substitution clause** — If the selected proponent cannot commit to implementation within the agreed terms, or if undisclosed non-conformities, inaccurate information, or conflicts of interest are discovered at any stage, the Carrot Foundation may: (a) invite the next highest-ranked proponent for negotiation, or (b) open a new RFP for the same scope. Invitation of the next-ranked proponent respects the original evaluation ranking and is conditional on continued eligibility.
### Not selected? [#not-selected]
Participating in an RFP — even without being selected — has value. You gain visibility with the Carrot team, receive feedback on your proposal, and can use the experience to strengthen future submissions. Many of the most successful proponents in subsequent calls are those who participated previously and incorporated the feedback they received.
## RFP Library [#rfp-library]
The table below is the central registry of all RFPs published by the Carrot Foundation. It is updated as new calls are opened or closed.
| Reference | Type | Title | Status | Published | Deadline |
| --------------------- | :----: | ------------ | :----: | :--------: | :--------: |
| *RFP-CARROT-2026-001* | *A--F* | *Call title* | *Open* | *DD/MM/YY* | *DD/MM/YY* |
**Possible statuses:** Open (accepting proposals), Under Evaluation (deadline closed, evaluation in progress), In Execution (proponent selected, work in progress), Completed (deliverables accepted), Cancelled (call cancelled without selection).
Contact [rfp@carrot.eco](mailto:rfp@carrot.eco) for full RFP documents, referencing the call identifier.
## FAQ [#faq]
Yes, as long as you meet the eligibility criteria for each call and have the capacity to execute
if selected for more than one.
No, unless the RFP explicitly allows alternative proposals. When in doubt, submit your best
proposal.
Yes. Consortium proposals are accepted, provided there is a clear lead proponent and the roles
of each partner are well-defined.
Yes. Carrot treats all received proposals as confidential and does not share their content with
third parties or other proponents.
Send your questions to [rfp@carrot.eco](mailto:rfp@carrot.eco) during the Q\&A period indicated in the timeline. Answers
are published in a public FAQ accessible to all proponents.
No. The Carrot Foundation reserves the right to not select any proposal, cancel, or modify an
RFP at any time, without obligation to justify or compensate.
New RFPs are announced on the carrot.eco website, the RFP Library above, and official community
channels.
[RFP Process](/docs/standard/policies/rfp-process) · [Methodology Ecosystem](/docs/standard/concepts/ecosystem)
# Colliding Methodologies
## What is a methodology collision? [#what-is-a-methodology-collision]
A methodology collision occurs when two or more digital MRV ([dMRV](/docs/protocol/dmrv)) methodologies could verify the same waste mass, creating a risk of double counting. For example, if the same waste mass could earn two recycling credits (or two carbon credits) under overlapping methodologies, the environmental impact would be double-counted — which is why a MassID can carry at most one credit of each type.
Collision prevention is a core requirement of the [Carrot dMRV Standard](/docs/standard) and is enforced at multiple levels: during methodology proposal review, through runtime validation rules, and via governance oversight.
## Prevention [#prevention]
Collisions are prevented before they can occur through structural safeguards:
* **Scope registration** — Every methodology declares its eligible waste types, treatment methods, and geographic boundaries. These scope definitions are reviewed for overlap before a methodology enters production.
* **Community review** — The Community of Experts evaluates new methodology proposals for potential overlap with existing methodologies during the validation phase of the [methodology lifecycle](/docs/standard/concepts/lifecycle).
* **Technical safeguards** — Each waste mass is represented by a unique [MassID](/docs/protocol/mass-ids), ensuring that the same physical material cannot be submitted under multiple identities.
## Detection [#detection]
Even with preventive measures, the system includes runtime rules that detect and block potential collisions:
* **`waste-mass-is-unique`** — Validates that no duplicate MassIDs exist with the same combination of drop-off, pick-up, [recycler](/docs/protocol/supply-chain#the-role-of-the-recycler), [waste generator](/docs/protocol/supply-chain), and vehicle license plate. This prevents the same physical waste mass from being submitted twice.
* **`no-conflicting-certificate-or-credit`** — Validates that a MassID is not already linked to a valid [certificate](/docs/protocol/certificates) or [credit](/docs/protocol/credits) order. This prevents double counting at the certification level.
These rules run automatically as part of every [MvA](/docs/standard/concepts/mva) evaluation. A MassID that fails either rule cannot receive a certificate.
The Community of Experts also monitors for emerging collision patterns — cases where methodologies develop scope overlap over time through versioning changes.
## Resolution process [#resolution-process]
When a potential collision is identified, the resolution process is governance-led:
1. **Detection** — The collision is identified through runtime rule failures, Community of Experts monitoring, or external reporting.
2. **Analysis** — The [Carrot Foundation](/docs/network/the-foundation) and Community of Experts analyze the scope overlap and its impact.
3. **Priority determination** — The first-verified methodology generally takes precedence for disputed claims.
4. **Scope adjustment** — The conflicting methodology must narrow its scope to eliminate the overlap.
5. **Implementation** — Rule updates are deployed to enforce the adjusted scopes.
As the ecosystem matures, the [Carrot Foundation](/docs/network/the-foundation) will progressively expand community participation in collision resolution decisions.
## Current safeguards [#current-safeguards]
The active BOLD methodologies ([BOLD Recycling](/docs/methodologies/bold-recycling) and [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon)) enforce collision prevention through their integrity rules:
* **`waste-mass-is-unique`** — Shared across both methodologies, preventing duplicate submissions.
* **`no-conflicting-recycled-id-or-credit`** (BOLD Recycling) — Ensures a MassID is not already linked to a [RecycledID](/docs/protocol/certificates#recycledid) certificate or credit.
* **`no-conflicting-gas-id-or-credit`** (BOLD Carbon (CH₄)) — Ensures a MassID is not already linked to a [GasID](/docs/protocol/certificates#gasid) certificate or credit.
These rules operate independently per methodology but together form a comprehensive anti-collision system.
## Coexistence scenarios [#coexistence-scenarios]
Two methodologies with similar technical basis can coexist if they serve distinct purposes (different audiences, scales, or contexts — e.g., municipal vs. industrial), and the platform ensures the same participant cannot be accredited simultaneously under both colliding methodologies.
### Automated collision detection [#automated-collision-detection]
* **[Carrot Analytic Engine (CaE)](/docs/glossary#cae) monitoring** — The CaE monitors data from active methodologies using ML algorithms comparing mass patterns, flows, coefficients, and calculation parameters. When unusual correlations are found (mass duplication, variable equivalence, statistical overlap), it triggers preventive blocking and flags the case for analysis.
* **[Carrot Agentic Advisor (CaA)](/docs/glossary#caa) contextualization** — The CaA contextualizes detected anomalies, classifies the conflict type and severity, and recommends corrective actions (parameter adjustments, temporary accreditation suspension, or community review process).
### Governance resolution [#governance-resolution]
When a persistent or structural conflict is identified, the [Carrot Foundation](/docs/network/the-foundation) and/or the Community of Experts may deliberate on: maintaining both methodologies with reinforced scope separation, merging overlapping elements, or discontinuing one methodology.
[Learn about rules](/docs/methodologies) · [Learn about MvA](/docs/standard/concepts/mva) · [Learn about the methodology lifecycle](/docs/standard/concepts/lifecycle)
# Discontinuation Policy
## When is a methodology discontinued? [#when-is-a-methodology-discontinued]
A digital MRV ([dMRV](/docs/protocol/dmrv)) methodology may be discontinued when it no longer serves its intended purpose or when continued operation would compromise the integrity of the [Carrot Network](/docs/network). Discontinuation criteria include:
1. **Scientific invalidity** — The methodology's scientific basis has been disproven or superseded by new research.
2. **Regulatory change** — Changes in environmental regulation make the methodology's verification approach non-compliant.
3. **Superseded** — A newer methodology covers the same scope with improved accuracy or efficiency.
4. **Inactivity** — The methodology has had no active submissions for an extended period, indicating it is no longer relevant to the market.
5. **Governance decision** — The Community of Experts or the [Carrot Foundation](/docs/network/the-foundation) determines that discontinuation is in the network's best interest.
## Discontinuation process [#discontinuation-process]
Discontinuation follows a three-phase transition:
### Phase 1: Communication & notice [#phase-1-communication--notice]
The [Carrot Foundation](/docs/network/the-foundation) publishes the decision with advance notice, notifying all active participants, MvF author, MvA developer, and credit buyers. The notice includes: technical justification, transition timeline, guidance for active operations, and replacement methodology (when one exists). Typical notice period: 90–180 days.
### Phase 2: Restricted operation [#phase-2-restricted-operation]
The methodology continues operating for [MassIDs](/docs/protocol/mass-ids) that started processing before the notice date, but no new MassIDs can be created under the methodology. Validation rules and calculations remain active for in-transit MassIDs, preserving credit integrity.
### Phase 3: Archive [#phase-3-archive]
The methodology is formally deactivated. No new events are accepted. The [MvF](/docs/standard/concepts/mvf), [MvA](/docs/standard/concepts/mva), artifacts, and complete history are archived with a "discontinued" status. [Credits](/docs/protocol/credits) issued before discontinuation remain valid and tradeable.
## Impact on existing credits [#impact-on-existing-credits]
[Credits](/docs/protocol/credits) and [Certificates](/docs/protocol/certificates) issued before discontinuation remain valid and tradeable. Discontinuation is forward-looking — it prevents new verifications but does not retroactively affect previously verified claims.
The audit trail for all past verifications remains accessible through the [Carrot Registry](/docs/protocol/registry) and the immutable public registry.
## Governance [#governance]
Discontinuation decisions are made by the [Carrot Foundation](/docs/network/the-foundation) with input from the Community of Experts. As the ecosystem matures, the Foundation will progressively expand community participation in discontinuation decisions.
## Banning [#banning]
Banning is an exceptional measure reserved for situations of immediate or severe integrity risk. It can be executed **without** a transition period.
### Banning triggers [#banning-triggers]
* Fraud or deliberate manipulation of data, evidence, or parameters.
* Structural MvF/MvA failures resulting in credit issuance without valid technical basis, uncorrectable by versioning.
* Judicial or regulatory orders preventing continued operation.
### Banning process [#banning-process]
1. **Immediate suspension** — No new events and no new issuances.
2. **Preventive credit blocking** — Credits are blocked for analysis.
3. **Immediate notification** — All participants, buyers, registries, and VVBs are notified.
4. **Investigation** — The impact scope is determined.
5. **Public report** — Findings, justification, and measures are published.
### Impact on issued credits [#impact-on-issued-credits]
| Outcome | When it applies |
| --------------------- | ------------------------------------------------------------------- |
| Confirmation | The fault did not affect previously issued credits |
| Revision & adjustment | The fault partially impacted results — recalculation where affected |
| Revocation | Credits based on compromised data or logic — invalidated |
When applicable, the review is conducted with independent auditors.
[Learn about the versioning policy](/docs/standard/policies/versioning) · [Learn about the methodology lifecycle](/docs/standard/concepts/lifecycle)
# Quality Criteria & Accreditation
## Purpose and scope [#purpose-and-scope]
The quality evaluation of a digital MRV ([dMRV](/docs/protocol/dmrv)) serves three simultaneous purposes. For the ecosystem, it acts as an **integrity barrier** — ensuring that only technically sound, auditable, and implementable frameworks enter production, protecting the credibility of issued credits and the trust of participants and buyers. For the author, it acts as an **expectation guide** — by knowing the evaluation criteria in advance, the author can build the [MvF](/docs/standard/concepts/mvf) with focus on the requirements that will be verified, reducing rework and review cycles. For the developer, it acts as a **quality guarantee** for inputs — an accredited MvF is, by definition, implementable without interpretation, reducing risk and friction during [MvA](/docs/standard/concepts/mva) development.
The scope of this page covers the evaluation of the MvF (framework), which is the primary author deliverable and the main object of curation at the current stage of the ecosystem. Quality criteria for the MvA (application), which involve software engineering and platform integration requirements, are defined by the Engineering team in a separate document.
The criteria described here reflect the current internal curation model, in which MvF validation
is conducted by the Carrot Operations and Methodologies team. As the ecosystem matures and the
Community of Experts advances through its phases, these responsibilities may be progressively
transferred, with safeguards and processes defined by applicable governance.
## Evaluation principles [#evaluation-principles]
The quality evaluation of an MvF is guided by six principles that reflect the values of the dMRV ecosystem and apply both to the current internal curation process and to future community review processes.
1. **Verifiability** — Every requirement described in the MvF must be expressed so that someone — whether the MvA in automated execution or an auditor in independent verification — can answer, based on evidence, whether the requirement was met. The guiding question is: "for each rule, criterion, and parameter, is there an objective way to test whether it was fulfilled?"
2. **Self-containment** — The MvF must be sufficiently complete for the MvA developer to implement all rules, calculations, and validations without consulting the author or the original scientific methodology. This does not mean the MvF replaces the external reference. Instead, the framework itself must contain all operational information necessary for implementation and audit.
3. **Traceability** — It must be possible to trace the complete path between the third-party validated methodology and any operational element of the MvF — rule, calculation, parameter, eligibility criterion — demonstrating where each requirement came from and how it was translated. The Traceability Matrix is the instrument that materializes this principle.
4. **Internal consistency** — The different parts of the MvF must be coherent with each other: eligibility criteria must be compatible with catalog events, validation rules must reference inputs that exist in the events, calculations must use variables that have been defined and have a declared source, and outputs must be justified by the evidence trail from preceding events.
5. **Proportionality** — The evaluation recognizes that different methodologies have different complexity levels, and that quality criteria must be applied with reasonableness. An MvF for a simple methodology with few events and straightforward rules does not need the same documentary breadth as an MvF for a complex methodology with dozens of variables and cross-participant interactions. What must remain constant is the quality and precision of each component, not necessarily the quantity.
6. **Adaptability** — The MvF must be designed to support application across multiple territories, separating universal elements from elements parameterizable by geography. A framework that works only for a specific country — without providing an interface with Geographic Annexes — limits the methodology's scalability and creates significant rework when territorial expansion becomes necessary.
## Quality dimensions [#quality-dimensions]
Quality criteria are organized into six dimensions. Each dimension groups a set of requirements that together determine whether the MvF is ready for accreditation. The evaluation is performed dimension by dimension, and the result for each can be: **Conformant**, **Conformant with caveats** (minor points to adjust that do not compromise framework integrity), or **Non-conformant** (gaps that prevent accreditation and require substantive revision).
### Completeness [#completeness]
The completeness dimension evaluates whether the MvF contains all components defined in the MvF Minimum Structure and whether mandatory artifacts are present and filled in. The MvF Completeness Checklist is the author's self-assessment instrument for this dimension, but internal curation may verify additional aspects beyond the checklist.
In practice, the completeness evaluation verifies that each Minimum Structure section is present and non-empty: scope and concept, methodology reference, eligibility and exclusions, event catalog, evidence policy, validation rules, calculations and parameters, outputs, and geographic adaptability. It also verifies that mandatory artifacts have been delivered: Traceability Matrix, Event Catalog, Evidence Policy, Validation Rules Table, and Calculations and Parameters Specification Table — all with Geographic Scope columns filled in applicable tabs.
### Verifiability [#verifiability]
The verifiability dimension evaluates whether the rules, criteria, and parameters of the MvF are described in a way that allows objective testing. It is the most critical dimension for the operational quality of the framework, because an MvF that cannot be verified cannot be implemented deterministically.
Curation evaluates verifiability through a sample-based review: it selects a representative subset of validation rules and eligibility criteria and, for each one, verifies whether the description is sufficient to answer, without ambiguity, whether the requirement was met. Rules containing terms such as "adequate", "reasonable", "sufficient", or "as needed" without an operational definition are considered non-verifiable and must be reformulated.
The evaluation also verifies that test scenarios provided (when present) are consistent with the described formulas — that is, that expected results are correct when the stated inputs are applied.
### Traceability [#traceability]
The traceability dimension evaluates whether the MvF maintains a clear, documented connection to the third-party validated methodology that underpins it. The central instrument of this evaluation is the Traceability Matrix, which must connect each relevant requirement from the external methodology to the corresponding MvF element.
Curation verifies that the Matrix is completed in a way that allows any reviewer to trace the path between the external reference and the operational implementation: Is the original requirement identified precisely (section, version, passage)? Does the MvF indicate where and how this requirement is addressed? Do associated events exist in the catalog? Are the evidence and validations consistent?
Beyond the Matrix, traceability is also evaluated in the MvF body: Do formulas reference their sources? Do fixed parameters indicate the origin of their value? Are exclusions and exceptions justified by the methodology? When the MvF makes design choices that go beyond what the methodology prescribes — for example, defining event granularity or conservative discount factors — these choices must be documented with technical rationale.
### Implementability [#implementability]
The implementability dimension evaluates whether the MvF provides the MvA developer with sufficient information to code all rules, validations, and calculations without needing to interpret, infer, or consult the author. It is the self-containment principle translated into an evaluation criterion.
In practice, curation evaluates whether: validation rules specify the tested condition, the acceptance criterion, and the action on failure; calculations describe the equation, each variable (with unit, source, and conditions), and fixed parameters with references; catalog events declare required inputs with minimum metadata and expected formats; and conditional criteria state the trigger that activates each condition.
A pragmatic way to assess implementability is the "developer test": if curation takes any section of the MvF and hands it to a developer who did not participate in writing the framework, could that developer implement it without asking the author any questions? If the answer is no, the section needs refinement.
### Auditability [#auditability]
The auditability dimension evaluates whether the MvF, when executed, generates sufficient evidence for an independent auditor to verify the process end-to-end — from original inputs to final outputs — without needing to access internal systems or rely on verbal explanations.
Curation verifies whether: the Evidence Policy distinguishes what is digitally verifiable from what requires audit or inspection; escalation triggers are defined for situations of inconsistency, absence, and anomaly; the digital evidence package contains the elements necessary to justify each result; and MvF and MvA versioning is included in outputs, enabling future reproduction of results.
Auditability is especially relevant because the Carrot ecosystem involves validation, issuance, and retirement processes for credits that require a complete audit trail. An MvF that does not generate auditable evidence creates friction throughout the cycle and weakens credit credibility.
### Geographic adaptability [#geographic-adaptability]
The geographic adaptability dimension evaluates whether the MvF is designed to support application across multiple territories, following the geographic adaptability guidelines. This dimension recognizes that a dMRV methodology with global scaling potential needs to separate, from the design stage, what is universal — derived from the methodology's logic — from what is territorial — dependent on local legislation, classification, or infrastructure.
Curation evaluates whether: MvF elements are classified as Universal or Territorial in tabular artifacts (Rules Table, Calculations Table, Evidence Policy); elements classified as Territorial have a clear functional requirement (the universal intent) separated from operationalization (which depends on the territory); territorial parameters indicate a default value when local data is unavailable; territorial eligibility criteria indicate connection points with the Geographic Annex; and the MvF explicitly declares which information the Geographic Annex must provide for each territorial point.
An MvF that does not address geographic adaptability is not necessarily non-conformant in this dimension — this depends on the scope declared by the author. If the methodology is explicitly designed for a single territory (for example, a methodology that only applies to Brazil due to specific Brazilian legislation), the author must declare this restriction in the scope and the evaluation will consider this dimension "not applicable". However, if the methodology has multi-territorial application potential and the MvF does not provide universal/territorial separation, curation will flag this as an improvement point.
## Accreditation process [#accreditation-process]
The accreditation process is the flow through which a submitted MvF is evaluated, adjusted (when necessary), and — when approved — formally accredited for production operation. At the current stage, this process is conducted internally by the Carrot Operations and Methodologies team, with support from the Engineering team for technical implementation feasibility.
### Submission and triage [#submission-and-triage]
The process begins with the author's formal submission of the MvF, accompanied by all mandatory artifacts (Traceability Matrix, Event Catalog, Evidence Policy, Rules Table, Calculations Table) and the completed Completeness Checklist. Submission may occur via RFP (when the dMRV responds to a published demand) or via partnership/direct initiative.
During initial triage, curation verifies that the deliverable is complete — that is, that all Minimum Structure sections are present, that mandatory artifacts have been delivered, and that Geographic Scope columns are filled in applicable tabs. If the deliverable is incomplete, the author is notified of the missing components and given a deadline to supplement before the technical assessment begins.
### Technical assessment [#technical-assessment]
Once the deliverable is complete, curation conducts the technical assessment — the systematic application of the quality criteria across six dimensions (completeness, verifiability, traceability, implementability, auditability, and geographic adaptability). The assessment produces a technical report that records, for each dimension, the result (conformant, conformant with caveats, non-conformant) and applicable observations.
During the technical assessment, curation may consult the author to clarify specific points, request additional documentation, or solicit targeted adjustments. These interactions are recorded as part of the dMRV's assessment history, preserving traceability of the decision process.
When the Engineering team identifies that some aspect of the MvF presents significant implementation challenges — for example, a rule that depends on information the platform cannot access, or a calculation requiring external data that cannot be integrated — curation may return the MvF to the author with a technical note explaining the limitation and suggesting alternatives.
### Review cycle [#review-cycle]
If the technical assessment identifies dimensions that are non-conformant or conformant with caveats requiring adjustment, the MvF enters a review cycle. The author receives the technical report with detailed observations and has a defined period to submit the revised version.
The ecosystem allows a **maximum of two review cycles** for the same MvF. If after the second cycle there are still non-conformant dimensions, the MvF is returned to the author with a recommendation for substantive restructuring, and a new submission will be treated as an independent process. This limitation ensures that the accreditation process remains efficient and that frameworks with structural problems do not consume indefinite review cycles.
In each cycle, curation re-evaluates only the flagged dimensions — previously approved dimensions are not re-evaluated, unless changes made by the author have cross-cutting impact that justifies reassessment.
### Accreditation [#accreditation]
When all six dimensions are evaluated as conformant (or conformant with minor caveats that do not compromise integrity), the MvF is considered approved and enters formal accreditation. Accreditation includes:
* Registration of the approved MvF version with timestamp and reference to the technical assessment
* Publication of the framework in the platform's accredited methodology repository
* Linkage to the MvA development process, which proceeds under the responsibility of the Engineering team and the designated developer
Accreditation of the MvF does not end the author's responsibility. As described in the [Versioning Policy](/docs/standard/policies/versioning), the author may be called upon to collaborate on version revisions, respond to auditor inquiries, and participate in technical discussions about the framework's evolution.
## Non-conformity typology [#non-conformity-typology]
To guide authors and standardize evaluation language, this section classifies the most common types of non-conformity identified during the technical assessment of an MvF.
| Type | Description | Examples | Impact | Typical resolution |
| --------------------------- | --------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Content gap | A mandatory Minimum Structure section is absent or nearly empty. | Event catalog without input descriptions; Evidence Policy absent; Calculations section without specified variables. | Blocks assessment: cannot evaluate quality without content. | Complete the section and resubmit. |
| Rule ambiguity | A validation rule or eligibility criterion is described in a way that allows multiple interpretations. | "The participant must have adequate capacity"; "weighing must be precise"; "the interval must be reasonable". | Prevents deterministic implementation; creates risk of divergence between MvF and MvA. | Rewrite with testable condition, numeric criteria, and failure action. |
| Internal inconsistency | Two or more parts of the MvF contradict each other or make incorrect cross-references. | A rule references a non-existent event in the catalog; a calculation uses an undefined variable; the Matrix points to non-existent sections. | Compromises framework reliability as a whole. | Revise conflicting parts and ensure coherence between sections and artifacts. |
| Insufficient traceability | Cannot connect an MvF element to its origin in the validated methodology. | Formula without methodology reference; fixed parameter without source; exclusion criterion without methodological justification. | Weakens the framework's technical legitimacy. | Add references and sources; complete the Traceability Matrix. |
| Insufficient specification | Description exists but lacks sufficient detail for developer implementation. | Formula with variables without units; event with "weighing data" unspecified; rule without failure action. | Creates developer dependency on the author; increases error risk. | Detail fields, units, sources, conditions, and actions for each component. |
| Auditability gap | The framework does not generate sufficient evidence for independent verification at one or more points. | Event without defined evidence regime; no escalation triggers; outputs without versioning. | Compromises verification and audit capacity for the credit cycle. | Define complete Evidence Policy with regime, metadata, and triggers. |
| Geographic adaptability gap | The MvF has multi-territorial scope but does not provide separation between universal and territorial elements. | Eligibility rules referencing single-country legislation without indication of territorial variation; material classification hardcoded for a local taxonomy; parameters without default value. | Limits methodology scalability; creates rework during territorial expansion. | Classify elements as Universal/Territorial in artifacts; write functional requirements separate from operational ones; define Geographic Annex connection points. |
Each non-conformity identified in the technical report includes: the affected quality dimension, the non-conformity type, the location in the MvF (section and artifact), the problem description, and the resolution recommendation. This record allows the author to understand precisely what needs correction, without ambiguity.
## MvA quality criteria [#mva-quality-criteria]
The quality evaluation of the Methodology Verification Application (MvA) involves software engineering criteria, platform infrastructure integration, and implementation fidelity relative to the accredited MvF.
There is a relevant interface between MvF quality and MvA quality: a well-specified framework — one that meets the verifiability, implementability, and geographic adaptability criteria described on this page — reduces the risk of implementation problems. When the MvF classifies elements as territorial and provides clear functional requirements, the developer knows to parameterize those points in the MvA instead of hardcoding values — resulting in more robust and scalable code.
MvA validation, when performed, verifies — among other aspects — fidelity to the accredited MvF, technical quality of the implementation (determinism, reproducibility, error handling), traceability and evidence generation (logs, audit trails, version records), compliance with platform technical standards, and correct parameterization of territorial elements.
MvA quality criteria are defined and documented by the Engineering team in a separate document,
maintaining the separation of responsibilities between framework and code.
## Evolution toward community evaluation [#evolution-toward-community-evaluation]
As described in the [Methodology Lifecycle](/docs/standard/concepts/lifecycle), dMRV curation is designed to evolve progressively — from exclusively internal validation toward a model with increasing community participation.
The quality criteria described on this page were designed to support this evolution: they are objective, documented, and applicable by any reviewer with adequate technical capacity. The inclusion of the geographic adaptability dimension reinforces this point: it enables reviewers from different territories to evaluate whether an MvF is prepared to operate in their local regulatory contexts.
Regardless of the evaluation model in effect, Carrot maintains a backstop role to ensure transparency, consistency, and process continuity — including preservation of assessment history, versioning of criteria, and response to integrity risks.
Formal criteria for community participation in dMRV evaluation, including roles, permission
levels, and decision processes, are still being defined and will be documented as the community
structure consolidates.
***
[MvF Author Guide](/docs/standard/guides/mvf-author-guide) · [Methodology Lifecycle](/docs/standard/concepts/lifecycle)
# Rewards Distribution Policy
## Overview [#overview]
The Rewards Distribution Policy defines how the proceeds from [credit](/docs/protocol/credits) **purchases** are distributed among participants. When a buyer purchases a **quantity** of credits (e.g. 10 metric tons), that quantity is fulfilled by allocating from one or more [certificates](/docs/protocol/certificates), each backed by [MassIDs](/docs/protocol/mass-ids). Proceeds are split across the underlying MassIDs proportional to the value of the credits drawn from each, then distributed by participant category according to the percentages below. The policy is designed to maximize participation in the network and accelerate recycling rates across geographies.
The policy was established by the Carrot Foundation in consultation with market participants, advisors, and data scientists. Over time, the Foundation will progressively expand community participation in these decisions.
**Across every waste type, at least 80% of each credit sale — recycling or carbon — is allocated to Carrot Network participant categories, before any [reward discount](#reward-discounts).** The remainder covers the Distribution Fee and the Registry, which cover network operations, plus the digital MRV ([dMRV](/docs/protocol/dmrv)) and Integrity Component, which funds the Foundation's operations and growth. The tables below set out how the participant share is divided by category for each material. Where a reward discount applies, part of that participant share is redirected to the [Community Pool](/docs/glossary#community-pool) or the [Impact Pool](/docs/glossary#impact-pool) instead of being paid out — it stays inside the network and never accrues to a private party.
## Payment currency and withdrawal [#payment-currency-and-withdrawal]
Rewards are paid in [USDC](/docs/glossary#usdc) (a traceable digital currency pegged to the US dollar). Participants can withdraw their rewards in fiat or stablecoin — fiat payouts are fulfilled via integrated payment providers, while USDC withdrawals draw directly on the participant's balance held on the public registry. Using USDC as the settlement currency gives participants **stable value** without exposure to market price volatility, keeps protocol settlement consistent across the public registry, and allows participants to choose how they receive value (fiat or stablecoin) according to their needs. For full claiming mechanics and privacy-preserving distribution, see [Rewards Distribution](/docs/protocol/rewards-distribution).
## Participant categories [#participant-categories]
| Key | Participant | Description |
| ---- | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| G | Waste Generator | Produces waste and performs source sorting |
| WM | Waste Manager | Coordinates and directs waste destination without taking physical custody |
| BC | Bin Custodian | Manages the collection bin or drop-off point where recyclables are deposited before they are collected |
| H | Hauler(s) | Transports waste between locations |
| P | Processor(s) | Sorts, accumulates, and pre-processes materials |
| R | Recycler | Performs certified recycling or biological treatment (also serves as Processor when it records the sorting events) |
| I | Network Integrator | Data provider for supply chain tracking |
| A | MvF Author | Creator of the methodology framework (MvF) |
| D | MvA Developer | Developer of the MvA (software that implements the framework) |
| DF | Distribution Fee | Covers transaction handling and the settlement and payout of participant rewards |
| RG | Registry | Covers issuing and maintaining the records of credit and certificate issuance |
| dMRV | digital MRV and Integrity Component | Feeds the Foundation Treasury and sustains protocol development and network integrity |
The [**Bin Custodian**](/docs/protocol/supply-chain) manages the collection point where recyclables accumulate before a [Hauler](/docs/protocol/supply-chain) collects them for recycling. Its share recognizes the costs of enabling collection at the source — acquiring the bin, deploying and retrieving it, cleaning, maintenance, access control, and energy, among others. Bins may be offered free of charge or under contract, in public or private locations, broadening collection points and network participation. Where a Bin Custodian share applies (currently PET collection, per the distribution table below) and no Bin Custodian is involved in the asset's process, that percentage is redirected to the Hauler.
The [**Waste Manager**](/docs/protocol/supply-chain#waste-manager) is contracted by the Waste
Generator to coordinate waste destination without transporting, sorting, or treating the material.
For organic waste, its 4% share applies only when both the Waste Manager and Waste Generator have
completed onboarding and confirmed their relationship. A one-sided declaration has no effect. If
more than one Waste Manager is confirmed, they divide the category share.
When a Waste Generator changes Waste Manager, it notifies the Carrot Foundation at
[operations@carrot.eco](mailto:operations@carrot.eco) so the relationship record can be updated.
[**Program Owners**](/docs/protocol/credit-ecosystem-roles#program-owner) and
[**Network Developers**](/docs/protocol/credit-ecosystem-roles#network-developer) are ecosystem
roles, not reward categories. They receive no protocol rewards and do not appear in the percentages
below; any remuneration for their services is contractual and outside this policy.
## Distribution by waste type [#distribution-by-waste-type]
Each waste type has its own distribution percentages, reflecting the relative contribution of each participant in that material's supply chain.
**Composting of mixed organic waste:**
G (30%), WM (4%), H (9%), P (9%), R (18%), I (8%), A (1%), D (1%), DF (2.5%), RG (1%), dMRV (16.5%)
**Composting of sludge from waste treatment plants:**
G (25%), WM (4%), H (4%), P (9%), R (28%), I (8%), A (1%), D (1%), DF (2.5%), RG (1%), dMRV (16.5%)
**Composting of tobacco industry residues:**
G (25%), WM (4%), H (4%), P (9%), R (28%), I (8%), A (1%), D (1%), DF (2.5%), RG (1%), dMRV (16.5%)
The Waste Manager's 4% comes from the Hauler (1%), [Processor](/docs/protocol/supply-chain) (1%), and
[Recycler](/docs/protocol/supply-chain#the-role-of-the-recycler) (2%) categories; the total remains
100%. If no confirmed Waste Manager exists for the asset's process, those percentages return to
their source categories.
G (20%), H (20%), P (15%), R (15%), I (8%), A (1%), D (1%), DF (2.5%), RG (1%), dMRV (16.5%)
G (20%), H (20%), P (15%), R (15%), I (8%), A (1%), D (1%), DF (2.5%), RG (1%), dMRV (16.5%)
G (25%), H (10%), P (20%), R (15%), I (8%), A (1%), D (1%), DF (2.5%), RG (1%), dMRV (16.5%)
G (25%), BC (3%), H (12%), P (15%), R (15%), I (8%), A (1%), D (1%), DF (2.5%), RG (1%), dMRV (16.5%)
The Bin Custodian's 3% comes from the Hauler's share (15% → 12%); the total remains 100%. When no Bin Custodian is involved, that 3% is redirected to the Hauler.
Use the [Credit Calculator](/docs/standard/guides/credit-calculator) to see an illustrative
distribution breakdown for a given waste type and volume.
## Reward discounts [#reward-discounts]
The reward distribution is calculated at the moment of sale. Two discounts can apply, and both feed the network's [destination funds](#destination-funds) rather than any private party.
### Supply chain digitization incentive [#supply-chain-digitization-incentive]
When the [Waste Generator](/docs/protocol/supply-chain) is not identified in the chain of custody, a digitization discount applies and is directed to the [Community Pool](/docs/glossary#community-pool):
* The Waste Generator's **100% share** is redirected to the Community Pool.
* All other logistics and service providers (Haulers, [Processors](/docs/protocol/supply-chain), [Recyclers](/docs/protocol/supply-chain), and the [Network Integrator](/docs/protocol/network-integrators) — and the Bin Custodian where applicable) receive a **25% discount** on their payout, also directed to the Community Pool.
An unidentified Waste Generator cannot be associated with a confirmed Waste Manager relationship
for the asset. No Waste Manager share is distributed in this case; its 4% returns to the Hauler,
Processor, and Recycler categories as described above.
This applies to all waste types and geographies, serving as an incentive for further supply chain digitization. See [Rewards Distribution](/docs/protocol/rewards-distribution) for the full mechanics.
### Waste Generator discounts [#waste-generator-discounts]
A **50% discount** on the Waste Generator's share applies in two cases:
1. **Large Business** — Waste Generators classified as Large Businesses (revenue exceeding USD 4 million in the prior calendar year) receive 50% of their allocated share; the remaining 50% is directed to the [Impact Pool](/docs/glossary#impact-pool). This calibrates incentives proportionally while preserving participation motivation.
2. **Onboarding not yet completed** — because the distribution is calculated at the moment of sale, a Waste Generator that has not completed onboarding cannot be classified as a Large Business or not, so the 50% discount is applied automatically. The discounted half is directed to the [Impact Pool](/docs/glossary#impact-pool), and the generator's remaining 50% is held, claimable only after the generator completes onboarding. The held rewards follow the standard reward expiration window: if the generator completes onboarding and claims in time, they receive their share; if the rewards expire unclaimed, that half is directed to the [Community Pool](/docs/glossary#community-pool). This keeps the policy uniform while registration verification remains pending and incentivizes completing onboarding.
## Destination funds [#destination-funds]
Apart from the Distribution Fee and Registry, which cover network operations, what is not paid directly to participants is directed to one of three purpose-defined funds, depending on the mechanism it comes from — so it is always clear what each unit of value funds. These funds are financed transparently by design rather than at the operator's discretion.
* **[Foundation Treasury](/docs/glossary#foundation-treasury)** — the Carrot Foundation's operational resources, funded by the digital MRV and Integrity Component of each sale.
* **[Community Pool](/docs/glossary#community-pool)** — a discretionary fund for open-network growth (onboarding, expansion, marketing, events, competitive grants, ecosystem support). It is **not a donation fund**; value that would otherwise sit idle is recycled into ecosystem growth.
* **[Impact Pool](/docs/glossary#impact-pool)** — a pure-donation fund for socio-environmental and circular economy projects in the country where the recycling took place.
### What feeds the Community Pool [#what-feeds-the-community-pool]
Beyond the digitization discount above, the Community Pool is fed by the network's own integrity and incentive mechanisms:
* **Unredeemed rewards** — rewards not claimed within **90 calendar days** of the sale date, reinvested into network growth instead of sitting idle.
* **Self-policing penalties** — rewards withheld when the Carrot Foundation determines that bad or fraudulent data was submitted. Withholding is not automatic: for good-faith quality errors, a three-step process applies — (1) notice and acknowledgement, (2) a formal warning describing the failures and the required changes, and (3) a penalty notice withholding rewards if the failures are not corrected. In cases of fraud (deliberately false data), the penalty is absolute and applied directly, without the steps above.
* **Forfeited collateral** — where structured, collateral forfeited by participants who commit violations may be directed to the Community Pool.
### What feeds the Impact Pool [#what-feeds-the-impact-pool]
The Impact Pool's main source is the share redirected from **Large Business** Waste Generators (revenue exceeding USD 4 million) and the discounted half of generators whose onboarding is incomplete. This ensures credit buyers are not funding rewards to large corporations and channels that value into local impact.
[Learn about rewards distribution](/docs/protocol/rewards-distribution) · [Learn about the supply chain](/docs/protocol/supply-chain)
# Request for Proposals (RFP)
## What is an RFP? [#what-is-an-rfp]
A Request for Proposals (RFP) is a formal call in which the [Carrot Foundation](/docs/network/the-foundation) invites experts, developers, and organizations to submit proposals for a specific challenge, build a solution, or contribute to the platform ecosystem. Think of an RFP as a bridge between a need identified by Carrot (or the market) and the talent available in the community.
The RFP mechanism is central to Carrot's mission because it reflects three principles:
* **Transparency** — Public criteria and a documented process ensure every participant has the same information.
* **Documented selection** — Proposals are scored against published criteria, and selection follows the documented evaluation process.
* **Community engagement** — The community participates actively in building the platform.
Any individual or organization can participate in a Carrot RFP, provided they meet the eligibility
criteria defined in each call.
To preserve impartiality, community members eligible for deliberative governance processes cannot serve as evaluators on RFPs to which they have submitted a proposal.
## RFP types [#rfp-types]
Not all RFPs are the same. Each type is designed for a specific kind of contribution — the type determines what is expected from the proponent, which documents to submit, and how the proposal will be evaluated.
| Type | Name | Description |
| :---: | ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **A** | **Problem-solving** | Carrot identifies a problem or question and invites the community to propose approaches, analyses, or conceptual solutions. The focus is on idea quality, not immediate execution. |
| **B** | **AMC Project** | An Advance Market Commitment arranged by external buyers or funders — not operated by Carrot — funds the construction of infrastructure: biological treatment facilities, collection systems, or recycling chains. The proponent presents a full implementation and delivery plan. |
| **C** | **MvF Build** | A call to translate a validated scientific methodology into an operational Methodology Verification Framework. The proponent must demonstrate domain mastery and the ability to structure the artifacts the Carrot platform uses to execute the methodology. |
| **D** | **MvA Build** | A call to implement an approved MvF as code. The deliverable is the MvA (Methodology Verification Application) — the software that performs digital verification on the platform. Requires a completed MvF as a prerequisite. |
| **E** | **Technology Solution** | Development of a feature, tool, or integration for the Carrot platform. The deliverable is functional, tested, and documented code. |
| **F** | **Open** | Reserved for calls that do not fit other types. New categories may emerge as ecosystem needs evolve. |
New RFP types may be created as new needs arise in the ecosystem. Carrot reserves the right to
create or revoke types at any time, always respecting processes already in progress.
## Type dependencies [#type-dependencies]
Some RFP types have natural dependencies. For example, a Type D ([Methodology Verification Application (MvA)](/docs/standard/concepts/mva) Build) can only be opened after a Type C ([Methodology Verification Framework (MvF)](/docs/standard/concepts/mvf) Build) is completed, because the code needs an approved framework as reference. Similarly, a Type B (AMC Project) can generate subsequent Type C, D, and E needs — when an infrastructure project requires a new methodology to be operationalized and technology tools to function on the platform.
When reviewing an RFP, check whether it references dependencies on prior or concurrent calls.
## Lifecycle [#lifecycle]
Every Carrot RFP follows a standardized lifecycle with 10 phases, ensuring each call goes through the same preparation, engagement, evaluation, and execution stages regardless of type.
1. **Conception** — Carrot (or the market) identifies the need that originates the RFP and defines its initial scope.
2. **Structuring** — The RFP is drafted with scope, eligibility criteria, expected deliverables, timeline, and evaluation matrix.
3. **Publication** — The RFP is published and the community is notified. From this point, the document is public.
4. **Submission** — Proponents prepare and submit their proposals within the established deadline.
5. **Triage** — Proposals are checked against eligibility criteria. Those that do not meet minimum requirements are disqualified.
6. **Evaluation** — Eligible proposals are scored individually by independent evaluators using the weighted criteria matrix.
7. **Selection** — Proposals are ranked by final score and the evaluation committee makes a decision.
8. **Contracting** — The selected proponent negotiates final terms and formalizes the agreement with the Carrot Foundation.
9. **Execution** — Work proceeds according to the agreed timeline, with periodic oversight by Carrot.
10. **Closure** — Deliverables are verified, work is formally accepted, and lessons learned feed future calls.
## Key periods [#key-periods]
Each RFP defines its own timeline, but two periods deserve special attention:
**Q\&A period** — Between publication and the submission deadline, there is a window to submit questions. Answers are consolidated in a public FAQ available to all proponents. No privileged information is provided individually.
**Submission deadline** — Non-negotiable. Proposals received after the deadline will not be considered under any circumstances. The Carrot Foundation recommends submitting at least 24 hours early.
## Alternative entry channels [#alternative-entry-channels]
Although the RFP is the preferred mechanism, the ecosystem also accepts methodologies via strategic partnerships and direct initiative. In these cases, the proponent submits the proposal directly to Carrot, which evaluates relevance and quality using the same criteria applied to RFPs — preserving integrity, auditability, and ecosystem alignment requirements. The difference is that partnerships and direct submissions are evaluated on individual merit, without competition between proposals.
For practical guidance on participating in RFPs, see the [RFP Participation Guide](/docs/standard/guides/rfp-participation-guide).
[RFP Participation Guide](/docs/standard/guides/rfp-participation-guide) · [Methodology Lifecycle](/docs/standard/concepts/lifecycle) · [Methodology Ecosystem](/docs/standard/concepts/ecosystem)
# Versioning Policy
## SemVer conventions [#semver-conventions]
All digital MRV ([dMRV](/docs/protocol/dmrv)) methodologies in the [Carrot Network](/docs/network) follow [Semantic Versioning (SemVer)](https://semver.org/) to communicate the nature and impact of changes:
| Level | Meaning | Example |
| --------- | --------------------------------------------------------------------------------------------------- | --------------- |
| **MAJOR** | Breaking changes to verification logic that may affect existing integrations or alter rule outcomes | v1.0.0 → v2.0.0 |
| **MINOR** | New rules added or non-breaking enhancements to existing rules | v1.0.0 → v1.1.0 |
| **PATCH** | Bug fixes, documentation updates, or minor corrections that do not change rule behavior | v1.0.0 → v1.0.1 |
## Framework versioning [#framework-versioning]
[Methodology Verification Framework (MvF)](/docs/standard/concepts/mvf) documents are versioned independently. Each version represents a specific state of the verification specification:
* **MAJOR changes** require a new framework version and may include a migration guide for [Network Integrators](/docs/protocol/network-integrators) whose data submission patterns need to adapt.
* **MINOR changes** add new verification requirements without altering existing ones.
* **PATCH changes** clarify ambiguous specifications or correct documentation.
## Application versioning [#application-versioning]
[Methodology Verification Application (MvA)](/docs/standard/concepts/mva) releases track the MvF's MAJOR version to maintain alignment between specification and implementation:
* A new MvF MAJOR version triggers a new MvA MAJOR version.
* New rule implementations within the same MvF MAJOR version are MvA MINOR releases.
* Bug fixes in rule processors are MvA PATCH releases.
## Version lifecycle [#version-lifecycle]
Each version passes through defined stages:
1. **Draft** — Under development; not yet available for production use.
2. **Review** — Under Community of Experts review; may change before publication.
3. **Published** — Active in production; [MassID](/docs/protocol/mass-ids) documents are evaluated against this version.
4. **Deprecated** — Superseded by a newer version; a grace period allows integrators to transition.
## Transition policy [#transition-policy]
When a version is deprecated:
* **Grace period** — [Network Integrators](/docs/protocol/network-integrators) and [supply chain](/docs/protocol/supply-chain) participants are given advance notice to adapt to the new version.
* **Existing [credits](/docs/protocol/credits)** — Credits issued under a deprecated version remain valid and tradeable. Deprecation does not retroactively affect previously verified claims.
* **New submissions** — After the grace period, new MassID submissions must conform to the current published version.
## Update principles [#update-principles]
All methodology updates are governed by three inviolable principles:
1. **Historical traceability preservation** — No update may erase or make inaccessible a previous version. Outputs generated under a version must remain auditable under that version's rules. The ecosystem maintains a versioned repository with complete change history.
2. **Operational continuity** — Updates must not cause abrupt interruption to active methodologies. When changes affect validation rules, calculations, or eligibility, a transition period allows coexistence.
3. **Transparent governance** — Every change must be justified, documented, and communicated. Documentation records: what changed, why, who proposed, who approved, when it takes effect.
## Alteration categories [#alteration-categories]
| Category | Impact | Version increment | Approval |
| --------------------- | ---------------------------------------------------------------------------------------------------------------------- | ----------------- | -------------------------------------------------------------------------- |
| Minor corrections | No logic/calc/eligibility changes. Typos, formatting, references, wording clarifications. | PATCH | Internal curation with change record |
| Operational updates | Affect execution but not scientific basis. Adding/adjusting rules, refining eligibility, new events, metadata updates. | MINOR | Technical analysis by curation, Engineering consultation when MvA impacted |
| Substantive revisions | Modify calculation basis, key parameters, quantification logic, or fundamentals. | MAJOR | Full accreditation cycle |
### Who can propose alterations [#who-can-propose-alterations]
Changes can be proposed by: original MvF author, Operations & Methodologies team, Engineering team, independent VVBs, Community of Experts members. Each proposal must include: description, technical justification, expected impact, proposed category.
## Version coexistence [#version-coexistence]
When a new MvF version is published, the previous is not deactivated immediately. Both coexist during a transition period for MassIDs in transit.
The governing rule is **entry version**: each [MassID](/docs/protocol/mass-ids) is evaluated under the MvF version active at its first event (typically pick-up). New MassIDs after the effective date follow updated rules.
Typical transition periods: 30–90 days for operational updates, longer for substantive revisions (case by case).
[Learn about the methodology lifecycle](/docs/standard/concepts/lifecycle) · [Learn about the discontinuation policy](/docs/standard/policies/discontinuation)
# BOLD Carbon (CH₄) Framework
## Framework summary [#framework-summary]
| Property | Value |
| ---------------------- | ------------------------------------------------------------------------------------------------------ |
| **Methodology** | [AMS-III.F](/docs/methodologies/ams-iii-f) |
| **Version** | 1.0.2 |
| **Status** | Published |
| **Credit type** | Carbon Credit |
| **Token** | [TCC](/docs/protocol/credits#tokenized-carbon-credits-tcc) (`C-CARB.CH4`) — issued by this methodology |
| **External reference** | UNFCCC AMS-III.F v12.0 |
## Scope [#scope]
The BOLD Carbon (CH₄) [MvF](/docs/standard/concepts/mvf) defines verification procedures for achieving methane reductions through composting organic waste that would otherwise decompose anaerobically in landfills:
* **Waste types**: Food waste, green waste (garden, yard, and park trimmings), sludge from waste treatment plants, tobacco industry residues, and other organic subtypes classified under CDM waste codes
* **Treatment**: Aerobic composting at professional facilities
* **Geography**: Currently operational in Brazil, with the framework designed to be expandable to other regions
* **Environmental claim**: Methane reductions (CO2e) through composting
## Eligibility criteria [#eligibility-criteria]
Participants must meet the same accreditation requirements as [BOLD Recycling](/docs/methodologies/bold-recycling/framework):
* **[Waste generators](/docs/protocol/supply-chain)** — Must be identified with valid documentation.
* **Haulers** — Required for truck and boat transport; optional for sludge pipe and cart collection.
* **Processors** — Exactly one processor must be identified per [MassID](/docs/protocol/mass-ids).
* **[Recyclers](/docs/protocol/supply-chain)** — Exactly one recycler (composting facility) must be identified with valid accreditation dates.
* **[Network Integrators](/docs/protocol/network-integrators)** — Must have valid accreditation dates.
## Verification requirements [#verification-requirements]
BOLD Carbon (CH₄) includes all the verification checks present in BOLD Recycling, plus additional checks specific to emission quantification:
* **All shared checks** — Document validation, actor identification, event validation, geolocation, manifests, compliance, and integrity (see [BOLD Recycling Framework](/docs/methodologies/bold-recycling/framework))
* **Emissions calculation** — The `prevented-emissions` rule quantifies emission reductions (CO2e) using the UNFCCC AMS-III.F methodology
* **Project boundary** — The `project-boundary` rule validates the geographic distance between pick-up and drop-off locations
## Baseline scenario and emission factors [#baseline-scenario-and-emission-factors]
BOLD Carbon (CH₄) references the UNFCCC AMS-III.F v12.0 methodology for emission calculations:
* **Baseline scenario** — Organic waste decomposing anaerobically in a landfill, generating methane (CH4)
* **Project scenario** — The same organic waste composted aerobically, preventing methane generation
* **Emission factors** — Static factors are used for most organic waste subtypes. For waste classified under CDM code 8.7D ("Others, if organic"), dynamic factors are applied based on Ibama waste classification codes.
The `prevented-emissions` rule applies the formula: emission reductions (CO2e) equal the mass of composted waste multiplied by the emission reductions factor per ton, minus the mass multiplied by the exceeding emission coefficient.
## Scientific basis [#scientific-basis]
The following standards provide the scientific foundation for emission calculations and waste classification in BOLD Carbon (CH₄):
### UNFCCC Clean Development Mechanism [#unfccc-clean-development-mechanism]
| Reference | Version | Description |
| --------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **AMS-III.F** | v12.0 | "Avoidance of methane emissions through composting" (verbatim CDM title) — the basis for the `prevented-emissions` rule. Defines emission factors and calculation procedures for quantifying CH₄ reductions from composting organic waste. |
| **CDM Tool 04** | v8.0 | "Emissions from solid waste disposal sites" — provides methodologies for estimating methane emissions from landfill disposal, used as the baseline scenario in emission reduction calculations. |
| **CDM Tool 13** | v2.0 | "Project and leakage emissions from composting" — defines procedures for estimating project emissions and leakage from composting activities. |
### IPCC [#ipcc]
| Reference | Year | Description |
| ------------ | ---- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **IPCC AR5** | 2013 | Fifth Assessment Report — provides Global Warming Potential (GWP) values used in emission calculations. The GWP for methane (CH₄) is used to convert methane reductions to CO₂e. |
### Regional standards [#regional-standards]
| Reference | Jurisdiction | Description |
| --------------------------------------- | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Ibama Brazilian List of Solid Waste** | Brazil | Official waste classification system used by the `regional-waste-classification` rule. Maps waste types to CDM waste codes for emission factor selection. |
## Emission calculation parameters [#emission-calculation-parameters]
### Baseline emissions — CDM Tool 04 v8.0 [#baseline-emissions--cdm-tool-04-v80]
For calculating methane emissions from landfills and dump sites, BOLD Carbon (CH₄) uses [UNFCCC CDM Tool 04 v8.0](https://cdm.unfccc.int/methodologies/PAmethodologies/tools/am-tool-04-v8.0.pdf) — "Emissions from Solid Waste Disposal Sites."
| Parameter | Value | Description |
| -------------- | ----------------------------------------- | -------------------------------------------------------------------------------------------------- |
| φ | 0.85 | Model correction factor for model uncertainties |
| f | 0.00 (scenarios 1, 3) / 0.45 (scenario 2) | Fraction of methane captured and flared |
| GWP\_CH₄ | 28 | Global Warming Potential of methane ([IPCC AR5, 2013](https://www.ipcc.ch/assessment-report/ar5/)) |
| OX | 0.1 | Oxidation factor (methane oxidized in soil covering) |
| F | 0.5 | Fraction of methane in landfill gas (volume) |
| DOC\_f | 0.5 | Fraction of degradable organic carbon that decomposes |
| MCF | 1.0 (scenarios 1, 2) / 0.8 (scenario 3) | Methane correction factor |
| DOC\_j (food) | 0.15 | Degradable organic carbon fraction — food waste |
| DOC\_j (green) | 0.20 | Degradable organic carbon fraction — green waste |
| K\_j (food) | 0.40 | Decay rate — food waste (1/yr, wet tropical climate) |
| K\_j (green) | 0.17 | Decay rate — green waste (1/yr, wet tropical climate) |
Three baseline scenarios are supported:
1. **Landfill without methane flaring** — Highest emissions (f = 0)
2. **Landfill with methane flaring** — Moderate emissions (f = 0.45, \~50% capture at 90% burn efficiency)
3. **Dump site** — Intermediate emissions (MCF = 0.8)
### Real emissions — CDM Tool 13 v2.0 [#real-emissions--cdm-tool-13-v20]
For calculating emissions during composting, BOLD Carbon (CH₄) uses [UNFCCC CDM Tool 13 v2.0](https://cdm.unfccc.int/methodologies/PAmethodologies/tools/am-tool-13-v2.pdf) — "Project and Leakage Emissions from Composting."
| Parameter | Value | Description |
| --------- | -------------- | -------------------------------------------------------------------------------------------------------- |
| EF\_CH₄ | 2.0 g/kg waste | Methane emission factor per kg composted |
| EF\_N₂O | 0.2 g/kg waste | Nitrous oxide emission factor per kg composted |
| GWP\_CH₄ | 28 | Global Warming Potential of methane ([IPCC AR5, 2013](https://www.ipcc.ch/assessment-report/ar5/)) |
| GWP\_N₂O | 265 | Global Warming Potential of nitrous oxide ([IPCC AR5, 2013](https://www.ipcc.ch/assessment-report/ar5/)) |
Default emission factors are for "Fresh Weight" (gross weight including water content). Additional factors for fossil fuel and electricity consumption apply but are not shown in the simplified formula.
## Calculation example [#calculation-example]
For a composting facility using a 50/50 food waste to green waste ratio, comparing composting to landfill without methane capture:
| Metric | Value |
| ----------------------------------- | ------------------- |
| Baseline Emissions (BE) | 2.451 tons CO₂e |
| Real Emissions from composting (RE) | 0.218 tons CO₂e |
| **Emission Reductions (ER)** | **2.233 tons CO₂e** |
This means composting 1 ton of food waste + 1 ton of green waste delivers approximately 2.2 tons of CO₂e in emission reductions over a 20-year period compared to landfill disposal.
### Comparison across disposal methods [#comparison-across-disposal-methods]
| Disposal method | Total 20-year emissions | Reductions through composting |
| ------------------------ | ----------------------- | ----------------------------- |
| Landfill without flaring | 2.451 tons CO₂e | 2.233 tons CO₂e |
| Dump site | 1.961 tons CO₂e | 1.743 tons CO₂e |
| Landfill with flaring | 1.348 tons CO₂e | 1.130 tons CO₂e |
| **Composting** | **0.218 tons CO₂e** | — |
In every scenario, composting 1 ton of organic waste delivers more than 1 ton of CO₂e in emission reductions.
## Supported waste codes [#supported-waste-codes]
BOLD Carbon validates waste materials against the [Brazilian List of Solid Waste](https://www.gov.br/ibama/pt-br/assuntos/emissoes-e-residuos/residuos/arquivos/ibama-lista-brasileira-de-residuos-solidos.doc) published by [Ibama](/docs/glossary#ibama) (IN nº 13, December 18, 2012) and maps each Ibama code to a [CDM](/docs/glossary#cdm) waste category from CDM Tool 04 v08.1. This mapping is enforced at submission time by the `regional-waste-classification` rule — see the [Rules catalog](/docs/methodologies/ams-iii-f/bold-carbon/application/application-rules) and the [Waste Classification](/docs/integrations/reference/waste-classification) reference for additional context.
### CDM waste categories [#cdm-waste-categories]
The methodology supports **216 Ibama codes** across the following CDM categories:
| CDM Code | Category | Supported codes |
| -------- | ----------------------------------------------------------- | --------------- |
| 8.1 | Wood and wood products | 8 |
| 8.2 | Pulp, paper and cardboard (other than sludge) | 8 |
| 8.3 | Food, food waste, beverages and tobacco (other than sludge) | 12 |
| 8.4 | Textiles | 5 |
| 8.5 | Garden, yard and park waste | 1 |
| 8.6 | Glass, plastic, metal, other inert waste | 47 |
| 8.7B | Industrial Sludge | 14 |
| 8.7C | Domestic Sludge | 26 |
| 8.7D | Others (if organic) | 95 |
### Ibama code reference [#ibama-code-reference]
Expand each category below to see the accepted Ibama codes. The **Ibama Code** is the value to send as `Local Waste Classification ID`; the **Description** is validated against `Local Waste Classification Description`.
| Ibama Code | Description |
| ---------- | ---------------------------------------------------------------------------------------------------- |
| `02 01 07` | Resíduos silvícolas |
| `03 01 01` | Resíduos do descasque da madeira |
| `03 01 05` | Serragem, aparas, fitas de aplainamento, madeira, aglomerados e folheados não abrangidos em 03 01 04 |
| `03 03 01` | Resíduos do descasque de madeira e resíduos de madeira |
| `15 01 03` | Embalagens de madeira |
| `17 02 01` | Madeira |
| `19 12 07` | Madeira não abrangida em 19 12 06 |
| `20 01 38` | Madeira não abrangida em 20 01 37 |
| Ibama Code | Description |
| ---------- | ------------------------------------------------------------------------------------------------- |
| `03 03 07` | Rejeitos mecanicamente separados da fabricação de pasta a partir de papel e papelão usado |
| `03 03 08` | Resíduos da triagem de papel e papelão destinado a reciclagem |
| `03 03 10` | Rejeitos de fibras e lodos de fibras, fillers e revestimentos, provenientes da separação mecânica |
| `04 02 21` | Resíduos de fibras têxteis não processadas |
| `04 02 22` | Resíduos de fibras têxteis processadas |
| `15 01 01` | Embalagens de papel e cartão |
| `19 12 01` | Papel e cartão |
| `20 01 01` | Papel e cartão |
| Ibama Code | Description |
| ---------- | ----------------------------------------------------------------------------------------------------- |
| `02 01 02` | Resíduos de tecidos animais |
| `02 01 03` | Resíduos de tecidos vegetais |
| `02 02` | Resíduos da preparação e processamento de carne, peixe e outros produtos alimentares de origem animal |
| `02 02 02` | Resíduos de tecidos animais e orgânico de processo (sebo, soro, ossos, sangue, etc.) |
| `02 02 03` | Materiais impróprios para consumo ou processamento |
| `02 03 04` | Materiais impróprios para consumo ou processamento |
| `02 05 01` | Materiais impróprios para consumo ou processamento |
| `02 06 01` | Materiais impróprios para consumo ou processamento |
| `02 07 04` | Materiais impróprios para consumo ou processamento |
| `20 01 08` | Resíduos biodegradáveis de cozinhas e cantinas |
| `20 01 25` | Óleos e gorduras alimentares |
| `20 03 02` | Resíduos de mercados públicos e feiras |
| Ibama Code | Description |
| ---------- | ----------------------------------------------------------------------------- |
| `04 02 09` | Resíduos de materiais têxteis (têxteis impregnados, elastômeros, plastômeros) |
| `15 01 09` | Embalagens têxteis |
| `19 12 08` | Têxteis |
| `20 01 10` | Roupas |
| `20 01 11` | Têxteis |
| Ibama Code | Description |
| ---------- | --------------------------------------------------------------------------------------------------------------- |
| `20 02 01` | Resíduos de varrição, limpeza de logradouros e vias públicas e outros serviços de limpeza urbana biodegradáveis |
| Ibama Code | Description |
| ---------- | -------------------------------------------------------------------------------------------------------------------------- |
| `02 01 04` | Resíduos de plásticos (excluindo embalagens) |
| `15 01 02` | Embalagens de plástico |
| `15 01 04` | Embalagens de metal |
| `15 01 05` | Embalagens longa-vida |
| `15 01 06` | Misturas de embalagens |
| `15 01 07` | Embalagens de vidro |
| `16 01 17` | Sucatas metálicas ferrosas |
| `16 01 18` | Sucatas metálicas não ferrosas |
| `16 01 19` | Plástico |
| `16 01 20` | Vidro |
| `17 02 02` | Vidro |
| `17 02 03` | Plástico |
| `17 04 01` | Cobre, bronze e latão |
| `17 04 02` | Alumínio |
| `17 04 03` | Chumbo |
| `17 04 04` | Zinco |
| `17 04 05` | Ferro e aço |
| `17 04 06` | Estanho |
| `17 04 07` | Mistura de sucatas |
| `17 04 12` | Magnésio |
| `17 04 13` | Níquel |
| `17 05 04` | Solos e rochas não abrangidos em 17 05 03 |
| `17 05 08` | Britas de linhas ferroviárias não abrangidos em 17 05 07 |
| `17 06 04` | Materiais de isolamento não abrangidos em 17 06 01 e 17 06 03 |
| `17 09 04` | Mistura de resíduos de construção e demolição não abrangidos em 17 09 01, 17 09 02 e 17 09 03 |
| `19 01 02` | Materiais ferrosos removidos das cinzas |
| `19 01 12` | Cinzas e escórias não abrangidas em 19 01 11 |
| `19 01 18` | Resíduos de pirólise não abrangidos em 19 01 17 |
| `19 01 19` | Areias de leitos fluidizados |
| `19 03 05` | Resíduos estabilizados não abrangidos em 19 03 04 |
| `19 03 07` | Resíduos solidificados não abrangidos em 19 03 06 |
| `19 04 01` | Resíduos vitrificados |
| `19 08 02` | Resíduos do desarenamento |
| `19 09 04` | Carvão ativado usado |
| `19 09 05` | Resinas de troca iônica, saturadas ou usadas |
| `19 10 01` | Resíduos de ferro ou aço |
| `19 12 02` | Metais ferrosos |
| `19 12 03` | Metais não ferrosos |
| `19 12 04` | Plásticos |
| `19 12 05` | Vidro |
| `19 12 09` | Substâncias minerais (por exemplo, areia, rochas) |
| `19 12 11` | Borrachas |
| `20 01 02` | Vidro |
| `20 01 39` | Plásticos |
| `20 01 40` | Metais |
| `20 02 02` | Terras e pedras |
| `20 02 03` | Outros resíduos de varrição, limpeza de logradouros e vias públicas e outros serviços de limpeza urbana não biodegradáveis |
| Ibama Code | Description |
| ---------- | -------------------------------------------------------------------------------------------------- |
| `02 01 01` | Lodos provenientes da lavagem e limpeza |
| `02 02 01` | Lodos provenientes da lavagem e limpeza |
| `02 03 01` | Lodos de lavagem, limpeza, descasque, centrifugação e separação |
| `03 03 02` | Lodos da lixívia verde (provenientes da valorização da lixívia de cozimento ou licor negro) |
| `03 03 05` | Lodos de branqueamento, provenientes da reciclagem de papel |
| `03 03 09` | Resíduos de lodos de cal |
| `04 01 06` | Lodos, em especial do tratamento local de efluentes, contendo cromo |
| `04 01 07` | Lodos, em especial do tratamento local de efluentes, sem cromo |
| `04 01 10` | Lodo do caleiro |
| `10 01 23` | Lodos aquosas provenientes da limpeza de caldeiras não abrangidas em 10 01 22 |
| `19 06 05` | Lodo do tratamento anaeróbio de resíduos animais e vegetais |
| `19 06 06` | Lamas e lodos de digestores de tratamento anaeróbio de resíduos animais e vegetais |
| `19 06 99` | Outros resíduos não anteriormente especificados |
| `19 08 09` | Misturas de gorduras e óleos, da separação óleo/água, contendo apenas óleos e gorduras alimentares |
| Ibama Code | Description |
| ---------- | ------------------------------------------------------------------------------------- |
| `02 02 04` | Lodos do tratamento local de efluentes |
| `02 03 05` | Lodos do tratamento local de efluentes |
| `02 04 03` | Lodos do tratamento local de efluentes |
| `02 05 02` | Lodos do tratamento local de efluentes |
| `02 06 03` | Lodos do tratamento local de efluentes |
| `02 07 05` | Lodos do tratamento local de efluentes |
| `03 03 11` | Lodos do tratamento local de efluentes não abrangidas em 03 03 10 |
| `04 02 20` | Lodos do tratamento local de efluentes não abrangidas em 04 02 19 |
| `05 01 10` | Lodos do tratamento local de efluentes não abrangidas em 05 01 09 |
| `06 05 03` | Lodos do tratamento local de efluentes não abrangidas em 06 05 02 |
| `07 01 12` | Lodos do tratamento local de efluentes não abrangidas em 07 01 11 |
| `07 02 12` | Lodos do tratamento local de efluentes não abrangidas em 07 02 11 |
| `07 03 12` | Lodos do tratamento local de efluentes não abrangidas em 07 03 11 |
| `07 04 12` | Lodos do tratamento local de efluentes não abrangidas em 07 04 11 |
| `07 05 12` | Lodos do tratamento local de efluentes não abrangidas em 07 05 11 |
| `07 06 12` | Lodos do tratamento local de efluentes não abrangidas em 07 06 11 |
| `07 07 12` | Lodos do tratamento local de efluentes não abrangidas em 07 07 11 |
| `10 01 21` | Lodos do tratamento local de efluentes não abrangidas em 10 01 20 |
| `10 11 20` | Resíduos sólidos do tratamento local de efluentes não abrangidos em 10 11 19 |
| `10 12 13` | Lodos do tratamento local de efluentes |
| `19 06 03` | Lodo do tratamento anaeróbio de resíduos urbanos e equiparados |
| `19 06 04` | Lamas e lodos de digestores de tratamento anaeróbio de resíduos urbanos e equiparados |
| `19 08 05` | Lodos do tratamento de efluentes urbanos |
| `19 11 06` | Lodos do tratamento local de efluentes não abrangidas em 19 11 05 |
| `20 03 04` | Lodos de fossas sépticas |
| `20 03 06` | Resíduos da limpeza de esgotos, bueiros e bocas-de-lobo |
| Ibama Code | Description | % Carbon (wet basis) |
| ---------- | -------------------------------------------------------------------------------------------------------------------- | -------------------- |
| `02 01 06` | Fezes, urina e estrume de animais (incluindo palha suja), efluentes recolhidos separadamente e tratados noutro local | 15 |
| `02 02 99` | Outros resíduos não anteriormente especificados | — |
| `02 03 99` | Outros resíduos não anteriormente especificados | — |
| `02 04 04` | Vinhaça | 1.4 |
| `02 04 05` | Bagaço de cana-de-açúcar | 33 |
| `02 04 99` | Outros resíduos não anteriormente especificados | — |
| `02 05 99` | Outros resíduos não anteriormente especificados | — |
| `02 07 02` | Resíduos da destilação de álcool | 8.6 |
| `02 07 99` | Outros resíduos não anteriormente especificados | — |
| `03 01 99` | Outros resíduos não anteriormente especificados | — |
| `03 03 99` | Outros resíduos não anteriormente especificados | — |
| `04 01 01` | Resíduos das operações de descarne e divisão de tripa | 18 |
| `04 01 04` | Licores de curtimenta contendo cromo | — |
| `04 01 05` | Licores de curtimenta sem cromo | — |
| `04 01 08` | Aparas, serragem e pós de couro provenientes de couros curtidos ao cromo | 33 |
| `04 01 09` | Resíduos da confecção e acabamentos | — |
| `04 01 99` | Outros resíduos não anteriormente especificados | — |
| `04 02 10` | Matéria orgânica de produtos naturais (por exemplo, gordura, cera) | 18 |
| `04 02 15` | Resíduos dos acabamentos não abrangidos em 04 02 14 | 18 |
| `04 02 99` | Outros resíduos não anteriormente especificados | — |
| `05 06 99` | Outros resíduos não anteriormente especificados | — |
| `05 07 99` | Outros resíduos não anteriormente especificados | — |
| `06 02 99` | Outros resíduos não anteriormente especificados | — |
| `06 03 99` | Outros resíduos não anteriormente especificados | — |
| `06 04 99` | Outros resíduos não anteriormente especificados | — |
| `06 07 99` | Outros resíduos não anteriormente especificados | — |
| `06 09 99` | Outros resíduos não anteriormente especificados | — |
| `06 11 99` | Outros resíduos não anteriormente especificados | — |
| `07 01 99` | Outros resíduos não anteriormente especificados | — |
| `07 02 99` | Outros resíduos não anteriormente especificados | — |
| `07 03 99` | Outros resíduos não anteriormente especificados | — |
| `07 04 99` | Outros resíduos não anteriormente especificados | — |
| `07 05 14` | Resíduos sólidos não abrangidos em 07 05 13 | — |
| `07 05 99` | Outros resíduos não anteriormente especificados | — |
| `07 06 99` | Outros resíduos não anteriormente especificados | — |
| `07 07 99` | Outros resíduos não anteriormente especificados | — |
| `08 01 99` | Outros resíduos não anteriormente especificados | — |
| `08 02 99` | Outros resíduos não anteriormente especificados | — |
| `08 03 99` | Outros resíduos não anteriormente especificados | — |
| `08 04 99` | Outros resíduos não anteriormente especificados | — |
| `09 01 99` | Outros resíduos não anteriormente especificados | — |
| `10 01 99` | Outros resíduos não anteriormente especificados | — |
| `10 02 08` | Resíduos sólidos do tratamento de gases não abrangidos em 10 02 07 | — |
| `10 02 15` | Outras lodos e tortas de filtro | 9 |
| `10 02 99` | Outros resíduos não anteriormente especificados | — |
| `10 03 99` | Outros resíduos não anteriormente especificados | — |
| `10 04 99` | Outros resíduos não anteriormente especificados | — |
| `10 05 99` | Outros resíduos não anteriormente especificados | — |
| `10 06 99` | Outros resíduos não anteriormente especificados | — |
| `10 08 99` | Outros resíduos não anteriormente especificados | — |
| `10 09 99` | Outros resíduos não anteriormente especificados | — |
| `10 10 99` | Outros resíduos não anteriormente especificados | — |
| `10 11 99` | Outros resíduos não anteriormente especificados | — |
| `10 12 99` | Outros resíduos não anteriormente especificados | — |
| `10 13 99` | Outros resíduos não anteriormente especificados | — |
| `11 01 10` | Lodos e tortas de filtro não abrangidos em 11 01 09 | 9 |
| `11 01 99` | Outros resíduos não anteriormente especificados | — |
| `11 02 99` | Outros resíduos não anteriormente especificados | — |
| `11 05 99` | Outros resíduos não anteriormente especificados | — |
| `12 01 99` | Outros resíduos não anteriormente especificados | — |
| `16 01 99` | Outros resíduos não anteriormente especificados | — |
| `16 03 06` | Resíduos orgânicos não abrangidos em 16 03 05 | 5 |
| `16 07 99` | Outros resíduos não anteriormente especificados | — |
| `17 05 06` | Lodos de dragagem não abrangidas em 17 05 05 | 5 |
| `19 01 99` | Outros resíduos não anteriormente especificados | — |
| `19 02 03` | Misturas de resíduos contendo apenas resíduos não perigosos | 5 |
| `19 02 06` | Lodos de tratamento físico-químico não abrangidas em 19 02 05 | 5 |
| `19 02 99` | Outros resíduos não anteriormente especificados | — |
| `19 05 01` | Fração não compostada de resíduos urbanos e equiparados | 15 |
| `19 05 02` | Fração não compostada de resíduos animais e vegetais | 15 |
| `19 05 03` | Composto fora de especificação | 5 |
| `19 05 99` | Outros resíduos não anteriormente especificados | — |
| `19 07 02` | Lixiviados ou líquidos percolados de aterros contendo substâncias perigosas | — |
| `19 07 03` | Lixiviados ou líquidos percolados de aterros não abrangidos em 19 07 02 | 9 |
| `19 08` | Resíduos de estações de tratamento de efluentes (ETE) não anteriormente especificados | 9 |
| `19 08 01` | Resíduos retirados da fase de gradeamento | 5 |
| `19 08 12` | Lodos do tratamento biológico de efluentes industriais não abrangidas em 19 08 11 | 9 |
| `19 08 14` | Lodos de outros tratamentos de efluentes industriais não abrangidas em 19 08 13 | 9 |
| `19 08 99` | Outros resíduos não anteriormente especificados | — |
| `19 09 01` | Resíduos retirados da fase de gradeamento | 5 |
| `19 09 06` | Soluções e lodos da regeneração de colunas de troca iônica | — |
| `19 09 99` | Outros resíduos não anteriormente especificados | — |
| `19 10 02` | Resíduos não ferrosos | — |
| `19 10 06` | Outras frações não abrangidas em 19 10 05 | — |
| `19 11 99` | Outros resíduos não anteriormente especificados | — |
| `19 12 10` | Resíduos combustíveis (combustíveis derivados de resíduos) | — |
| `19 12 13` | Outros resíduos (incluindo misturas de materiais) do tratamento mecânico de resíduos não abrangidos em 19 12 12 | — |
| `19 13 02` | Resíduos sólidos da descontaminação de solos não abrangidos em 19 13 01 | — |
| `19 13 04` | Lodos da descontaminação de solos não abrangidas em 19 13 03 | — |
| `19 13 06` | Lodos da descontaminação de águas freáticas não abrangidas em 19 13 05 | — |
| `19 13 08` | Resíduos líquidos aquosos e concentrados aquosos da descontaminação de águas freáticas não abrangidos em 19 13 07 | — |
| `20 01 99` | Outras frações não anteriormente especificadas | — |
| `20 03 01` | Outros resíduos urbanos e equiparados, incluindo misturas de resíduos | 5 |
| `20 03 03` | Resíduos da limpeza de ruas e de galerias de drenagem pluvial | 20 |
| `20 03 99` | Resíduos urbanos e equiparados não anteriormente especificados | 5 |
For codes under CDM 8.7D where % Carbon is not listed, the recycler must specify the waste type and/or provide a laboratory report. The carbon fraction is used by the `prevented-emissions` rule (rule 21) to calculate dynamic emission factors — see [Baseline scenario and emission factors](#baseline-scenario-and-emission-factors).
## Key parameters [#key-parameters]
| Parameter | Value |
| ------------------------------ | ---------------------------------------------------------------------- |
| **Composting cycle timeframe** | Validated between DROP\_OFF and RECYCLED events |
| **Geolocation tolerance** | Participant addresses validated against accredited addresses |
| **Project boundary** | Distance between first PICK\_UP and last DROP\_OFF validated |
| **Document unit** | Kilograms (kg) |
| **Document type** | Organic |
| **Project period** | RECYCLED event must occur on or after January 1st of the previous year |
## Validation rules [#validation-rules]
See the [BOLD Carbon (CH₄) Application Rules](/docs/methodologies/ams-iii-f/bold-carbon/application/application-rules) catalog for the complete list of validation rules, grouped by category with descriptions.
## Downloads [#downloads]
Feedback: [method@carrot.eco](mailto:method@carrot.eco)
***
## Framework rules [#framework-rules]
Framework rules define **what** must be verified in the BOLD Carbon (CH₄) methodology. Each framework rule specifies a validation requirement at the specification level.
These rules are implemented by one or more [application rules](/docs/methodologies/ams-iii-f/bold-carbon/application/application-rules) that contain the executable validation logic. The mapping is not one-to-one: a single application rule may satisfy multiple framework rules, and a framework rule may require multiple application rules to fully verify.
[View application rules](/docs/methodologies/ams-iii-f/bold-carbon/application/application-rules) · [Learn about AMS-III.F](/docs/methodologies/ams-iii-f)
# BOLD Recycling Credit Framework
## Framework summary [#framework-summary]
| Property | Value |
| ---------------------- | ----------------------------------------------------------------------------------------------------- |
| **Methodology** | [BOLD Recycling](/docs/methodologies/bold-recycling) |
| **Version** | 1.0.1 |
| **Status** | Published |
| **Credit type** | Recycling Credit |
| **Token** | [TRC](/docs/protocol/credits#tokenized-recycling-credits-trc) (`C-BIOW`) — issued by this methodology |
| **Framework document** | [PDF](https://drive.google.com/file/d/1Qdod8Qy3zT4lBkUp1TIyuxguHIYTevJJ/view) |
## Scope [#scope]
The BOLD Recycling [MvF](/docs/standard/concepts/mvf) defines verification procedures for organic waste diversion from landfills to composting facilities:
* **Waste types**: Food waste, green waste (garden, yard, and park trimmings), sludge from waste treatment plants, tobacco industry residues, and other organic subtypes classified under CDM waste codes
* **Treatment**: Aerobic composting at professional facilities
* **Geography**: Currently operational in Brazil, with the framework designed to be expandable to other regions with compatible waste classification systems
## Eligibility criteria [#eligibility-criteria]
Participants must meet accreditation requirements:
* **[Waste generators](/docs/protocol/supply-chain)** — Must be identified with valid documentation. Accreditation dates are optional.
* **Haulers** — Required for truck and boat transport; optional for sludge pipe and cart collection.
* **Processors** — Exactly one processor must be identified per [MassID](/docs/protocol/mass-ids).
* **[Recyclers](/docs/protocol/supply-chain#the-role-of-the-recycler)** — Exactly one recycler (composting facility) must be identified with valid accreditation dates.
* **[Network Integrators](/docs/protocol/network-integrators)** — Must have valid accreditation dates.
## Verification requirements [#verification-requirements]
The framework specifies verification checks across the full supply chain:
* **Document validation** — MassID structure, type, unit, and value
* **Actor identification** — Presence and identity of all required participants
* **Event validation** — Weighing, sorting, drop-off, and composting cycle data
* **Geolocation** — Address matching between events and accredited locations
* **Manifests** — Required transport and recycling documentation
* **Compliance** — Regional waste classification and project period validity
* **Integrity** — Uniqueness checks to prevent double counting
## Key parameters [#key-parameters]
| Parameter | Value |
| ------------------------------ | ---------------------------------------------------------------------- |
| **Composting cycle timeframe** | Validated between Drop Off and Recycled events |
| **Geolocation tolerance** | Participant addresses validated against accredited addresses |
| **Document unit** | Kilograms (kg) |
| **Document type** | Organic |
| **Project period** | Recycled event must occur on or after January 1st of the previous year |
## Validation rules [#validation-rules]
See the [BOLD Recycling Application Rules](/docs/methodologies/bold-recycling/framework/application/application-rules) catalog for the complete list of validation rules, grouped by category with descriptions.
## Downloads [#downloads]
* [BOLD Recycling Methodology Framework v1.0.1 (PDF)](https://drive.google.com/file/d/1Qdod8Qy3zT4lBkUp1TIyuxguHIYTevJJ/view)
Feedback: [method@carrot.eco](mailto:method@carrot.eco)
***
## Framework rules [#framework-rules]
Framework rules define **what** must be verified in the BOLD Recycling methodology. Each framework rule specifies a validation requirement at the specification level.
These rules are implemented by one or more [application rules](/docs/methodologies/bold-recycling/framework/application/application-rules) that contain the executable validation logic. The mapping is not one-to-one: a single application rule may satisfy multiple framework rules, and a framework rule may require multiple application rules to fully verify.
[View application rules](/docs/methodologies/bold-recycling/framework/application/application-rules) · [Learn about BOLD Recycling](/docs/methodologies/bold-recycling)
# Contract Categories
## Overview [#overview]
The Carrot Network's smart contracts are organized into five categories, each with a distinct responsibility. This modular design keeps individual contracts focused and auditable, while the [ContractRegistry](#registries) ties them together at runtime.
| Category | Contracts | Responsibility |
| --------------- | ----------------------------------------------------------------------- | ----------------------------------- |
| **Controllers** | InventoryManager, CreditPurchaseManager, CreditRetirementManager | Business logic and orchestration |
| **Custodians** | Vault, RewardsVault | Asset custody and distribution |
| **NFTs** | MassID, Certificate, `CreditPurchaseReceipt`, `CreditRetirementReceipt` | Soulbound proof tokens (ERC-721) |
| **Tokens** | Credit | Fungible credit tokens (ERC-20) |
| **Registries** | ContractRegistry, CertificateRegistry | Discovery and relationship tracking |
## Controllers [#controllers]
Controllers are the entry points for all major operations. They orchestrate complex workflows that span multiple contracts, ensuring that each operation is executed atomically — either every step succeeds or none of them do.
### InventoryManager [#inventorymanager]
Creates the foundational on-chain assets. When verified data is ready for minting, the InventoryManager mints [MassID](/docs/protocol/mass-ids) NFTs, and then [Certificate](/docs/protocol/certificates) NFTs and [Credit](/docs/protocol/credits) tokens in a second transaction, at the moment the credit is issued from the verified batch. It also registers the relationships between these assets through the CertificateRegistry. All minted assets are deposited into the Vault.
### CreditPurchaseManager [#creditpurchasemanager]
Executes atomic [credit purchases](/docs/protocol/credit-purchase). In a single transaction, the CreditPurchaseManager:
* Validates the purchase order using an EIP-712 typed data signature
* Processes payment in USDC
* Updates the backing certificate records
* Transfers credit tokens to the buyer — for purchases that are not fully retired in the same transaction
* Mints a `CreditPurchaseReceipt` as permanent proof
* Records reward allocations for participants
The CreditPurchaseManager supports **integrated retirement** — purchasing and retiring credits in one transaction — and this is the path in use today: every purchase is currently retired in full at the moment of sale, so credits are burned rather than delivered to the buyer. The contracts also support partial retirement, with the remainder transferred to the buyer, which is not yet used in production.
### CreditRetirementManager [#creditretirementmanager]
Handles standalone [credit retirement](/docs/protocol/credit-retirement) for holders who want to permanently remove credits from circulation. The CreditRetirementManager burns the credit tokens, updates the backing certificate tracking, and mints a `CreditRetirementReceipt` as permanent proof of the retirement.
## Custodians [#custodians]
Custodians hold and manage assets on behalf of the network. They enforce strict access controls — only authorized contracts (controllers) can transfer or burn assets from custody.
### Vault [#vault]
The central custodian for all soulbound NFTs (MassIDs, Certificates, `CreditPurchaseReceipt` and `CreditRetirementReceipt` NFTs) and credit token balances before purchase. The Vault is the permanent home for every non-transferable token in the system, ensuring they remain permanent and traceable, except where revoked. Credit tokens are also held here as available inventory until a buyer purchases them.
### RewardsVault [#rewardsvault]
Manages the privacy-preserving [rewards distribution](/docs/protocol/rewards-distribution) system. During credit purchases, USDC payments are deposited into the RewardsVault, and cryptographic commitments (Merkle roots) representing the rewards distribution are committed on-chain. This keeps participant identities pseudonymous — only a purchase-scoped hash is stored on-chain, and the hashes on their own cannot be correlated across purchases. The claiming wallet and the amount become visible on-chain when the reward is withdrawn, so reusing one wallet links a participant's withdrawals to each other. Participants claim their rewards by providing Merkle proofs that are verified against the stored roots. The RewardsVault holds USDC allocated for rewards until participants claim them.
## NFTs (Soulbound ERC-721) [#nfts-soulbound-erc-721]
All NFTs in the Carrot Network are **soulbound** — non-transferable and permanently held by the Vault. No NFT can be transferred, sold, or traded. The only exception is [revocation](/docs/protocol/smart-contracts/on-chain-flows#revocation) — an operator can burn a MassID or Certificate and point its metadata at a revocation record when the underlying data is found to be incorrect; the original metadata and the reason stay recoverable on-chain.
### MassID [#massid]
Represents a verified batch of waste material. Each MassID records the material type, weight, and full chain of custody from waste generation through collection and sorting. MassIDs are the foundation of the [credit lifecycle](/docs/protocol/credit-lifecycle) — every certificate traces back to a single MassID.
### Certificate [#certificate]
Represents a verified environmental outcome — either recycling (RecycledID) or carbon emission reductions (GasID). Certificates are linked to their parent MassID via the CertificateRegistry and track their lifecycle through four quantities: the **total amount** (set at minting), the **purchased amount** (updated at each sale), the **retired amount** (updated at each retirement), and the **available amount** — derived at read time as total minus purchased; the retired amount does not affect it. This accounting model is central to preventing double-counting — the contract enforces that credits cannot be sold beyond the available balance, and cannot be retired beyond the amount that was actually purchased.
### CreditPurchaseReceipt [#creditpurchasereceipt]
Tamper-evident proof that a credit purchase occurred. Each receipt records which certificates were involved, the buyer's address, the amount purchased, and the payment details. Purchase receipts are visible in the [Carrot Registry](/docs/protocol/registry) and provide a permanent record for compliance and reporting.
### CreditRetirementReceipt [#creditretirementreceipt]
Permanent proof that credits were retired (burned). Retirement receipts record the certificates involved, the amount retired, and the retiring party. They are used for ESG reporting and regulatory compliance, and are viewable through the [Carrot Registry](/docs/protocol/registry) or any blockchain block explorer (e.g. [PolygonScan](https://polygonscan.com/)).
## Tokens (Fungible ERC-20) [#tokens-fungible-erc-20]
### Credit [#credit]
Fungible environmental credit tokens. The Carrot Network issues two credit types:
| Symbol | Name | Represents |
| ------------ | ----------------------------------------------------------------------------------------------------------------- | ------------------------------------------- |
| `C-BIOW` | Tokenized Recycling Credit (TRC), e.g. from [BOLD Recycling](/docs/methodologies/bold-recycling) | 1 metric ton of certified recycled material |
| `C-CARB.CH4` | Tokenized Carbon Credit (TCC), e.g. from [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) (methane) | 1 metric ton of CO₂-equivalent prevented |
Credits are the **only transferable tokens** in the system. They are designed for market activity — purchasing, holding, and retiring environmental offsets. All other tokens (MassIDs, certificates, receipts) are soulbound and cannot be transferred. The credit system is designed to support additional credit types beyond the current `C-BIOW` and `C-CARB.CH4` as new environmental methodologies are validated.
## Registries [#registries]
Registries provide the infrastructure for contract coordination and relationship tracking. They contain no business logic themselves but are essential to the system's upgradeability and traceability.
### ContractRegistry [#contractregistry]
The central registry that maps logical contract names to their deployed addresses on-chain. Instead of hardcoding addresses, contracts query the ContractRegistry to discover each other at runtime. This decouples contracts from each other's addresses. An ordinary logic upgrade needs no registry change at all — the proxy address is stable, so dependents keep resolving the same entry. The registry matters when a contract is fully **replaced** with a new proxy: that takes one registry write plus explicit state migration, instead of redeploying every dependent contract.
### CertificateRegistry [#certificateregistry]
Tracks the parent-child relationship between [MassID](/docs/protocol/mass-ids) tokens and their linked [certificates](/docs/protocol/certificates). Every certificate can be traced back through this registry to the specific waste batch it represents. The CertificateRegistry is what makes end-to-end traceability possible — from a retired credit, through its certificate, all the way back to the physical waste.
## Token relationships [#token-relationships]
The on-chain assets form a directed graph of relationships:
* **MassID → Certificate** — Linked via the CertificateRegistry. A single MassID can back several certificates; each certificate is backed by exactly one MassID.
* **Certificate → Credit** — Credit tokens are generated at minting time in amounts corresponding to their backing certificates.
* **`CreditPurchaseReceipt`** and **`CreditRetirementReceipt`** — Record transactions against specific certificates, providing the audit trail for every purchase and retirement.
This structure ensures that every credit in circulation can be traced back through its certificate to the specific waste batch that produced it.
## Next steps [#next-steps]
* [On-Chain Flows](/docs/protocol/smart-contracts/on-chain-flows) — Step-by-step walkthrough of how these contracts interact during minting, purchasing, and retirement.
* [Security](/docs/protocol/smart-contracts/security) — Access control, pausability, and governance protections.
* [Credit Lifecycle](/docs/protocol/credit-lifecycle) — The MassID → Certificate → Credit lifecycle.
# Contract Architecture Overview
## Why the registry runs on a public blockchain [#why-the-registry-runs-on-a-public-blockchain]
The Carrot Network records every [environmental credit](/docs/protocol/credits) on a public blockchain to guarantee three properties that traditional databases cannot:
* **Immutability** — Every issuance, purchase, and retirement is permanently recorded on-chain, and provenance metadata is content-addressed on IPFS, where continued availability depends on active pinning. A token's metadata pointer can be corrected by governance, and MassIDs and certificates can be revoked — in both cases the change is itself recorded on-chain. Protocol-level contract logic (single-use checks and permanent destruction on retirement) prevents double-counting.
* **Transparency** — All transactions are publicly verifiable on the blockchain. Anyone can inspect the complete history of a credit via the [Carrot Registry](/docs/protocol/registry) or any blockchain block explorer (e.g. [PolygonScan](https://polygonscan.com/)), without requiring special access or credentials. Trust and verification do not depend on Carrot's infrastructure.
* **Auditability** — Registry records and every credit lifecycle event (issuance, purchase, retirement) exist on-chain. Together with platform data in the [Carrot Registry](/docs/protocol/registry), the full chain from physical waste to retired credit is traceable. Auditors, regulators, and stakeholders can independently verify the lifecycle without relying on a single party's records.
## Deployment [#deployment]
The Carrot Network's smart contracts are implemented in Solidity and compatible with any EVM-compatible blockchain. They are currently deployed on [Polygon PoS](https://polygon.technology/), which was selected for its low transaction costs and full EVM compatibility, allowing the network to process high volumes of registry-record creation, purchasing, and retirement operations without prohibitive gas fees while maintaining compatibility with the broader Ethereum ecosystem. The platform is blockchain network agnostic and could deploy on other EVM-compatible networks in the future.
## Architecture overview [#architecture-overview]
The smart contract ecosystem follows a **modular architecture** organized into five contract categories. Each category has a well-defined responsibility, and contracts interact through well-defined interfaces rather than monolithic logic.
| Category | Contracts | Role |
| --------------- | ------------------------------------------------------------------- | ------------------------------------------------------- |
| **Controllers** | InventoryManager, CreditPurchaseManager, CreditRetirementManager | Orchestrate multi-contract operations |
| **Custodians** | Vault, RewardsVault | Hold and manage assets (credits, NFTs, USDC) |
| **NFTs** | MassID, Certificate, CreditPurchaseReceipt, CreditRetirementReceipt | Soulbound ERC-721 tokens representing assets and proofs |
| **Tokens** | Credit | Fungible ERC-20 environmental credit tokens |
| **Registries** | ContractRegistry, CertificateRegistry | Service discovery and relationship tracking |
This separation keeps each contract focused and auditable. Controllers contain the business logic, custodians manage asset custody, and NFTs and tokens represent the assets themselves. Registries provide the infrastructure that ties everything together.
## Design principles [#design-principles]
### Upgradeability (UUPS) [#upgradeability-uups]
All contracts use the **Universal Upgradeable Proxy Standard (UUPS)**, allowing the protocol to evolve without losing state or requiring redeployment. When a contract is upgraded, its address stays the same and its stored data carries over — the logic changes, and the upgrade call can also run a migration against that existing storage. This enables the team to fix bugs, add features, and improve efficiency while preserving the integrity of the on-chain record.
### Registry-based discovery [#registry-based-discovery]
Contracts locate each other through the **ContractRegistry** using logical keys rather than hardcoded addresses. This decouples contracts from each other and enables independent upgrades. A logic upgrade keeps the proxy address, so no registry change is needed and every peer keeps resolving the same entry. The registry matters when a contract is replaced by a new proxy: updating that single registry entry repoints every peer without redeploying any of them. Either way, individual contracts can be improved, patched, or extended without a system-wide redeployment.
### Soulbound NFTs [#soulbound-nfts]
All NFTs in the Carrot Network are [**soulbound**](/docs/protocol/credit-lifecycle) — **non-transferable** and permanently held by the Vault contract. This preserves the integrity of the environmental audit trail — tokens cannot be moved, sold, or hidden. A MassID or [certificate](/docs/protocol/certificates) can be burned by [revocation](/docs/protocol/smart-contracts/on-chain-flows#revocation); every issuance, transfer attempt, and revocation stays in the on-chain event log, so the chain of evidence survives the token.
### Meta-transactions [#meta-transactions]
Buyers never need to hold the network's native gas token or pay blockchain transaction fees — Carrot submits purchase and retirement transactions on their behalf, removing a significant barrier to adoption for buyers new to blockchain. The credit purchase and retirement contracts implement the **ERC-2771** meta-transaction standard, so this can also be delegated to a trusted relayer.
### Role-based access control [#role-based-access-control]
Every contract implements **RBAC** with defined roles for day-to-day operations, upgrades, and emergency actions. The five roles are assigned to five distinct addresses, so routine operation requires more than one key. See [Security](/docs/protocol/smart-contracts/security) for what that separation does and does not guarantee.
### Pausability [#pausability]
Critical operations can be paused in emergencies, halting every balance movement across the contract while a vulnerability or incident is investigated. Emergency pauses **carry a 48-hour expiry**, after which any account can lift them. Standard pauses, held by a separate pauser role, persist until explicitly lifted. See [Security](/docs/protocol/smart-contracts/security) for the full access control and pausability model, including how an ongoing incident is held open past that window.
## Next steps [#next-steps]
* [Contract Categories](/docs/protocol/smart-contracts/contract-categories) — Detailed breakdown of each contract and its role in the system.
* [On-Chain Flows](/docs/protocol/smart-contracts/on-chain-flows) — Step-by-step walkthrough of minting, purchasing, rewards, and retirement.
* [Security](/docs/protocol/smart-contracts/security) — Access control, governance security, and anti-manipulation mechanisms.
# On-Chain Flows
## Overview [#overview]
The Carrot Network's [smart contracts](/docs/protocol/smart-contracts) execute five major on-chain flows. Every transaction is **atomic** — either every step completes successfully or none of them do, preventing partial state changes. Minting spans two transactions by design, because they happen at different moments: the MassID is minted when the waste batch is verified, and the certificate is minted when the credit is issued from it.
All transactions are recorded on-chain and visible through any blockchain block explorer (e.g., [PolygonScan](https://polygonscan.com/)). The main operations are also reflected in the [Carrot Registry](/docs/protocol/registry) with environmental context and traceability data.
## Minting [#minting]
When verified data is ready for minting, the **InventoryManager** creates the foundational on-chain assets in two steps, each its own transaction.
### Step 1 — MassID minting [#step-1--massid-minting]
[MassID](/docs/protocol/mass-ids) NFTs are minted to the [Vault](/docs/protocol/smart-contracts), each with an [IPFS](https://ipfs.tech/) metadata URI containing provenance data: material type, weight, geographic origin, and the full chain of custody from waste generation through collection and sorting.
### Step 2 — Certificate and credit minting [#step-2--certificate-and-credit-minting]
[Certificate](/docs/protocol/certificates) NFTs are minted and linked to their parent MassIDs via the CertificateRegistry. Corresponding [credit](/docs/protocol/credits) tokens (ERC-20) are minted in matching amounts and deposited into the Vault.
After minting, all assets are held by the Vault and ready for credit purchases. The CertificateRegistry records which MassID backs each certificate, establishing the traceability chain that persists for the lifetime of those assets.
## Credit purchase [#credit-purchase]
An **atomic transaction** executed by the CreditPurchaseManager that handles the entire [purchase](/docs/protocol/credit-purchase) in a single operation. If any step fails, the entire transaction reverts.
### Step 1 — Purchase signature validation [#step-1--purchase-signature-validation]
The purchase order is verified using an **EIP-712** typed data signature from an authorized signer. This cryptographic validation ensures that only legitimate, pre-approved purchase orders are executed on-chain.
### Step 2 — Payment [#step-2--payment]
USDC is transferred from the payer to the RewardsVault, where it becomes available for [rewards distribution](/docs/protocol/rewards-distribution) to participants.
### Step 3 — Certificate update [#step-3--certificate-update]
The purchased amount is recorded on each backing certificate, reducing the available inventory. This ensures that the same credits cannot be sold twice.
### Step 4 — Credit delivery or retirement [#step-4--credit-delivery-or-retirement]
Today every purchased credit is retired in the same transaction, so no credit tokens are delivered to the buyer's wallet. The contracts also support partial retirement, with credit tokens (e.g. `C-BIOW`, `C-CARB.CH4`) transferred from the Vault to the buyer's wallet for the remainder — a capability that is not yet used in production.
### Step 5 — Receipt minting [#step-5--receipt-minting]
A **`CreditPurchaseReceipt`** NFT is minted to the Vault as permanent, tamper-evident proof of the transaction. The receipt records the certificates involved, the buyer, the amount, and the payment details.
### Step 6 — Rewards recording [#step-6--rewards-recording]
A Merkle root representing the complete rewards distribution is recorded in the RewardsVault. This enables participants to claim their share of the payment without revealing participant details on-chain.
### Integrated retirement [#integrated-retirement]
With **integrated retirement**, the credits are burned (instead of transferred to the buyer) in the same transaction, and a `CreditRetirementReceipt` is also minted. This is how every purchase works today: buyers acquire and retire credits in a single step, and claim the environmental offset immediately.
## Rewards distribution [#rewards-distribution]
Rewards distribution uses a **privacy-preserving mechanism** that keeps individual participant identities off-chain while maintaining on-chain verifiability.
### Recording [#recording]
During each credit purchase, a **Merkle root** is committed on-chain in the RewardsVault. This root represents the complete rewards distribution for that transaction. Participant identities stay pseudonymous — only hashed commitments are stored publicly on-chain. The underlying distribution data is maintained off-chain by the backend.
### Claiming [#claiming]
Participants can claim their rewards by providing **Merkle proofs** that verify their entitlement against the on-chain root. The RewardsVault validates the proof and releases the allocated USDC to the claimant. Each allocation can only be claimed once — the contract tracks claimed status to prevent double-claiming.
### Auditability [#auditability]
While individual participant identities are not visible on-chain, authorized auditors can access the underlying distribution data to identify participants for compliance purposes. The on-chain Merkle roots serve as cryptographic commitments that the off-chain data has not been tampered with.
## Credit retirement (standalone) [#credit-retirement-standalone]
For credit holders who want to [retire](/docs/protocol/credit-retirement) credits they already own, the **CreditRetirementManager** executes a standalone retirement flow.
### Step 1 — Retirement signature validation [#step-1--retirement-signature-validation]
The retirement order is verified using an **EIP-712** typed data signature, ensuring only authorized retirement requests are processed.
### Step 2 — Credit burning [#step-2--credit-burning]
Credit tokens are **burned** (permanently destroyed) from the Vault's own balance, not directly from the holder's wallet. The holder therefore transfers the credits to the Vault first, as an ordinary token transfer.
That deposit is a separate transaction, outside the atomic retirement described here: if the retirement order then fails, the deposit does not roll back with it, and the contracts expose no return path — only authorized controllers can move assets out of the Vault. Retry the retirement order rather than treating the credits as lost.
Burned tokens can never be recovered or re-issued — the environmental offset is permanently claimed.
### Step 3 — Certificate tracking [#step-3--certificate-tracking]
The retired amounts are recorded on the backing certificates, updating their retirement totals. This maintains accurate accounting across the certificate layer.
### Step 4 — Receipt minting [#step-4--receipt-minting]
A **`CreditRetirementReceipt`** NFT is minted to the Vault as permanent proof of the retirement. This receipt is the definitive on-chain evidence that the credits were retired.
Retired credits are recorded on the blockchain and visible through the Carrot Registry, providing transparent, auditable evidence that the environmental offset has been claimed and cannot be double-counted.
## Revocation [#revocation]
Assets can be revoked when underlying data is found to be incorrect or fraudulent. Revocation is a protective mechanism that preserves the credibility of the Carrot Network's environmental claims.
### MassID revocation [#massid-revocation]
Revoking a MassID does **not** cascade to its certificates:
* Linked certificates are not revoked automatically. Each certificate must be revoked on its own, before the MassID, to avoid leaving active certificates linked to a revoked MassID.
* **Protection**: A MassID cannot be revoked while any still-linked certificate has purchased credits — revoking it validates that every linked certificate would itself be revocable. This prevents retroactively invalidating credits that buyers have already purchased in good faith. Certificates that were already revoked are unlinked from the MassID by their own revocation, so they no longer block it.
### Certificate revocation [#certificate-revocation]
Individual certificates can be revoked **independently** without affecting the parent MassID or sibling certificates. This allows targeted corrections when only specific environmental claims need to be invalidated.
* As with MassID revocation, certificate revocation is blocked if credits from that certificate have already been sold.
### Audit trail preservation [#audit-trail-preservation]
Revoking an asset flags it as revoked, replaces its metadata URI with a revocation record, and burns the NFT — and for certificates, unlinks it from its parent MassID in the CertificateRegistry. The revoked flag stays permanently readable on-chain, and the revocation reason together with the original metadata URI remain permanently readable in the transaction event log. Auditors and regulators can still reconstruct the full history, even though the token itself no longer exists.
## Next steps [#next-steps]
* [Contract Categories](/docs/protocol/smart-contracts/contract-categories) — Detailed breakdown of each contract involved in these flows.
* [Security](/docs/protocol/smart-contracts/security) — How access control, pausability, and governance protect these operations.
* [Purchasing Credits](/docs/protocol/credit-purchase) — The buyer perspective on credit purchases.
* [Retiring Credits](/docs/protocol/credit-retirement) — How and why credits are permanently retired.
# Security
## Overview [#overview]
Security in the Carrot Network operates at two levels: **smart contract security** protecting on-chain assets, and **governance security** protecting the network from manipulation and hostile actions.
## Smart contract security [#smart-contract-security]
The Carrot Network's smart contracts implement multiple security layers:
### Role-Based Access Control (RBAC) [#role-based-access-control-rbac]
Privileged functions are gated by role, and separation of duties is validated when each contract is initialized, so the five roles start on five distinct addresses. That check runs at initialization only: `DEFAULT_ADMIN_ROLE` can grant any role afterwards, so keeping them separate is a governance discipline rather than something the contract re-enforces. Public entry points such as `purchase` and `retire` are open to any caller but execute only against an order signed by an authorized backend signer (see [EIP-712](#eip-712-typed-data-signatures) below). The system defines five standard roles:
* **`DEFAULT_ADMIN_ROLE`** — Contract ownership and role management. This role can grant or revoke any other role.
* **`UPGRADER_ROLE`** — Can upgrade contract implementations via UUPS proxy. Separated from admin to limit blast radius.
* **`OPERATOR_ROLE`** — Day-to-day operations such as minting MassIDs, issuing certificates, and executing revocations.
* **`PAUSER_ROLE`** — Standard pause mechanism for orderly operational halts.
* **`EMERGENCY_PAUSER_ROLE`** — Circuit breaker for critical failures. An emergency pause carries a 48-hour expiry, but it does not lift itself: once the expiry passes, any account — not only a role holder — can call `checkAndUnpause()` to end it. A compromised emergency account can pause again as soon as a pause is lifted, so containment is revoking `EMERGENCY_PAUSER_ROLE`, not waiting the window out.
Governance is distributed across these distinct roles, each currently held by a separate holder, so day-to-day operation requires more than one party. Critical operations — contract upgrades and changes to critical parameters — require multi-party approval before they execute.
### Pausability [#pausability]
Contracts can be paused in standard or emergency mode, halting operations if a vulnerability or attack is detected. Standard pauses require the `PAUSER_ROLE` and persist until explicitly unpaused. Emergency pauses, triggered by the `EMERGENCY_PAUSER_ROLE`, expire after 48 hours, so an emergency responder acting alone cannot hold a pause open indefinitely. While an emergency pause is active, the `PAUSER_ROLE` can extend it into an indefinite pause (`extendPause`), which is how a real incident is held open past that window.
### UUPS upgradeability [#uups-upgradeability]
Contracts use the Universal Upgradeable Proxy Standard, allowing bug fixes and improvements while maintaining the same contract addresses and state. The `ContractRegistry` provides centralized service discovery so upgrades propagate cleanly across the system.
### EIP-712 typed data signatures [#eip-712-typed-data-signatures]
Critical operations like credit purchases and retirements require cryptographically signed, structured data before they can execute on-chain. This means every order must be digitally signed by an authorized party — the smart contract verifies this signature before processing, rejecting any transaction that wasn't properly authorized. This prevents unauthorized parties from executing operations and ensures that signed orders cannot be replayed (used more than once).
Specifically:
* **CreditPurchaseManager** and **CreditRetirementManager** use EIP-712 typed data signatures to authorize purchase and retirement orders.
* **RewardsVault** uses EIP-712 for withdrawal authorization, ensuring that reward distributions are explicitly approved.
### Soulbound custody [#soulbound-custody]
All NFTs ([MassIDs](/docs/protocol/mass-ids), [certificates](/docs/protocol/certificates), receipts) are soulbound and held by the [Vault](/docs/protocol/smart-contracts/contract-categories#custodians) smart contract. They cannot be transferred, traded, or stolen. This design is intentional for these reasons:
* **Provenance integrity** — The chain from waste collection through certification to credit issuance remains permanent and verifiable on-chain.
* **No speculative trading** — Environmental audit records should reflect real-world recycling work, not market speculation.
* **Simplified security model** — Eliminating transfers removes an entire class of attack vectors related to marketplace interactions, approval exploits, and unauthorized token movement.
### Reentrancy protection [#reentrancy-protection]
A reentrancy attack occurs when a malicious contract interrupts an operation mid-execution — for example, triggering a withdrawal repeatedly before the balance is updated, draining funds that should no longer be available. All value-moving operations in the Carrot Network are protected against this class of attack using OpenZeppelin's `ReentrancyGuard`, which ensures each operation completes fully before any new call can begin.
## Governance security [#governance-security]
The [Carrot Foundation](/docs/network/the-foundation) implements systematic reward and punishment mechanisms that scale the cost of malicious behavior faster than any revenue it could generate:
* **Participant reputation tracking (planned)** — A future mechanism to track participant behavior across the network, surfacing patterns that indicate bad actors, so that sensitive operations can be gated by reputation thresholds. It is not implemented today.
* **Wallet verification** — Additional verification steps can be enacted if needed to increase security, which may trade ease of onboarding for stronger protections.
* **Moderation** — The Foundation's oversight team can flag behavior violating community guidelines and limit access to reduce risk. Moderators also work to detect and penalize automated manipulation attempts (anti-botting).
* **Punitive measures** — When violations are confirmed, penalties are issued through governance decisions. The Foundation can revoke a participant's platform membership, removing dashboard and API access; the operator role can revoke an issued MassID or certificate. There is no per-wallet freeze or blocklist in any contract — a pause halts every balance movement on the contract at once, never one holder's balance on its own.
## Design philosophy [#design-philosophy]
The security strategy follows a principle: make the cost of attacking the network always exceed the potential reward. As the ecosystem grows and more participants build genuine reputation, the barrier to coordinated manipulation scales proportionally — protecting the network's integrity as it becomes more valuable.
[Learn about smart contracts](/docs/protocol/smart-contracts) · [Learn about governance](/docs/network/governance)
# BOLD Carbon (CH₄) Rules Reference
## Overview [#overview]
These are the **application rules** — the executable validation logic that runs against each [MassID](/docs/protocol/mass-ids) document. Each rule evaluates a document and returns **PASSED**, **FAILED**, or **REVIEW\_REQUIRED** with an explanation.
Each application rule satisfies one or more [framework rules](/docs/methodologies/ams-iii-f/bold-carbon#framework-rules) from the BOLD Carbon (CH₄) [methodology framework](/docs/standard/concepts/mvf). See the "Implements framework rules" section in each rule's details for the mapping.
The BOLD Carbon (CH₄) framework defines a set of open-source rules to verify that organic waste has been properly diverted from landfills and composted, preventing methane emissions.
BOLD Carbon (CH₄) shares most rules with [BOLD Recycling](/docs/methodologies/bold-recycling/framework/application/application-rules) and adds methodology-specific rules for emissions calculation and geographic boundary validation.
Rules execute in a defined order against MassID documents. Passing them all is what triggers issuance of the [GasID certificate](/docs/protocol/certificates#gasid).
All rules are licensed under LGPL-3.0: [github.com/carrot-foundation/methodology-rules](https://github.com/carrot-foundation/methodology-rules)
[View on Carrot Registry](https://registry.carrot.eco/document/9498dd79-97ca-4efb-b47d-a8b61cf1f995)
## MassID rules [#massid-rules]
These rules validate individual [MassID](/docs/protocol/mass-ids) documents. They execute in the order shown. Rules 1–19 are shared with BOLD Recycling; rule 20 is Carbon-exclusive.
See the [Rewards Distribution Policy](/docs/standard/policies/rewards-distribution) for the full percentage breakdown by actor type and waste category.
[Learn about AMS-III.F](/docs/methodologies/ams-iii-f) · [Learn about BOLD Recycling rules](/docs/methodologies/bold-recycling/framework/application/application-rules)
# BOLD Carbon — MassID Event Reference
## How to read this page [#how-to-read-this-page]
Each event below shows the canonical JSON payload [integrators](/docs/protocol/network-integrators) send to the Documents API.
The `isPublic` flags inside each example are Carrot's recommended visibility — see
[Privacy & Masking](/docs/integrations/guides/privacy-and-masking) for the model.
Each payload references its participant and address by `participantId` and `addressId`. Resolve each one
first — retrieve it by key or create it — via the [Participants API](/docs/integrations/api/participants);
sending full `participant` and `address` objects inline is also supported and find-or-creates the record.
Send exactly one form of each pair — both, or neither, fails with `400 VALIDATION_ERROR`. The rule is the same on the single-event and batch endpoints.
> Per-event attribute dictionaries (definitions, types, sensitive flags, conditional rules)
> are the planned next addition to this page.
## Create MassID document [#create-massid-document]
The initial `POST /documents` call that creates a MassID. Not an event on the document's
timeline — included here as the starting point for integrator flows. The
[Waste Generator](/docs/protocol/supply-chain) is the creator; events are added to this
document afterward.
## ACTOR — Waste Generator [#actor--waste-generator]
## ACTOR — Recycler [#actor--recycler]
## ACTOR — Processor [#actor--processor]
## ACTOR — Hauler [#actor--hauler]
## ACTOR — Integrator [#actor--integrator]
## Pick-up [#pick-up]
## Transport Manifest [#transport-manifest]
## Weighing [#weighing]
## Drop-off [#drop-off]
## Sorting [#sorting]
## Recycled [#recycled]
## Recycling Manifest [#recycling-manifest]
# BOLD Carbon (CH₄) Application Overview
## Application summary [#application-summary]
| Property | Value |
| --------------- | -------------------------------------------------------------------------------------------------------- |
| **Methodology** | [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) |
| **Version** | 1.0.0 |
| **License** | LGPL-3.0 |
| **Repository** | [github.com/carrot-foundation/methodology-rules](https://github.com/carrot-foundation/methodology-rules) |
## Architecture [#architecture]
The BOLD Carbon (CH₄) [MvA](/docs/standard/concepts/mva) is implemented in the open-source methodology-rules monorepo. It follows the two-layer architecture shared by all BOLD methodologies:
* **Shared rule libraries** — Common verification logic reused across all BOLD methodologies. Located in the shared rule processors directory.
* **BOLD Carbon (CH₄) application wrappers** — Thin deployment layers that wrap shared libraries as serverless functions, located in the BOLD Carbon (CH₄) application directory. This includes Carbon-exclusive rules (`prevented-emissions`, `project-boundary`) that do not exist in the shared layer.
Each rule is an independent serverless function that evaluates [MassID](/docs/protocol/mass-ids) documents and returns PASSED, FAILED, or REVIEW\_REQUIRED with an explanation.
For the complete rules catalog with execution order, see [Application Rules](/docs/methodologies/ams-iii-f/bold-carbon/application/application-rules).
## Source code [#source-code]
The repository is organized as follows:
* **Shared rule libraries** — [libs/methodologies/bold/rule-processors/](https://github.com/carrot-foundation/methodology-rules/tree/main/libs/methodologies/bold/rule-processors/) contains the shared rule implementations used by all BOLD methodologies.
* **BOLD Carbon (CH₄) deployments** — [apps/methodologies/bold-carbon/rule-processors/](https://github.com/carrot-foundation/methodology-rules/tree/main/apps/methodologies/bold-carbon/rule-processors/) contains the deployment wrappers for this methodology, including the Carbon-exclusive rules.
See the repository README for navigation guidance and contribution instructions.
[Learn about AMS-III.F](/docs/methodologies/ams-iii-f) · [Learn about the framework](/docs/methodologies/ams-iii-f/bold-carbon) · [View rules catalog](/docs/methodologies/ams-iii-f/bold-carbon/application/application-rules) · [Integration guide](/docs/methodologies/ams-iii-f/bold-carbon/application/integration)
# BOLD Carbon (CH₄) Integration Guide
This guide explains how to submit [MassID](/docs/protocol/mass-ids) documents that satisfy
[BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) rules. BOLD Carbon shares most rules with
[BOLD Recycling](/docs/methodologies/bold-recycling) and adds one Carbon-exclusive rule for
emissions calculation. Geographic boundary validation is handled at the framework level.
For the base API flow, see [Submitting a MassID](/docs/integrations/guides/submitting-a-mass-id). For the
complete rules catalog, see [BOLD Carbon (CH₄) Rules](/docs/methodologies/ams-iii-f/bold-carbon/application/application-rules).
## Prerequisites [#prerequisites]
* Completed the [Quick Start](/docs/integrations/getting-started/quick-start) flow.
* Familiar with [Core Concepts](/docs/integrations/getting-started/core-concepts) (document model, event ordering, idempotency).
* [Accreditation](/docs/protocol/network-integrators) documents on file for the [Network Integrator](/docs/protocol/network-integrators), the [Processor](/docs/protocol/supply-chain) and the [Recycler](/docs/protocol/supply-chain#the-role-of-the-recycler) — the Processor's and Recycler's validity is checked when the methodology runs. Rule 4 checks these three only: a [Hauler](/docs/protocol/supply-chain) needs no accreditation, and a [Waste Generator's](/docs/protocol/supply-chain) is not required by this rule.
* Recycler accreditation includes the **exceeding emission coefficient** required for emissions calculation.
## Shared rules with BOLD Recycling [#shared-rules-with-bold-recycling]
BOLD Carbon rules 1–19 are identical to BOLD Recycling. The document creation, event sequence, and field
requirements for these rules are the same. See the
[BOLD Recycling Integration Guide](/docs/methodologies/bold-recycling/framework/application/integration)
for the full event-by-event breakdown covering:
* Document creation (category, type, subtype, measurement unit)
* ACTOR events for all participants
* Pick-up, Transport Manifest, Weighing, Drop-off, Sorting, Recycled, and Recycling Manifest events
* Geolocation, uniqueness, biological treatment timeframe, and Ibama code validations (see [Supported waste codes](/docs/methodologies/ams-iii-f/bold-carbon#supported-waste-codes) for accepted values)
Everything in that guide applies here. This page covers only the **Carbon-exclusive addition**.
## Event and rule mapping [#event-and-rule-mapping]
## Carbon-exclusive rules [#carbon-exclusive-rules]
### Rule 20 — Emission Reductions [#rule-20--emission-reductions]
Calculates CO₂-equivalent emission reductions based on the UNFCCC AMS-III.F methodology. The calculation
uses:
| Input | Source |
| ------------------------------ | --------------------------------------------- |
| Exceeding emission coefficient | Recycler accreditation document. |
| Baselines per waste subtype | Recycler accreditation document. |
| Greenhouse Gas Type (GHG) | MassID metadata attribute. |
| Waste subtype | MassID document `subtype` field. |
| MassID value | MassID document `value` field (weight in kg). |
**What your integration must ensure:**
* The recycler's accreditation document includes a valid exceeding emission coefficient and baselines for each waste subtype.
* The MassID document's subtype and value are correctly set.
* The GHG metadata attribute is present and valid.
The rule outputs the calculated emission reductions in CO₂e.
The framework-level `methodology-distance-limit` rule validates the distance between Pick-up and
Drop-off locations. Distances exceeding 200 km are flagged for review. This is a framework check,
not an application rule — it does not affect the rule count.
## Post-validation [#post-validation]
When all 20 rules pass:
1. A [GasID certificate](/docs/protocol/certificates#gasid) is issued, linked to the MassID (instead of a RecycledID).
2. Its [C-CARB.CH4](/docs/protocol/credits#tokenized-carbon-credits-tcc) (Tokenized Carbon Credits ([TCC](/docs/protocol/credits#tokenized-carbon-credits-tcc))) credit tokens are minted in the same transaction as the certificate.
3. [Rewards](/docs/protocol/rewards-distribution) for [supply chain](/docs/protocol/supply-chain) participants are calculated and committed on-chain later, when a credit from that certificate is sold.
## Differences from BOLD Recycling [#differences-from-bold-recycling]
| Aspect | BOLD Recycling | BOLD Carbon (CH₄) |
| --------------------- | ------------------------------------------------------ | -------------------------------------------------------- |
| Rules count | 19 MassID rules | 20 MassID rules (19 shared + 1 exclusive) |
| Certificate type | [RecycledID](/docs/protocol/certificates#recycledid) | [GasID](/docs/protocol/certificates#gasid) |
| Credit token | `C-BIOW` (TRC) | `C-CARB.CH4` (TCC) |
| Emissions calculation | Not applicable | CO₂e reductions via UNFCCC AMS-III.F (rule 20) |
| Geographic boundary | Pick-up → Drop-off distance flagged at framework level | Same framework-level check (200 km threshold) |
| Accreditation data | Standard accreditation fields | Must include exceeding emission coefficient for recycler |
## Common issues [#common-issues]
All [BOLD Recycling common issues](/docs/methodologies/bold-recycling/framework/application/integration#common-issues) apply, plus:
* **Missing emission coefficient** — The recycler's accreditation must include the exceeding emission coefficient. Without it, rule 20 cannot calculate emission reductions.
* **Distance flag** — The Pick-up and Drop-off addresses must be geographically reasonable. Distances exceeding 200 km are flagged for review. Ensure GPS coordinates are accurate on both events.
* **Missing baselines** — The recycler's accreditation must include baselines for each waste subtype used in the emissions calculation.
[View rules catalog](/docs/methodologies/ams-iii-f/bold-carbon/application/application-rules) · [View app reference](/docs/methodologies/ams-iii-f/bold-carbon/application) · [BOLD Recycling integration guide](/docs/methodologies/bold-recycling/framework/application/integration)
# BOLD Recycling Credit Rules Reference
## Overview [#overview]
These are the **application rules** — the executable validation logic that runs against each [MassID](/docs/protocol/mass-ids) document. Each rule evaluates a document and returns **PASSED**, **FAILED**, or **REVIEW\_REQUIRED** with an explanation.
Each application rule satisfies one or more [framework rules](/docs/methodologies/bold-recycling/framework#framework-rules) from the [BOLD Recycling](/docs/methodologies/bold-recycling) specification. See the "Implements framework rules" section in each rule's details for the mapping.
The BOLD Recycling framework defines a set of open-source rules to verify that organic waste has been properly sorted, collected, transported, and composted.
Rules execute in a defined order against MassID documents. Passing them all is what triggers issuance of the [RecycledID certificate](/docs/protocol/certificates#recycledid).
All rules are licensed under LGPL-3.0: [github.com/carrot-foundation/methodology-rules](https://github.com/carrot-foundation/methodology-rules)
[View on Carrot Registry](https://registry.carrot.eco/document/31f1ff32-fdc5-469a-9d30-caf0be89b50a)
## MassID rules [#massid-rules]
These rules validate individual [MassID](/docs/protocol/mass-ids) documents. They execute in the order shown.
See the [Rewards Distribution Policy](/docs/standard/policies/rewards-distribution) for the full percentage breakdown by actor type and waste category.
[Learn about BOLD Recycling](/docs/methodologies/bold-recycling) · [Learn about BOLD Carbon (CH₄) rules](/docs/methodologies/ams-iii-f/bold-carbon/application/application-rules)
# BOLD Recycling — MassID Event Reference
## How to read this page [#how-to-read-this-page]
Each event below shows the canonical JSON payload [integrators](/docs/protocol/network-integrators) send to the Documents API.
The `isPublic` flags inside each example are Carrot's recommended visibility — see
[Privacy & Masking](/docs/integrations/guides/privacy-and-masking) for the model.
Each payload references its participant and address by `participantId` and `addressId`. Resolve each one
first — retrieve it by key or create it — via the [Participants API](/docs/integrations/api/participants);
sending full `participant` and `address` objects inline is also supported and find-or-creates the record.
Send exactly one form of each pair — both, or neither, fails with `400 VALIDATION_ERROR`. The rule is the same on the single-event and batch endpoints.
> Per-event attribute dictionaries (definitions, types, sensitive flags, conditional rules)
> are the planned next addition to this page.
## Create MassID document [#create-massid-document]
The initial `POST /documents` call that creates a MassID. Not an event on the document's
timeline — included here as the starting point for integrator flows. The
[Waste Generator](/docs/protocol/supply-chain) is the creator; events are added to this
document afterward.
## ACTOR — Waste Generator [#actor--waste-generator]
## ACTOR — Recycler [#actor--recycler]
## ACTOR — Processor [#actor--processor]
## ACTOR — Hauler [#actor--hauler]
## ACTOR — Integrator [#actor--integrator]
## Pick-up [#pick-up]
## Transport Manifest [#transport-manifest]
## Weighing [#weighing]
## Drop-off [#drop-off]
## Sorting [#sorting]
## Recycled [#recycled]
## Recycling Manifest [#recycling-manifest]
# BOLD Recycling Credit Application Overview
## Application summary [#application-summary]
| Property | Value |
| --------------- | -------------------------------------------------------------------------------------------------------- |
| **Methodology** | [BOLD Recycling](/docs/methodologies/bold-recycling) |
| **Version** | 1.0.0 |
| **License** | LGPL-3.0 |
| **Repository** | [github.com/carrot-foundation/methodology-rules](https://github.com/carrot-foundation/methodology-rules) |
## Architecture [#architecture]
The [BOLD Recycling](/docs/methodologies/bold-recycling) [MvA](/docs/standard/concepts/mva) is implemented in the open-source methodology-rules monorepo. It follows the two-layer architecture shared by all BOLD methodologies:
* **Shared rule libraries** — Common verification logic reused across all BOLD methodologies. Located in the shared rule processors directory.
* **BOLD Recycling application wrappers** — Thin deployment layers that wrap shared libraries as serverless functions, located in the BOLD Recycling application directory.
Each rule is an independent serverless function that evaluates [MassID](/docs/protocol/mass-ids) documents and returns PASSED, FAILED, or REVIEW\_REQUIRED with an explanation.
For the complete rules catalog with execution order, see [Application Rules](/docs/methodologies/bold-recycling/framework/application/application-rules).
## Source code [#source-code]
The repository is organized as follows:
* **Shared rule libraries** — [libs/methodologies/bold/rule-processors/](https://github.com/carrot-foundation/methodology-rules/tree/main/libs/methodologies/bold/rule-processors/) contains the shared rule implementations used by all BOLD methodologies.
* **BOLD Recycling deployments** — [apps/methodologies/bold-recycling/rule-processors/](https://github.com/carrot-foundation/methodology-rules/tree/main/apps/methodologies/bold-recycling/rule-processors/) contains the deployment wrappers for this methodology.
See the repository README for navigation guidance and contribution instructions.
[Learn about BOLD Recycling](/docs/methodologies/bold-recycling) · [Learn about the framework](/docs/methodologies/bold-recycling/framework) · [View rules catalog](/docs/methodologies/bold-recycling/framework/application/application-rules) · [Integration guide](/docs/methodologies/bold-recycling/framework/application/integration)
# BOLD Recycling Credit Integration Guide
This guide explains how to submit [MassID](/docs/protocol/mass-ids) documents that satisfy
[BOLD Recycling](/docs/methodologies/bold-recycling) rules. It covers the expected event
sequence, required fields per event, and common validation issues.
For the base API flow, see [Submitting a MassID](/docs/integrations/guides/submitting-a-mass-id). For the
complete rules catalog, see [BOLD Recycling Rules](/docs/methodologies/bold-recycling/framework/application/application-rules).
## Prerequisites [#prerequisites]
* Completed the [Quick Start](/docs/integrations/getting-started/quick-start) flow.
* Familiar with [Core Concepts](/docs/integrations/getting-started/core-concepts) (document model, event ordering, idempotency).
* [Accreditation](/docs/protocol/network-integrators) documents on file for the [Network Integrator](/docs/protocol/network-integrators), the [Processor](/docs/protocol/supply-chain) and the [Recycler](/docs/protocol/supply-chain#the-role-of-the-recycler). Rule 4 checks these three only — a [Hauler](/docs/protocol/supply-chain) needs no accreditation, and a [Waste Generator's](/docs/protocol/supply-chain) is not required by this rule.
## Document creation [#document-creation]
Create the document with these required qualifications (validated by rule 5 — MassID Qualifications):
| Field | Required value |
| ------------- | -------------------------------- |
| `category` | `MassID` |
| `type` | `Organic` |
| `measureUnit` | `kg` |
| `value` | Greater than 0 |
| `subtype` | A valid organic waste subtype |
| `isPublic` | Per your visibility requirements |
Reference: [Documents API](/docs/integrations/api/documents).
## Expected event sequence [#expected-event-sequence]
Submit events in chronological order via `POST /documents/{documentId}/events`. See
[Event Specification](/docs/integrations/reference/event-specification) for common event fields.
The following sequence reflects the order validated by the BOLD Recycling rules:
### Required participant roles [#required-participant-roles]
| Role | ACTOR label | Purpose |
| --------------- | ----------------- | -------------------------------------------------------------- |
| Waste Generator | `Waste Generator` | Source of the waste material |
| Hauler | `Hauler` | Transports waste from origin to facility |
| Recycler | `Recycler` | Operates the recycling or composting facility |
| Processor | `Processor` | Processes sorted material (may be the same entity as recycler) |
### 1. ACTOR events — participant registration [#1-actor-events--participant-registration]
Register each participant with an `ACTOR` event. Rule 4 — Participant Accreditations & Verifications
— checks accreditation documents for the Integrator, Processor and Recycler only, and the Processor's
and Recycler's accreditation must be valid on the evaluation date. Registering a Hauler or a Waste
Generator does not require an accreditation document.
| Participant | Required? | Conditions |
| --------------- | ----------- | ----------------------------------------------------------------------------- |
| Integrator | Yes | Must have an accreditation document. |
| Waste Generator | Conditional | Required if waste origin is identified (rule 8). Omit if origin unidentified. |
| Hauler | Conditional | Required for most vehicle types (rule 9). Optional for cart or sludge pipes. |
| Processor | Yes | Exactly one processor required (rule 13). |
| Recycler | Yes | Exactly one recycler required (rule 14). |
Every ACTOR event carries the participant and address identifiers. It carries no accreditation data: accreditation is not submitted through the API at all — it lives in the accreditation layer, and the verification pipeline reads it from there. Rule 7 — Geolocation Precision — compares an event's address against the accredited address of the participants that have an accreditation on file.
The payload shape is identical across actors — only the role identifier differs.
### 2. Pick-up event — waste collection [#2-pick-up-event--waste-collection]
The Pick-up event captures vehicle and driver information:
| Field | Required? | Validated by |
| ----------------------- | ----------- | ------------------------------------- |
| Vehicle type | Yes | Rule 10 — Vehicle Identification |
| License plate / ID | Conditional | By vehicle type (rule 10) |
| Driver identifier | Conditional | By vehicle type (rule 11) |
| Exemption justification | Conditional | When driver ID not required (rule 11) |
### 3. Transport Manifest event — shipping documentation [#3-transport-manifest-event--shipping-documentation]
Must include (rule 12 — Transport Manifest):
| Field | Required? | Notes |
| --------------- | --------- | ------------------------------------------------------------------ |
| Document number | Yes | |
| Document type | Yes | Must be `MTR` for recyclers in Brazil. |
| Issue date | Yes | |
| Attachments | Yes | Upload via [File Uploads](/docs/integrations/guides/file-uploads). |
### 4. Weighing event(s) — mass measurement [#4-weighing-events--mass-measurement]
Record weight measurements (rule 15 — Weighing):
| Field | Required? | Notes |
| --------------------- | ----------- | ---------------------------------------------------------------------- |
| Event value | Yes | Net weight in kg, must be greater than 0. |
| Description | Yes | Weighing event description. |
| Gross weight | Yes | Must be greater than 0, in kg. |
| Tare | Yes | Container empty weight in kg (exemptions may apply per accreditation). |
| Container type | Yes | One of: Bag, Bin, Drum, Pail, Street Bin, Waste Box, or Truck. |
| Container quantity | Conditional | Required when container type is not Truck. |
| Container capacity | Conditional | Required for multi-container weighing. |
| Capture method | Yes | One of: Digital, Photo (Scale+Cargo), Manual, or Transport Manifest. |
| Scale type | Yes | Must match an approved scale type. |
| Scale ticket | Conditional | When required by recycler accreditation. |
| Vehicle license plate | Conditional | Required when container type is Truck. |
Supports both single-step and two-step weighing processes.
### 5. Drop-off event — delivery to recycling facility [#5-drop-off-event--delivery-to-recycling-facility]
Must include (rule 16 — Drop-off At Recycling Facility):
| Field | Required? | Notes |
| ------------------ | --------- | --------------------------------------------- |
| Receiving operator | Yes | Operator identifier at the facility. |
| Address | Yes | Must match the recycler's accredited address. |
### 6. Sorting event — mass sorting [#6-sorting-event--mass-sorting]
Must include (rule 17 — Mass Sorting):
| Field | Required? | Notes |
| --------------- | --------- | ----------------------------------------------- |
| Description | Yes | Sorting event description. |
| Gross weight | Yes | Total weight before deductions. |
| Deducted weight | Yes | Weight of contaminants/non-target material. |
| Sorting factor | Yes | Calculated from gross and deducted weight. |
| Event value | Yes | Must be correctly calculated from sorting data. |
### 7. Recycled event — biological treatment completion [#7-recycled-event--biological-treatment-completion]
The Recycled event marks the end of the biological treatment cycle. The timestamp is validated against the Drop-off
event (rule 18 — Composting Cycle Timeframe):
* Time between Drop-off and Recycled must be **60–180 days**.
### 8. Recycling Manifest event — recycling documentation [#8-recycling-manifest-event--recycling-documentation]
Must include (rule 19 — Recycling Manifest):
| Field | Required? | Notes |
| ----------------------- | ----------- | ------------------------------------------------- |
| Document number | Yes | |
| Document type | Yes | Must be `CDF` for recyclers in Brazil. |
| Issue date | Yes | |
| Attachments | Conditional | Required unless exemption justification provided. |
| Exemption justification | Conditional | When attachments are not available. |
## Event and rule mapping [#event-and-rule-mapping]
## Additional validations [#additional-validations]
| Rule | What it checks |
| ---- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1 | No duplicate MassID exists with the same drop-off + pick-up + recycler + waste generator + license plate combination. |
| 2 | MassID is not already linked to a [RecycledID](/docs/protocol/certificates#recycledid) or credit order. |
| 3 | Recycled event occurred on or after January 1st of the previous year. |
| 6 | Local waste classification matches a valid Ibama code (recyclers in Brazil). |
| 7 | Participant event addresses are validated against accredited addresses using tiered distance thresholds (≤2 km: GPS check, 2–30 km: address similarity review, >30 km: fail). |
## Post-validation [#post-validation]
When all 19 rules pass:
1. A [RecycledID certificate](/docs/protocol/certificates#recycledid) is issued, linked to the MassID.
2. Its [C-BIOW](/docs/protocol/credits#tokenized-recycling-credits-trc) credit tokens (Tokenized Recycling Credits) are minted in the same transaction as the certificate.
3. [Rewards](/docs/protocol/rewards-distribution) for [supply chain](/docs/protocol/supply-chain) participants are calculated and committed on-chain later, when a credit from that certificate is sold.
## Common issues [#common-issues]
* **Geolocation mismatch** — Participant event addresses are validated against accredited addresses using tiered distance thresholds. Verify GPS accuracy.
* **Biological treatment timeframe** — The Drop-off to Recycled window must be 60–180 days. Documents outside this range fail rule 18.
* **Missing accreditations** — The Integrator, Processor and Recycler must have accreditation documents on file, and the Processor's and Recycler's must be valid and non-expired at the time the methodology runs, not at the time the event was submitted. Rule 4 does not check Hauler or Waste Generator accreditation.
* **Duplicate MassIDs** — The uniqueness check (rule 1) prevents duplicate submissions. Use `deduplicationId` for retries, not re-submissions.
* **Ibama codes** — For recyclers in Brazil, local waste classification must match a valid Ibama code. Validate before submission.
[View rules catalog](/docs/methodologies/bold-recycling/framework/application/application-rules) · [View app reference](/docs/methodologies/bold-recycling/framework/application) · [Base integration flow](/docs/integrations/guides/submitting-a-mass-id)
---
# Locale: pt-BR
# Perguntas Frequentes
Use esta página para respostas rápidas e navegação. Para detalhes de implementação, continue em
[Integrações](/docs/integrations), [Referência da API](/docs/integrations/api) ou [Metodologias](/docs/methodologies).
## Geral [#geral]
### O que é a Rede Carrot? [#o-que-é-a-rede-carrot]
A [Rede Carrot](/docs/network) é infraestrutura pública digital para a economia circular de baixo carbono e eficiente no uso de recursos. Ela abrange um [standard](/docs/standard), um [registry](/docs/registry) público de créditos, infraestrutura de Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)) para verificação independente por terceiros de créditos de carbono e outras categorias, o [Protocolo da Economia Circular](/docs/protocol) e uma camada de [governança](/docs/network/governance) para tomada de decisão transparente e rastreável e compartilhamento dos recursos da rede. Saiba mais sobre por que a Carrot é construída como [infraestrutura pública digital](/docs/network/digital-public-infrastructure).
### Como a reciclagem é verificada na Rede Carrot? [#como-a-reciclagem-é-verificada-na-rede-carrot]
Cada lote de resíduos é rastreado como um [MassID](/docs/protocol/mass-ids) — um gêmeo digital que registra o tipo de material, sua origem e quem o manuseou. Em cada ponto de transferência, validadores confirmam o material, criando uma cadeia de custódia ininterrupta desde a geração do resíduo até a reciclagem certificada. Este é o processo de dMRV.
### Quem pode participar? [#quem-pode-participar]
Qualquer pessoa envolvida na cadeia de reciclagem: [Geradores de Resíduos, Responsáveis por Pontos de Coleta, Transportadores, Processadores e Recicladores](/docs/protocol/supply-chain), além de [Integradores](/docs/protocol/network-integrators). Cada participante recebe [recompensas](/docs/protocol/rewards-distribution) por sua contribuição verificada.
## Governança da Rede [#governança-da-rede]
### A Carrot é uma empresa, fundação ou rede? [#a-carrot-é-uma-empresa-fundação-ou-rede]
A rede é administrada pela Carrot Fndn, uma fundação suíça. A Fundação fornece administração institucional para o standard, o registro, a conformidade das metodologias e a continuidade operacional da rede.
### Quem governa a rede hoje? [#quem-governa-a-rede-hoje]
O Conselho da Fundação governa a rede hoje, com apoio de conselheiros e contribuidores de domínio. Espera-se que a participação se expanda ao longo do tempo por meio das fases de engajamento, consultiva e deliberativa.
### Para onde vão os recursos das compras de créditos? [#para-onde-vão-os-recursos-das-compras-de-créditos]
Os recursos das compras de créditos são distribuídos de acordo com a [Política de Distribuição de Recompensas](/docs/standard/policies/rewards-distribution) publicada. A política define categorias de participantes e percentuais de distribuição para cada tipo de resíduo suportado.
### O que a Fundação administra? [#o-que-a-fundação-administra]
A Fundação administra a estrutura de governança da rede, incluindo o standard, o registro, a conformidade das metodologias, a direção do protocolo e a continuidade operacional.
### Como a Carrot é diferente de uma plataforma privada de mensuração, relato e verificação (MRV)? [#como-a-carrot-é-diferente-de-uma-plataforma-privada-de-mensuração-relato-e-verificação-mrv]
Uma plataforma privada desse tipo geralmente registra e reporta dados dentro do ambiente de produto de uma única empresa. A rede é projetada como infraestrutura de mercado compartilhada: lógica de metodologia, rastreabilidade de créditos, registros públicos e distribuição de recompensas são organizados por meio de um modelo liderado por uma fundação.
## Créditos [#créditos]
### O que são `C-BIOW` e `C-CARB.CH4`? [#o-que-são-c-biow-e-c-carbch4]
Um [crédito `C-BIOW`](/docs/protocol/credits#tokenized-recycling-credits-trc) é um Tokenized Recycling Credit (TRC) que representa 1 tonelada métrica de resíduo orgânico reciclado certificado. Um [crédito `C-CARB.CH4`](/docs/protocol/credits#tokenized-carbon-credits-tcc) é um Tokenized Carbon Credit (TCC) que representa 1 tonelada métrica de reduções de emissões de CO₂ equivalente por meio do desvio de resíduos. Ambos são créditos digitais fungíveis respaldados por [certificados](/docs/protocol/certificates) verificados; TRC e TCC são as categorias mais amplas, enquanto `C-BIOW` e `C-CARB.CH4` são os símbolos específicos no registry.
### Como os créditos são adquiridos? [#como-os-créditos-são-adquiridos]
Os créditos são adquiridos apenas por meio de interfaces Carrot — compradores não compram diretamente pela infraestrutura subjacente do registry. Indivíduos podem adquirir impacto ambiental pela [Loja Carrot](https://store.carrot.eco) (store.carrot.eco), que oferece pacotes baseados em intenção que resultam em créditos aposentados. Organizações utilizam interfaces fornecidas pela Carrot que aceitam Pix e cartão de crédito/débito; a liquidação no registry público sempre ocorre em USDC, uma moeda digital rastreável, e a Carrot faz a conversão. Na implementação atual, compra e [aposentadoria](/docs/protocol/credit-retirement) acontecem em uma única transação no registry: todo crédito comprado é aposentado no momento da compra, então o comprador recebe um Credit Purchase Receipt e um Credit Retirement Receipt como prova permanente de ação ambiental, e não um saldo de créditos transferível. Os dois recibos são verificáveis pelo [Carrot Registry](/docs/protocol/registry) (registry.carrot.eco) ou — de forma independente dos sistemas da Carrot — na blockchain pública subjacente. Veja [Compra de Créditos](/docs/protocol/credit-purchase) para detalhes.
### Os créditos podem ser usados para conformidade com EPR? [#os-créditos-podem-ser-usados-para-conformidade-com-epr]
Sim. Como os MassIDs registram a origem geográfica dos resíduos, os créditos podem ser rastreados até municípios específicos. Isso os torna adequados para demonstrar conformidade com mandatos locais de Responsabilidade Estendida do Produtor (EPR).
{/* Preços devem corresponder a src/data/pricing.ts (fonte canônica). Atualize tanto pricing.ts quanto os valores aqui quando os preços mudarem. */}
## Comprando Créditos [#comprando-créditos]
### Qual o volume mínimo para comprar créditos? [#qual-o-volume-mínimo-para-comprar-créditos]
Não há tonelagem nem compromisso mínimo de volume. Na [Loja Carrot](https://store.carrot.eco) você escolhe um pacote de impacto ou uma coleção e contribui com qualquer valor igual ou superior ao preço dele — o pacote de entrada define a menor compra — e os créditos aposentados em seu nome acompanham o valor da sua contribuição. Para acordos de volume enterprise ou compromissos mínimos anuais (AMC), entre em contato com nossa equipe comercial.
### Como `C-CARB.CH4` e `C-BIOW` são precificados? [#como-c-carbch4-e-c-biow-são-precificados]
Na venda conjunta, cada `C-CARB.CH4` tem valor de US$ 120,00 e a parcela de valor do `C-BIOW` acrescenta US$ 33,53 por `C-CARB.CH4` vendido, totalizando o valor de referência combinado de US$ 153,53.
O valor de US$ 33,53 não é multiplicado pela quantidade física de `C-BIOW`; o coeficiente de emissão determina o valor efetivo por `C-BIOW`. Consulte a [Calculadora de Créditos](/docs/standard/guides/credit-calculator) para ver o cálculo aberto e a tabela comparativa.
### Quais formas de pagamento são aceitas? [#quais-formas-de-pagamento-são-aceitas]
Pix e cartão de crédito/débito. A liquidação no registry público sempre ocorre em USDC — a Carrot faz a conversão, então o comprador não precisa manter nem enviar stablecoin.
### Preciso ter uma carteira blockchain para comprar? [#preciso-ter-uma-carteira-blockchain-para-comprar]
Você não precisa configurar ou gerenciar uma carteira por conta própria. O [MyCarrot](https://my.carrot.eco) é um portal com interface intuitiva — a plataforma executa as etapas técnicas para você, qualquer que seja o meio de pagamento escolhido. Pelo MyCarrot você acessa seu painel de impacto, histórico de compras com detalhes de certificados e trilhas de auditoria — tudo em um só lugar.
### Como integro os certificados de aposentadoria no meu relatório ESG? [#como-integro-os-certificados-de-aposentadoria-no-meu-relatório-esg]
Cada [aposentadoria de crédito](/docs/protocol/credit-retirement) gera um certificado permanente e verificável de forma independente, com trilha de auditoria completa que pode apoiar relatórios ESG. Veja [Aposentadoria de Créditos](/docs/protocol/credit-retirement) para mais detalhes.
## Integração [#integração]
### Como os Integradores se conectam? [#como-os-integradores-se-conectam]
Os Integradores são aplicações de software de terceiros que se conectam à Rede Carrot por meio da [Carrot API](/docs/integrations/api) após concluir o processo de [homologação](/docs/protocol/network-integrators). Eles enviam dados da cadeia de suprimentos em nome de seus clientes e recebem uma parte das recompensas de compra de créditos. Veja o [guia de integração](/docs/integrations/getting-started/quick-start) para começar.
### Quais dados a API aceita? [#quais-dados-a-api-aceita]
Os Integradores enviam dados de eventos da cadeia de suprimentos que cobrem coletas, entregas, validações de materiais e outros eventos da cadeia. Esses dados criam e atualizam MassIDs que rastreiam resíduos pelo sistema. Veja a [especificação de eventos](/docs/integrations/reference/event-specification) para detalhes.
### Existe prazo para enviar os dados das massas? [#existe-prazo-para-enviar-os-dados-das-massas]
Sim, e ele depende de quando o material foi reciclado: o [framework de metodologia](/docs/standard/concepts/mvf) só aceita uma massa cujo evento Recycled tenha ocorrido em ou após 1º de janeiro do ano civil anterior, em UTC, então o último ciclo que pode analisar uma massa é o do ano seguinte ao da reciclagem, e os dados precisam chegar à rede até o fim de novembro desse ano. Os dados podem ser enviados conforme a operação acontece, e devem ser. O prazo exato, o que acontece entre o corte e o fechamento do ciclo e o tratamento dos envios atrasados estão descritos em [Janela de envio](/docs/protocol/mass-ids#janela-de-envio).
## Metodologias [#metodologias]
### O que é BOLD? [#o-que-é-bold]
BOLD (Breakthrough in Organics Landfill Diversion) é a família de [metodologias](/docs/methodologies) na Rede Carrot para verificação de desvio de resíduos orgânicos. [BOLD Recycling](/docs/methodologies/bold-recycling) verifica o desvio de resíduos orgânicos para compostagem aeróbica; [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) verifica reduções de metano alcançadas quando a compostagem impede a decomposição anaeróbica em aterros.
### Qualquer pessoa pode criar uma metodologia? [#qualquer-pessoa-pode-criar-uma-metodologia]
O ecossistema aceita propostas de metodologias, frameworks de verificação de metodologia e aplicações de dMRV de terceiros para revisão e aprovação sob o [Carrot dMRV Standard](/docs/standard).
# Glossário
{/* This file is generated by pnpm glossary:sync from .docs/glossary/terms/*.md. Do not edit directly. */}
Termos-chave usados na documentação da Rede Carrot.
## A [#a]
**Adicionalidade** — Uma atividade de projeto que reduz as emissões líquidas de GEE abaixo do nível que ocorreria sem o projeto (o cenário de referência).
**Advance Market Commitment (AMC)** — Um compromisso, feito antes de a oferta existir, de comprar um volume definido de um resultado verificado a um preço definido — transformando demanda futura na certeza que permite que fornecedores e seus financiadores invistam. A Rede Carrot fornece a verificação, o registro único e a liquidação que esses compromissos exigem; ela não opera compromissos de mercado nem atua como compradora. Veja o [White Paper](/docs/network/white-paper) e o [Processo de RFP](/docs/standard/policies/rfp-process).
**AMS-III.F** — Uma metodologia do Mecanismo de Desenvolvimento Limpo da UNFCCC para reduções de emissões de metano pela compostagem. A metodologia externa e validada por trás do framework [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon).
**Anexo Geográfico** — Um documento complementar que fornece a especificação local para cada elemento territorial em um [Methodology Verification Framework (MvF)](/docs/standard/concepts/mvf). Mapeia regulações locais, códigos de classificação de materiais, documentação exigida, fatores de emissão e critérios de elegibilidade para os requisitos funcionais declarados no framework. O MvF mais um Anexo Geográfico formam uma especificação completa e implementável para um determinado mercado. Veja [MvF — Adaptabilidade geográfica](/docs/standard/concepts/mvf#geographic-adaptability).
**Aposentadoria de crédito** — A remoção permanente de créditos de circulação. Quando um comprador aposenta créditos, eles são consumidos de forma irreversível e um `CreditRetirementReceipt` é emitido como prova permanente e auditável. Créditos aposentados não podem ser revendidos ou reutilizados. Veja [Compra de Créditos](/docs/protocol/credit-purchase).
**Atributo** — Veja [Metadados](#metadata). Os termos *atributo* e *metadados* são usados de forma intercambiável na documentação Carrot para referir-se aos pares chave-valor anexados a eventos.
**Auditor** — Um negócio, organização ou consultor independente e terceirizado que audita e credencia participantes e instalações para a Rede Carrot. Veja [Verificação de Terceiros](/docs/protocol/third-party-verification).
## B [#b]
**Bens públicos digitais** — Software open source, padrões abertos, dados abertos e conteúdo aberto que podem ser reutilizados e adaptados livremente — o termo usado pela ONU e pela Digital Public Goods Alliance. A infraestrutura é o trilho; os bens públicos digitais são as partes abertas que a compõem. Os frameworks de metodologia da Rede Carrot, seu registry público de créditos e seu código de verificação open source são bens públicos digitais. Veja [Infraestrutura Pública Digital](/docs/network/digital-public-infrastructure).
**Bioresíduo** — Resíduo orgânico — restos de alimentos, resíduos agrícolas e outros materiais biodegradáveis — desviado de aterros para reciclagem ou [tratamento biológico](#biological-treatment). O bioresíduo reciclado é a matéria-prima dos créditos de reciclagem da Rede Carrot (ver [C-BIOW](#c-biow)); o bioresíduo tratado biologicamente gera [créditos de carbono](#carbon-credits) a partir da redução das emissões de metano. Em inglês, escreve-se sempre como uma única palavra: *biowaste*.
**BOLD (Breakthrough in Organics Landfill Diversion)** — Linha de produtos da Carrot para créditos de desvio de resíduos orgânicos de aterros, abrangendo as duas famílias: a unidade de carbono BOLD Carbon (CH4) Credit (derivada de metano — por exemplo, compostagem em pequena escala) + a unidade de reciclagem BOLD Recycling Credit. Símbolo da borboleta = transformação, com referência aos ciclos biológico + técnico da economia circular. Separar resíduos orgânicos na origem destrava a economia circular de baixo carbono.
## C [#c]
**C-BIOW** — O símbolo de crédito do [Tokenized Recycling Credit (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc) emitido pela metodologia [BOLD Recycling](/docs/methodologies/bold-recycling). 1 crédito = 1 tonelada métrica de bioresíduos reciclados certificados. Outras metodologias de reciclagem podem emitir TRCs com símbolos diferentes.
**C-CARB.CH4** — O símbolo de crédito do [Tokenized Carbon Credit (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc) emitido pela metodologia [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) (reduções de metano por compostagem). 1 crédito = 1 tonelada métrica de reduções de emissões de CO₂-equivalente. Outras metodologias de carbono podem emitir TCCs com símbolos diferentes.
**CaA** — Carrot Agentic Advisor. Uma camada de IA que identifica oportunidades de melhoria em metodologias, qualidade de dados e processos em todo o ecossistema. Veja [Ecossistema de Metodologias](/docs/standard/concepts/ecosystem#platform-intelligence-layers).
**Cadeia de custódia** — O registro completo de cada participante que manuseou um lote de material residual, da origem à reciclagem certificada. Registrado em cada [MassID](/docs/protocol/mass-ids).
**Cadeia de suprimentos** — A rede de participantes e transferências que move materiais desde a geração de resíduos até coleta, transporte, processamento e reciclagem certificada, com cada transferência registrada para rastreabilidade e verificação. Veja [cadeia de suprimentos](/docs/protocol/supply-chain).
**CaE** — Carrot Analytic Engine. A camada de avaliação da pilha de verificação — uma camada de aprendizado de máquina projetada para analisar dados de dMRV e resultados de verificação, detectando anomalias, inconsistências e padrões suspeitos. Ela aprimora a qualidade da auditoria, mas não certifica créditos. Veja [Ecossistema de Metodologias](/docs/standard/concepts/ecosystem#platform-intelligence-layers).
**Carrot dMRV Standard** — Os cinco princípios fundamentais que toda metodologia na Rede Carrot deve seguir: integridade & rastreabilidade, adicionalidade & verificabilidade, padronização & comparabilidade, interoperabilidade & automação, e transparência & auditabilidade. Veja [Carrot dMRV Standard](/docs/standard).
**Carrot Foundation** — Uma fundação na Suíça que constrói a Rede Carrot. Missão: acelerar a transição para uma economia circular eficiente em recursos, de baixo carbono e inclusiva.
**Carrot Registry** — A [interface pública](/docs/protocol/registry) da plataforma de verificação da Carrot em [registry.carrot.eco](https://registry.carrot.eco). Fornece uma visão transparente e amigável de dados ambientais e trilhas de auditoria — tanto dados do registry (MassIDs, certificados, créditos, registros de aposentadoria) quanto dados da plataforma (definições de metodologia, execução de regras, homologações). Os dados do registry também podem ser verificados por qualquer pessoa por meio de qualquer [explorador de blockchain](#blockchain-block-explorer), sem depender da infraestrutura da Carrot. A função de registry da Rede Carrot é descrita como "registry público de créditos" (em minúsculas); "Carrot Registry" é a própria superfície. A consulta e verificação de registros dentro dela é a seção Explorer.
**Carrot Store** — Uma experiência de consumo em [store.carrot.eco](https://store.carrot.eco) para a compra de impacto ambiental. Oferece um pequeno conjunto de pacotes de contribuição baseados em intenção que resultam em créditos aposentados — uma forma simples de indivíduos agirem sem escolher metodologias ou tonelagem.
**Categoria** — O nível de classificação mais amplo para um documento na [Carrot API](/docs/integrations/api). Para integrações de cadeia de suprimentos, a categoria é tipicamente `MassID`. Veja [Classificação de Resíduos](/docs/integrations/reference/waste-classification).
**CDM** — Clean Development Mechanism (Mecanismo de Desenvolvimento Limpo). Um framework da [UNFCCC](/docs/methodologies/ams-iii-f/bold-carbon#base-cientifica) que permite projetos de redução de emissões em países em desenvolvimento obterem créditos certificados de redução de emissões. O BOLD Carbon utiliza as categorias de resíduos do CDM Tool 04 v08.1 para classificar tipos de resíduos para atribuição de fatores de emissão. Veja [Códigos de resíduos suportados](/docs/methodologies/ams-iii-f/bold-carbon#códigos-de-resíduos-suportados).
**Certificado** — Um registro digital permanente e intransferível que representa um único MassID aprovado na verificação de metodologia. Dois tipos: [GasID](/docs/protocol/certificates#gasid) (reduções de emissões) e [RecycledID](/docs/protocol/certificates#recycledid) (material reciclado).
**CO₂e** — Dióxido de carbono equivalente. Uma unidade padrão que converte todos os gases de efeito estufa em equivalentes de dióxido de carbono usando o Potencial de Aquecimento Global (GWP). Medido em toneladas métricas (t-CO₂e).
**Cold Start** — Coleção de créditos que representa o desbloqueio de efeitos de rede em uma localização geográfica específica. Nomeada a partir do livro de Andrew Chen sobre efeitos de rede.
**Community Pool** — Um fundo discricionário (CP), mantido em USDC, que reinveste valor no crescimento da rede aberta — onboarding e expansão de participantes, marketing, eventos, grants competitivos e apoio ao ecossistema. Não é um fundo de doação. O Community Pool é financiado pelos próprios mecanismos de integridade e incentivo da rede: o desconto de digitalização da cadeia, recompensas não resgatadas, penalidades de self-policing e colateral retido. Veja [Política de Distribuição de Recompensas](/docs/standard/policies/rewards-distribution).
**community-built** — Descreve a infraestrutura e a plataforma da Carrot — construídas pela comunidade e para a comunidade. Uso padrão ao descrever o sistema, a plataforma ou sua diferenciação.
**community-led** — Descreve governança e stewardship — decisões lideradas pela comunidade. Use apenas em contextos de governança. Distinto de [community-built](#community-built) (infraestrutura).
**Compostagem aeróbica** — Um processo para produzir composto rico em nutrientes através da decomposição aeróbica (com presença de oxigênio) de matéria orgânica. Produz pouco ou nenhum metano comparado à decomposição anaeróbica em aterros.
**Comprador catalítico** — Organização ou indivíduo orientado por propósito disposto a agir antes de os sistemas estarem totalmente comprovados; usa poder de compra para catalisar mudança sistêmica, desbloquear oferta e acelerar mercados. Veja [Compra de Créditos](/docs/protocol/credit-purchase).
**Comprador de créditos** — Uma organização ou indivíduo que compra e aposenta créditos para reivindicar impacto ambiental verificado. Compradores de créditos dependem do registry, dos certificados e dos registros de aposentadoria para apoiar alegações de reporte ou conformidade. Veja [Aposentadoria de Créditos](/docs/protocol/credit-retirement).
**Crédito** — Uma unidade digital fungível que representa 1 tonelada métrica de impacto ambiental verificado. Duas categorias: [TRC](/docs/protocol/credits) (créditos de reciclagem tokenizados, ex.: `C-BIOW` do BOLD Recycling) e [TCC](/docs/protocol/credits) (créditos de carbono tokenizados, ex.: `C-CARB.CH4` do BOLD Carbon (CH₄)). Cada metodologia emite créditos sob seu próprio símbolo no Registry.
**Créditos de Carbono** — Créditos ambientais tratados como commodities para trabalho verificado de descarbonização. Negociados em mercados voluntários + regulados. Os da Carrot são derivados de metano (tCO2e), a partir do desvio de bioresíduos para tratamento biológico — os "cisnes brancos" do carbono derivado de resíduos (vs captura de gás de aterro, os "patinhos feios").
**Créditos de Circularidade** — Termo guarda-chuva para créditos emitidos na Rede Carrot — todos os créditos gerados representam *circularidade* (materiais mantidos em uso; bioresíduos desviados de aterros para tratamento biológico), nunca "gestão de resíduos". Duas famílias: **Créditos de Reciclagem** (trabalho de reciclagem verificado, em toneladas — bioresíduos + plástico) e **Créditos de Carbono** (derivados de metano, em tCO2e — tratamento biológico de bioresíduos: compostagem, biogás/digestão anaeróbia, black soldier flies). Os créditos de carbono de tratamento biológico são os "cisnes brancos" do carbono derivado de resíduos — de valor mais alto que créditos de captura de gás de aterro ("patinhos feios") porque transformam resíduo em recurso (composto, energia verde, proteína), não apenas previnem metano.
**Custodiante de Ponto de Coleta** — Um participante da cadeia de suprimentos (BC) que gerencia contentores ou pontos de coleta onde Geradores de Resíduos depositam materiais recicláveis. Veja [cadeia de suprimentos](/docs/protocol/supply-chain).
## D [#d]
**Desenvolvedor de Rede** — Um papel do ecossistema que fomenta projetos de créditos e rastreabilidade ao prospectar e integrar participantes, coordenar o processo de homologação e enviar dados comprobatórios à Carrot. O Desenvolvedor de Rede não aprova participantes e não recebe recompensas do protocolo. Veja [Papéis no Ecossistema de Créditos](/docs/protocol/credit-ecosystem-roles#network-developer).
**dMRV** — digital Measurement, Reporting and Verification (Monitoramento, Relato e Verificação digital). A camada de execução e evidência digital que executa regras de metodologia contra dados reais da cadeia de suprimentos, produz resultados auditáveis e apoia a garantia independente. Veja [dMRV](/docs/protocol/dmrv).
**Documento** — A estrutura de dados raiz na [Carrot API](/docs/integrations/api) representando um registro de rastreabilidade. Um documento armazena campos de identidade e classificação ([categoria, tipo, subtipo](/docs/integrations/reference/waste-classification)); mudanças de estado são registradas como eventos anexados em sua [timeline](#timeline). Cada documento recebe um identificador único. Veja [Conceitos Fundamentais](/docs/integrations/getting-started/core-concepts).
## E [#e]
**Economia circular** — Um sistema onde os materiais nunca se tornam resíduos e a natureza é regenerada. Produtos e materiais são mantidos em circulação através de reuso, reforma, remanufatura, reciclagem e tratamento biológico.
**Emissões de referência** — As emissões de GEE que ocorreriam se os resíduos fossem descartados por métodos padrão (aterro, lixão) em vez de reciclados ou tratados biologicamente. Usadas para calcular [reduções de emissões](/docs/protocol/certificates).
**EPR** — Extended Producer Responsibility (Responsabilidade Estendida do Produtor). Uma política ambiental que responsabiliza produtores pelo gerenciamento de seus produtos ao longo de todo o ciclo de vida, incluindo descarte pós-consumo e reciclagem.
**ESG** — Environmental, Social, and Governance (Ambiental, Social e Governança). Um framework de relatório e conformidade corporativa que mede as práticas de sustentabilidade de uma organização. Organizações e indivíduos compram TRCs e TCCs para cumprir compromissos ESG.
**Evento (dMRV)** — Uma ocorrência operacional no fluxo de metodologia que requer entradas e validações definidas conforme o [MvF](/docs/standard/concepts/mvf)/[MvA](/docs/standard/concepts/mva).
**execução da metodologia** — O processo da plataforma para executar a verificação de metodologia: o [MvA](/docs/standard/concepts/mva) executa as regras do [framework de metodologia](/docs/standard/concepts/mvf) sobre dados da cadeia de suprimentos para produzir resultados verificados (MassIDs, certificados). Veja [Execução da Metodologia](/docs/protocol/methodology-execution).
**Explorador de blockchain** — Uma interface web de terceiros para visualizar dados on-chain brutos (transações, chamadas de contrato, logs de eventos) em uma blockchain pública. Transações da Rede Carrot podem ser verificadas via qualquer explorador de blockchain (ex.: [PolygonScan](https://polygonscan.com/) para Polygon PoS, que o Carrot utiliza atualmente) sem depender da infraestrutura do Carrot. Distinto do Carrot Registry, que combina dados on-chain com dados da plataforma (definições de metodologia, execução de regras, homologações) para uma visão focada no domínio.
## F [#f]
**FIFO** — First-In-First-Out (Primeiro a Entrar, Primeiro a Sair). O método de gerenciamento de inventário usado em instalações de processamento — os primeiros [MassIDs](/docs/protocol/mass-ids) no inventário de uma instalação são processados e creditados primeiro.
**Foundation Treasury** — Os recursos operacionais da Carrot Foundation (Foundation Treasury), financiados pelo digital MRV and Integrity Component em cada venda de crédito. Sustenta a stewardship da rede pela Fundação. Veja [Política de Distribuição de Recompensas](/docs/standard/policies/rewards-distribution).
**framework de metodologia** — A especificação operacional (MvF) que transforma uma metodologia em requisitos verificáveis, regras de evidência, fórmulas e outputs. Veja [MvF](/docs/standard/concepts/mvf).
## G [#g]
**GasID** — Um tipo de [certificado](/docs/protocol/certificates) emitido sob uma metodologia de carbono que quantifica as reduções de emissões de gases de efeito estufa por meio do desvio de resíduos. No [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon), GasIDs geram créditos `C-CARB.CH4` na emissão; outras metodologias de carbono podem usar símbolos diferentes.
**Gerador de Resíduos** — Um participante da cadeia de suprimentos (G) — a pessoa ou empresa que produz resíduos. Identificar o Gerador de Resíduos na [cadeia de custódia](#chain-of-custody) é crítico: quando ausente, [pagamentos](/docs/protocol/rewards-distribution) com desconto se aplicam à cadeia. Quando presente, a própria parte dele ainda é reduzida à metade se for uma empresa de grande porte ou se não tiver concluído o onboarding, e a metade descontada vai para o Impact Pool. Veja [cadeia de suprimentos](/docs/protocol/supply-chain).
**Gestor de Resíduos** — Um participante da cadeia de suprimentos (WM) contratado pelo [Gerador de Resíduos](#waste-generator) para coordenar a destinação dos resíduos sem assumir a custódia física do material. Para resíduos orgânicos, o Gestor de Resíduos se torna elegível à parcela de 4% somente depois que ambas as partes confirmam o vínculo. Veja [cadeia de suprimentos](/docs/protocol/supply-chain#waste-manager).
**Green Premium** — Diferença de custo entre um produto ou processo convencional e sua alternativa sustentável. A Carrot busca reduzir o green premium por meio de alinhamento de incentivos e oferta em escala.
**GWP** — Global Warming Potential (Potencial de Aquecimento Global). Uma medida de quanto calor um gás de efeito estufa retém em relação ao CO₂. O metano (CH₄) tem um GWP de 28 ao longo de 100 anos.
## H [#h]
**Homologação** — O processo formal que verifica se um [Reciclador](/docs/protocol/supply-chain#o-papel-do-reciclador), [Integrador](/docs/protocol/network-integrators) ou outro participante atende aos standards da Rede Carrot.
## I [#i]
**Ibama** — Instituto Brasileiro do Meio Ambiente e dos Recursos Naturais Renováveis. Publica a [Lista Brasileira de Resíduos Sólidos](https://www.gov.br/ibama/pt-br/assuntos/emissoes-e-residuos/residuos/arquivos/ibama-lista-brasileira-de-residuos-solidos.doc) (per IN nº 13/2012), que atribui códigos de classificação de 6 dígitos a materiais residuais. O BOLD Carbon utiliza esses códigos para classificação de resíduos. Veja [Códigos de resíduos suportados](/docs/methodologies/ams-iii-f/bold-carbon#códigos-de-resíduos-suportados).
**Impact Pool** — Um fundo (IP) de doação pura a projetos socioambientais e de economia circular no país onde a reciclagem ocorreu. Sua principal fonte é a parcela de recompensa redirecionada de Geradores classificados como Grande Empresa e a metade descontada de geradores que não concluíram o onboarding, garantindo que compradores de crédito não estejam financiando recompensas a grandes corporações. Veja [Política de Distribuição de Recompensas](/docs/standard/policies/rewards-distribution).
**Infraestrutura Pública Digital (DPI)** — Sistemas digitais que funcionam como trilhos compartilhados para a sociedade, e não como plataformas proprietárias: fundacionais, interoperáveis, inclusivos e publicamente responsáveis. O termo é usado pelo UCL Institute for Innovation and Public Purpose, pelo UNDP, pelo Banco Mundial e pelo G20; casos de referência incluem Aadhaar e UPI na Índia, Pix no Brasil e X-Road na Estônia. A Rede Carrot é infraestrutura pública digital para a economia circular de baixo carbono e eficiente no uso de recursos. Veja [Infraestrutura Pública Digital](/docs/network/digital-public-infrastructure).
**Integrador** — Uma aplicação ou plataforma de software de terceiros que conecta operações reais à Rede Carrot enviando dados da cadeia de suprimentos pela API. Integradores são a ponte de dados entre sistemas operacionais e a camada de dMRV da Carrot; eles são distintos dos participantes físicos da cadeia de suprimentos que manuseiam material. Veja [Integradores](/docs/protocol/network-integrators).
## K [#k]
**KYC** — Know Your Customer/Client (Conheça Seu Cliente). O processo obrigatório de verificação de identidade do participante antes da participação na rede.
## L [#l]
**Lixo Zero** — A conservação de todos os recursos por meio de produção, consumo, reuso e recuperação responsáveis de produtos, embalagens e materiais, sem queima e sem descargas no solo, na água ou no ar que ameacem o meio ambiente ou a saúde humana. Objetivo: reduzir resíduos para aterros em mais de 90%.
## M [#m]
**MassID** — Um registro digital único e intransferível, criado quando um resíduo é identificado e medido. Registra tipo de material, peso e cadeia de custódia. É a base do sistema de verificação da Rede Carrot. Veja [MassIDs](/docs/protocol/mass-ids).
**Merkle proof** — Um método criptográfico usado para [distribuição de recompensas](/docs/protocol/rewards-distribution) com preservação de privacidade, permitindo que participantes reivindiquem recompensas sem expor todos os detalhes da distribuição nos registros públicos.
**Metadados** — Pares chave-valor anexados a eventos que fornecem informações contextuais sobre uma ação operacional — por exemplo, data, localização, veículo, operador ou medição de peso. Também chamados de *atributos*. Veja [Formatos de Dados](/docs/integrations/reference/data-formats).
**Metadata Viewer** — A ferramenta pública em [viewer.carrot.eco](https://viewer.carrot.eco) que abre o documento de proveniência por trás de um registro de MassID, Certificado ou recibo da Carrot e o renderiza no navegador de quem está lendo. Ela lê a URI de metadados do token no [smart contract](/docs/protocol/smart-contracts) e busca o documento no IPFS. As conferências são deliberadamente estreitas: a validação de schema só roda quando o build do viewer carrega a versão que o registro declara, e a conferência de ida e volta on-chain só quando o registro é aberto pela referência IPFS, colado ou enviado. Mais estreita que o [Carrot Registry](/docs/protocol/registry): mostra o que um registro diz, não o que o registro significa em contexto ambiental. Veja [Metadata Viewer](/docs/protocol/metadata-viewer).
**metodologia** — A base científica para medir uma alegação ambiental específica. Uma metodologia é traduzida em um [framework de metodologia (MvF)](/docs/standard/concepts/mvf) operacional e depois implementada como uma [MvA](/docs/standard/concepts/mva) para execução digital. Veja [Metodologias](/docs/methodologies).
**MvA** — Methodology Verification Application (Aplicação de Verificação de Metodologia). A implementação determinística em software de um [framework de metodologia (MvF)](/docs/standard/concepts/mvf) que avalia dados enviados e retorna resultados de verificação rastreáveis. Veja [MvA](/docs/standard/concepts/mva).
**MvA Developer** — O engenheiro que implementa frameworks de metodologia em código (o MvA). Veja [MvA](/docs/standard/concepts/mva) e o [Guia do MvA Developer](/docs/standard/guides/mva-developer-guide).
**MvF** — Methodology Verification Framework (Framework de Verificação de Metodologia). O documento de especificação que define regras, cálculos, requisitos de evidência e critérios de verificação para uma metodologia. Veja [MvF](/docs/standard/concepts/mvf).
**MvF Author** — O especialista que redige frameworks de metodologia. Veja [MvF](/docs/standard/concepts/mvf) e o [Guia do MvF Author](/docs/standard/guides/mvf-author-guide).
**MyCarrot** — O portal do comprador na Rede Carrot, disponível em [my.carrot.eco](https://my.carrot.eco). Oferece um painel de impacto com métricas acumuladas, histórico de compras com detalhes de certificados e trilhas de auditoria vinculadas ao [Carrot Registry](/docs/protocol/registry). Não requer conhecimento de blockchain. Veja [Compra de Créditos](/docs/protocol/credit-purchase).
## P [#p]
**Pacote de evidências digitais** — Um conjunto organizado de dados, documentos, logs, versões e resultados de validação produzidos durante a execução do dMRV; suporta auditoria e governança.
**Participação comunitária progressiva** — A abordagem da Carrot Foundation para expandir gradualmente a participação comunitária na governança do ecossistema à medida que a rede amadurece, através de três fases: engajamento, consultiva e deliberativa. Veja [Governança](/docs/network/governance).
**PAYT** — Pay-As-You-Throw (Pague pelo que Descarta). Um modelo de precificação de gestão de resíduos onde domicílios e empresas pagam pela coleta de resíduos com base na quantidade gerada — incentivando a triagem na origem e a reciclagem. Veja [A Solução](/docs/protocol/the-solution).
**Processador** — Um participante da cadeia de suprimentos (P) que separa, acumula ou pré-processa materiais residuais antes de chegarem a um Reciclador certificado. Veja [cadeia de suprimentos](/docs/protocol/supply-chain).
**Proof-of-Authority (PoA)** — O mecanismo de confiança na Rede Carrot que garante a integridade dos dados através de três camadas: autopoliciamento via incentivos econômicos (participantes perdem recompensas se os dados forem fraudulentos), homologação de instalações conduzida por auditores independentes terceirizados, e supervisão da rede pela [Carrot Foundation](/docs/network/the-foundation) que pode suspender ou desqualificar agentes mal-intencionados. Veja [dMRV](/docs/protocol/dmrv#proof-of-authority-details).
**Proof-of-Physical-Work (PoPW)** — Evidência de que trabalho real de reciclagem foi realizado, registrado através de eventos de cadeia de suprimentos e validado em cada ponto de transferência na cadeia de suprimentos.
**Proof-of-Provenance (PoP)** — Evidência que rastreia a origem e a jornada de materiais residuais desde a fonte até a reciclagem certificada, registrada em [MassIDs](/docs/protocol/mass-ids).
**Protocolo** — Um conjunto específico de regras tecnológicas e financeiras por domínio que agrupa metodologias relacionadas e sua economia dentro da Rede Carrot. O primeiro protocolo cobre economia circular (logística reversa, reciclagem, tratamento biológico).
## R [#r]
**Reciclador** — Um processador que foi homologado para realizar reciclagem certificada para um tipo específico de resíduo. Somente Recicladores homologados podem acionar a geração de créditos. Veja [cadeia de suprimentos](/docs/protocol/supply-chain#o-papel-do-reciclador).
**Recicle e Ganhe** — O modelo de incentivo no qual cada participante verificado da [cadeia de suprimentos](/docs/protocol/supply-chain) recebe uma parcela dos recursos da venda de [créditos](/docs/protocol/credits) pelo seu papel no processo de reciclagem. Os recursos das compras de créditos são [distribuídos](/docs/protocol/rewards-distribution) entre os MassIDs subjacentes proporcionalmente ao valor dos créditos retirados de cada um, e depois divididos pelo papel de cada participante.
**RecycledID** — Um tipo de [certificado](/docs/protocol/certificates#recycledid) emitido sob uma metodologia de reciclagem que verifica que uma quantidade específica de resíduo foi reciclada de forma certificada. Sob o [BOLD Recycling](/docs/methodologies/bold-recycling), RecycledIDs geram tokens de crédito `C-BIOW`; outras metodologias de reciclagem podem usar símbolos diferentes.
**Rede Carrot (Carrot Network)** — A infraestrutura pública digital da Carrot para a economia circular de baixo carbono e eficiente no uso de recursos: trilhos de mercado compartilhados que abrangem o [standard](/docs/standard), o [registry](/docs/registry) público de créditos, infraestrutura de [dMRV](/docs/protocol/dmrv) para [verificação de terceiros](/docs/protocol/third-party-verification), o [Protocolo da Economia Circular](/docs/protocol) e a [governança](/docs/network/governance) administrada pela Fundação. "Rede Carrot" nomeia o todo; a camada de governança dentro dela é chamada de Governança. Contratos inteligentes apoiam seus registros de créditos, distribuição de recompensas e rastreabilidade de decisões.
**Registry (papel da Carrot)** — O Registry emite, registra e aposenta créditos ambientais e mantém registros públicos duráveis de seu ciclo de vida. A infraestrutura do registry fornece registros públicos, permanentes e verificáveis de forma independente, distinta do papel de [Standard](/docs/standard) — a Carrot exerce ambos. Veja [Registry](/docs/registry).
**regras da metodologia** — As regras de verificação definidas em um [framework de metodologia (MvF)](/docs/standard/concepts/mvf) e implementadas/executadas pelo [MvA](/docs/standard/concepts/mva). Veja [Execução da Metodologia](/docs/protocol/methodology-execution) e [MvF](/docs/standard/concepts/mvf).
**Responsável pelo Programa** — Um papel do ecossistema que lidera o desenvolvimento de um programa de créditos ao coordenar sua metodologia, o [Methodology Verification Framework (MvF)](/docs/standard/concepts/mvf), a [Methodology Verification Application (MvA)](/docs/standard/concepts/mva) e a proposta de política de recompensas. O Responsável pelo Programa não aprova o próprio programa, não detém seus créditos e não recebe recompensas do protocolo. Veja [Papéis no Ecossistema de Créditos](/docs/protocol/credit-ecosystem-roles#program-owner).
**RFP** — Request for Proposals (Chamada de Propostas). O mecanismo formal pelo qual a Carrot busca novas contribuições para o ecossistema — desde desenvolvimento de metodologias (MvF + MvA) até projetos de infraestrutura e soluções tecnológicas. Cada RFP define escopo, critérios de elegibilidade, matriz de avaliação, cronograma e entregáveis. Seis tipos (A--F) cobrem diferentes necessidades: resolução de problemas, projetos AMC, construção de MvF, construção de MvA, soluções tecnológicas e chamadas abertas. Veja o [Processo de RFP](/docs/standard/policies/rfp-process) para o ciclo de vida completo e descrição dos tipos, e o [Guia de Participação em RFPs](/docs/standard/guides/rfp-participation-guide) para critérios de avaliação e instruções de submissão. Veja também [Ecossistema de Metodologias](/docs/standard/concepts/ecosystem) e [Ciclo de Vida da Metodologia](/docs/standard/concepts/lifecycle).
## S [#s]
**Sistema de créditos (crediting system)** — O sistema de créditos da economia circular que abrange um [standard](/docs/standard) (governança de metodologias), um [registry](/docs/registry) público de créditos e infraestrutura de [dMRV](/docs/protocol/dmrv) para [verificação de terceiros](/docs/protocol/third-party-verification). Para um mapa papel por papel, veja [Papéis no Ecossistema de Créditos](/docs/protocol/credit-ecosystem-roles).
**Smart contracts** — Programas autoexecutáveis em blockchain que registram e automatizam operações da Rede Carrot, como criação de registros no Registry, distribuição de recompensas, compras de créditos e aposentadoria de créditos. Veja [Smart Contracts](/docs/protocol/smart-contracts).
**Soulbound** — Uma propriedade técnica de alguns registros em blockchain que significa que eles não podem ser transferidos entre contas. A Rede Carrot usa registros intransferíveis no Registry para MassIDs, certificados e recibos, preservando uma trilha de auditoria permanente.
**Standard (papel da Carrot)** — A Carrot governa, aprova e gerencia o ciclo de vida das metodologias ambientais. Distinto do papel de [Registry](/docs/registry) — a Carrot exerce ambos. Veja [O Standard](/docs/standard).
**Subtipo** — O nível de classificação mais específico para um [documento](#document), refinando o [tipo](#type). Por exemplo, dentro do tipo `Organic`, subtipos incluem `Food, Food Waste and Beverages`, `Garden, Yard and Park Waste`, `Industrial Sludge`. Os subtipos aceitos dependem da metodologia. Veja [Classificação de Resíduos](/docs/integrations/reference/waste-classification).
## T [#t]
**TCC (`C-CARB.CH4`)** — Tokenized Carbon Credit (Crédito de Carbono Tokenizado). Um crédito fungível que representa 1 tonelada métrica de reduções de emissões de CO₂-equivalente por meio do desvio de resíduos. O símbolo no registry público de créditos `C-CARB.CH4` é usado para TCCs emitidos pela metodologia [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) (metano); outras metodologias de carbono podem emitir TCCs com símbolos diferentes. Veja [créditos](/docs/protocol/credits#tokenized-carbon-credits-tcc).
**Timeline** — A sequência cronologicamente ordenada de eventos registrados em um [documento](#document), representando o histórico operacional completo de uma massa desde a origem até o destino final. Visível no [Carrot Registry](/docs/protocol/registry).
**Tipo** — A classificação de nível intermediário para um [documento](#document), identificando a classe primária de material ou processo (ex.: `Orgânico`, `Plástico`, `Papel`, `Vidro`). Veja [Classificação de Resíduos](/docs/integrations/reference/waste-classification).
**Tracking ID** — O identificador público único atribuído a cada [documento](#document) na plataforma Carrot, usado para consultar o registro no [Carrot Registry](/docs/protocol/registry).
**Transportador** — Um participante da cadeia de suprimentos (H) que transporta resíduos entre locais — de pontos de coleta a processadores ou recicladores. Pode incluir tanto transportadores locais quanto de longa distância. Veja [cadeia de suprimentos](/docs/protocol/supply-chain).
**Tratamento biológico** — O processamento de resíduos orgânicos por meio de processos biológicos controlados que previnem emissões de metano provenientes da disposição em aterros. Inclui compostagem, digestão anaeróbia, processamento por larvas black soldier fly, processamento microbiano e outros métodos. Veja também [Compostagem aeróbica](#aerobic-composting).
**TRC (`C-BIOW`)** — Tokenized Recycling Credit (Crédito de Reciclagem Tokenizado). Um crédito fungível que representa 1 tonelada métrica de material reciclado certificado. O símbolo no registry público de créditos `C-BIOW` é usado para TRCs emitidos pela metodologia [BOLD Recycling](/docs/methodologies/bold-recycling); outras metodologias de reciclagem podem emitir TRCs com símbolos diferentes. Veja [créditos](/docs/protocol/credits#tokenized-recycling-credits-trc).
## U [#u]
**USDC** — USD Coin. Uma moeda digital rastreável atrelada 1:1 ao dólar americano, usada na Rede Carrot para compras de créditos e [distribuição de recompensas](/docs/protocol/rewards-distribution). Oferece aos participantes valor estável sem a volatilidade de preços de mercado.
## V [#v]
**Validador** — A parte receptora em uma transferência de material que confirma o conteúdo (peso, qualidade, origem) e atualiza o [MassID](/docs/protocol/mass-ids). Na maioria dos eventos de cadeia de suprimentos, o receptor atua como Validador. Veja [dMRV](/docs/protocol/dmrv#validators-and-supply-chain-events).
**Vault** — O contrato inteligente que mantém todos os registros intransferíveis (MassIDs, certificados e recibos) e o inventário de créditos em nome da rede. Veja [Contratos Inteligentes](/docs/protocol/smart-contracts).
**Verificação de Terceiros** — A prática de utilizar entidades terceirizadas independentes (VVBs, auditores) para validar conformidade com metodologias, homologação de instalações, pacotes de evidências de dMRV e integridade de créditos. A verificação de terceiros é independente das operações da plataforma Carrot e usa os registros de dMRV da Carrot como evidência auditável.
**VVB** — Validation/Verification Body (Organismo de Validação/Verificação). Uma entidade independente e terceirizada que fornece garantia externa para a Rede Carrot — da validação de metodologias à revisão de evidências. Veja [Verificação de Terceiros](/docs/protocol/third-party-verification) para escopo completo e responsabilidades.
# Registry
## O que é um registry? [#o-que-é-um-registry]
Um registry é o sistema que emite [créditos ambientais](/docs/protocol/credits), atribui a cada crédito um identificador único, rastreia mudanças de titularidade e registra aposentadorias. Sua função central é prevenir a dupla contagem — garantindo que o mesmo benefício ambiental não possa ser reivindicado por mais de um comprador.
Para entender como o registry se relaciona com [standards](/docs/standard), metodologias, Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)),
garantia independente e compradores — incluindo quem emite créditos de carbono e de reciclagem — veja [Papéis no Ecossistema de Créditos](/docs/protocol/credit-ecosystem-roles).
## Como o registry da Carrot funciona [#como-o-registry-da-carrot-funciona]
Os créditos na Carrot são emitidos como ativos digitais no registry público. Cada crédito carrega um registro auditável que vincula o evento físico que o originou — uma massa verificada de material coletado, triado ou processado — passando pela emissão e pela compra até sua eventual aposentadoria.
Esse registro é publicamente acessível: qualquer pessoa pode confirmar a emissão, o histórico de titularidade e a aposentadoria de um crédito no ledger público sem a cooperação da Carrot. As identidades dos participantes no registro de procedência são publicadas como hashes, não como nomes, e os resultados de verificação por trás de um crédito ficam com a plataforma — veja [Carrot Registry](/docs/protocol/registry) para saber o que está on-chain e o que fica na plataforma.
## O que o registry cobre [#o-que-o-registry-cobre]
O registry é o lugar do ciclo de vida dos créditos quando resultados ambientais verificados estão prontos para se tornar ativos voltados ao mercado. Ele cobre:
* **Emissão de créditos** — Certificados RecycledID e GasID lastreiam créditos fungíveis, como Créditos de Reciclagem e Créditos de Carbono, respectivamente.
* **Rastreamento de créditos fungíveis** — Saldos de crédito são rastreados por certificado para que quantidades disponíveis, compradas e aposentadas não excedam o volume verificado que as lastreia.
* **Registros de compra** — Compras de crédito criam registros permanentes que conectam compradores, pagamento, certificados e quantidades compradas.
* **Registros de aposentadoria** — A aposentadoria de crédito remove permanentemente de circulação a quantidade reivindicada e cria um recibo permanente para a reivindicação ambiental.
* **Fluxos de conta e custódia** — Contas de compradores e participantes interagem com saldos de crédito, recibos e fluxos de liquidação, enquanto evidências intransferíveis permanecem permanentemente ancoradas à infraestrutura do registry.
* **Camada de liquidação** — Fluxos de compra e aposentadoria conectam pagamento, alocação de inventário, distribuição de recompensas e registros permanentes de auditoria.
O registry não decide se uma atividade física se qualifica para emissão de créditos. Essa decisão vem dos critérios de frameworks de metodologia aprovados executados por dMRV. O registry registra o ciclo de vida resultante do crédito: emissão, atividade relacionada à titularidade, compra, aposentadoria e os recibos que tornam essas ações auditáveis.
## Por que o registry é construído dessa forma? [#por-que-o-registry-é-construído-dessa-forma]
O registry opera sobre infraestrutura blockchain. Três propriedades desse desenho importam diretamente para compradores de créditos:
* **Público e permanente** — Os registros de créditos existem em um livro-razão público, não em um banco de dados privado controlado por uma única organização. Os dados persistem independentemente do que aconteça com qualquer empresa ou serviço individual.
* **Verificável de forma independente** — Qualquer auditor, regulador ou comprador pode confirmar a integridade de um crédito — sua emissão, histórico de titularidade e status de aposentadoria — sem requerer a cooperação da Carrot ou acesso a sistemas proprietários.
* **Programável** — [Contratos inteligentes](/docs/protocol/smart-contracts) retêm os valores da venda de créditos e liberam a parte de cada participante da [cadeia de suprimentos](/docs/protocol/supply-chain) mediante uma prova criptográfica da alocação comprometida. O que cada participante tem a receber é fixado on-chain no momento da venda, e não decidido depois.
Para entender por que a Carrot constrói isso como [infraestrutura pública digital](/docs/network/digital-public-infrastructure), veja a seção da Rede.
## Registry, Standard e Verificação de Terceiros [#registry-standard-e-verificação-de-terceiros]
A Carrot desempenha três funções distintas dentro de seu ecossistema. O **registry** emite e rastreia créditos. [O **standard**](/docs/standard) governa o programa e as [metodologias](/docs/methodologies) que determinam como benefícios ambientais são mensurados e quais atividades qualificam para emissão de créditos. A [**verificação de terceiros**](/docs/protocol/third-party-verification) assegura que cada nível do ecossistema — desde auditorias de instalações até a execução automatizada do dMRV — seja validado por terceiros.
Essas funções são complementares, mas separadas. O registry é infraestrutura — deve ser confiável, transparente e resistente a adulterações. O standard é governança — deve ser cientificamente rigoroso e operacionalmente aplicável. A verificação de terceiros é asseguração — deve ser realizada por partes independentes das operações da Carrot. A Carrot opera o registry e define o standard; a verificação de terceiros é conduzida por auditores externos independentes e [Organismos de Validação e Verificação (VVBs)](/docs/glossary#vvb).
O registry é alimentado por um conjunto de contratos inteligentes que gerenciam o ciclo de vida completo do crédito — da emissão à aposentadoria. Cada etapa do ciclo de vida é registrada on-chain, criando uma trilha completa e auditável para cada crédito emitido.
Para uma cobertura mais aprofundada dos componentes individuais, consulte:
* [Créditos](/docs/protocol/credits) — tipos e estrutura dos créditos
* [Criação de Registros no Registry](/docs/protocol/on-chain-minting) — como a verificação física se torna um registro permanente no registry
* [Aposentadoria de Créditos](/docs/protocol/credit-retirement) — como os créditos são permanentemente retirados de circulação
* [Contratos Inteligentes](/docs/protocol/smart-contracts) — os contratos que governam emissão, transferência e aposentadoria
# Visão Geral das Integrações
Integrações conectam sua plataforma à [Rede Carrot](/docs/protocol/how-it-works) para que
[Integradores](/docs/protocol/network-integrators) possam enviar dados de rastreabilidade da cadeia de suprimentos
por meio da [Carrot API](/docs/integrations/api). Cada documento representa um registro de rastreabilidade do mundo real — como um
[MassID](/docs/protocol/mass-ids) rastreando um lote de resíduos pela
[cadeia de suprimentos](/docs/protocol/supply-chain) — construído como uma linha do tempo imutável de eventos que sustenta a emissão de créditos de reciclagem e de carbono, verificada pelo
processo de Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)).
Esta seção cobre o fluxo prático de integração, guias de implementação e dados de referência compartilhados necessários
antes que as regras específicas da [metodologia](/docs/methodologies) sejam aplicadas.
## Para agentes de IA [#para-agentes-de-ia]
Se você usa Claude, Cursor, Codex ou outro cliente MCP para responder perguntas a partir da Carrot Docs, prefira o servidor MCP público e somente leitura da Carrot Docs em `https://docs.carrot.eco/mcp`. Ele oferece aos agentes busca, consulta de documentos, pesquisa no glossário e navegação por documentos relacionados sobre a documentação publicada.
Comece por [Conectar Seu Agente de IA](/docs/integrations/getting-started/connect-ai-agent). Para clientes sem suporte a MCP, use [/llms.txt](/llms.txt) ou [/llms-full.txt](/llms-full.txt) como alternativas legíveis por máquina.
## Conceitos-chave [#conceitos-chave]
Antes de mergulhar na API, três ideias fundamentam toda integração:
* **Documentos e eventos** — Um [documento](/docs/integrations/api/documents) é o registro raiz de um fluxo de rastreabilidade (ex.: um MassID rastreando um lote de resíduos). Todas as mudanças de estado são representadas por [eventos](/docs/integrations/api/events) adicionados à linha do tempo do documento — não há endpoints de atualização ou exclusão.
* **Imutabilidade** — A plataforma usa um modelo baseado em eventos (event-sourced): cada submissão é adicionada ao histórico, e o estado atual é derivado do log de eventos. Se você precisar corrigir um erro, cancele o documento com um evento `CANCEL` e crie um novo. Essa imutabilidade sustenta a confiança no mercado de [créditos ambientais](/docs/protocol/credits).
* **Idempotência** — Use `deduplicationId` em toda chamada de criação e evento para que retentativas não produzam duplicatas. Um id repetido é rejeitado com `409 CONFLICT_ERROR` em vez de reexecutado — trate esse conflito como confirmação de que a primeira tentativa teve sucesso. Isso, combinado com timestamps `externalCreatedAt` ordenados, torna as integrações resilientes a falhas transitórias.
Para a explicação completa, veja [Conceitos Fundamentais](/docs/integrations/getting-started/core-concepts).
## Modelo de integração [#modelo-de-integração]
Em alto nível, toda integração segue o mesmo fluxo base:
1. Autenticar com credenciais de cliente OAuth 2.0.
2. Resolver participantes e endereços — recuperar por chave ou criá-los (`GET`/`POST /participants`, `POST /participants/{participantId}/addresses`).
3. Criar um documento (`POST /documents`), referenciando `participantId` e `addressId`.
4. Adicionar eventos à linha do tempo (`POST /documents/{documentId}/events`), ou enviar múltiplos eventos de uma vez (`POST /documents/events`).
5. Fazer upload de arquivos opcionais por meio de URLs de anexo pré-assinadas.
6. Consultar e validar o estado final (`GET /documents/{id}`).
Veja a [Referência da API](/docs/integrations/api) para detalhes dos contratos de cada endpoint.
## Pré-requisitos [#pré-requisitos]
* `clientId` e `clientSecret` emitidos pela Carrot.
* Uma estratégia estável de identificadores para `externalId` e `deduplicationId`.
* Ordenação de timestamps de eventos do seu sistema de origem.
* Controles de retentativas e rate-limiting no seu cliente.
## Integração (onboarding) [#integração-onboarding]
Para integrar com a Rede Carrot, sua plataforma passa pela [homologação](/docs/protocol/network-integrators): você envia informações da empresa e endereço e assina um acordo. Uma vez que o processo começa, a Carrot emite **credenciais de teste** para que você possa desenvolver e validar sua integração com dados de teste. Após a homologação ser concluída, a Carrot emite **credenciais de produção** para dados reais. Veja [Ambientes](/docs/integrations/getting-started/environments) para o comportamento de teste vs produção e o checklist de go-live.
## Como esta seção está organizada [#como-esta-seção-está-organizada]
* [Primeiros Passos](/docs/integrations/getting-started/quick-start): primeiro fluxo ponta a ponta, conceitos fundamentais e configuração de ambiente.
* [Guias](/docs/integrations/guides/submitting-a-mass-id): padrões de implementação orientados a tarefas.
* [Referência](/docs/integrations/reference/event-specification): restrições compartilhadas de eventos e dados.
* [Integração por Metodologia](/docs/integrations/guides/methodology-guides): eventos, atributos e regras de validação específicos de cada metodologia.
## Migrando de uma integração anterior [#migrando-de-uma-integração-anterior]
Se você está atualizando de uma integração mais antiga ou de uma versão diferente da API, observe estes requisitos atuais:
* **Categoria do documento** — Use `MassID` (não `Mass`).
* **Unidade de medida** — Use `kg` (minúsculo) para massa.
* **Chaves de metadados** — Use Title Case (ex.: `Vehicle License Plate`, `Issue Date`). Veja [Formatos de Dados](/docs/integrations/reference/data-formats).
* **Eventos ACTOR** — Use o campo `label` para identificar os papéis dos participantes (Waste Generator, Recycler, Processor, Hauler, Integrator). Não envie campos descontinuados como `actor-type`.
* **Participantes e endereços** — Prefira resolvê-los primeiro e referenciar por `participantId`/`addressId`. Objetos `participant`/`address` inline continuam suportados e fazem find-or-create do registro; envie exatamente uma das formas de cada.
* **Nomes de eventos** — Use os nomes de eventos específicos exigidos pela metodologia (ex.: `Pick-up`, `Transport Manifest`, `Weighing`, `Drop-off`, `Sorting`, `Recycled`, `Recycling Manifest`). O evento `OPEN` não é utilizado; não o envie.
Para a sequência completa de eventos e requisitos de campos, veja os [guias de integração por metodologia](/docs/integrations/guides/methodology-guides).
# Visão Geral das Metodologias
## O que é uma metodologia? [#o-que-é-uma-metodologia]
Uma metodologia na [Rede Carrot](/docs/network) é uma base científica validada que sustenta como o impacto ambiental — incluindo emissões e créditos de carbono — é medido, reportado e verificado por meio de Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)). Cada entrada de metodologia aprovada abrange um domínio ambiental específico — como desvio de resíduos orgânicos ou reduções de emissões de metano — e é traduzida em lógica de verificação automatizada por meio de um [framework de metodologia (MvF)](/docs/standard/concepts/mvf) que define regras, requisitos e cálculos concretos.
Toda metodologia possui três camadas:
1. **Metodologia** — A base científica validada aprovada para uso na rede.
2. **[Methodology Verification Framework (MvF)](/docs/standard/concepts/mvf)** — Um documento de especificação estruturado que traduz a metodologia em regras de verificação concretas, fórmulas e requisitos de dados.
3. **[Methodology Verification Application (MvA)](/docs/standard/concepts/mva)** — Software de código aberto que implementa o MvF como processadores de regras executáveis. Cada regra avalia documentos [MassID](/docs/protocol/mass-ids) e retorna um resultado PASSED, FAILED ou REVIEW\_REQUIRED com uma explicação.
## Metodologias e frameworks aprovados [#metodologias-e-frameworks-aprovados]
A Carrot aprova metodologias, frameworks de verificação de metodologia e aplicações de dMRV de terceiros para uso na Rede Carrot. A metodologia fornece a base científica validada; o framework traduz essa base em critérios operacionais; e a aplicação executa esses critérios em código.
A aprovação cobre o pacote completo: a base científica, o framework operacional e a aplicação executável. Isso mantém a responsabilidade com o contribuidor e dá à Carrot um caminho claro de revisão para qualidade, ciclo de vida e adequação à rede.
## Como o sistema funciona [#como-o-sistema-funciona]
1. **Propor** — Um proponente de metodologia submete uma nova metodologia alinhada ao [Carrot dMRV Standard](/docs/standard). A proposta define a reivindicação ambiental, os tipos de resíduos elegíveis e a abordagem de verificação.
2. **Validar** — A Comunidade de Especialistas analisa a proposta quanto ao rigor científico, adicionalidade e possíveis colisões com metodologias existentes.
3. **Implantar** — [MvF Authors](/docs/standard/concepts/mvf#o-papel-do-mvf-author) escrevem a especificação de verificação e [MvA Developers](/docs/standard/concepts/mva#o-papel-do-mva-developer) a implementam como processadores de regras. As regras são implantadas como funções independentes que avaliam documentos de forma autônoma.
4. **Verificar** — [Integradores](/docs/protocol/network-integrators) submetem dados da [cadeia de suprimentos](/docs/protocol/supply-chain) como documentos MassID. O MvA avalia cada documento contra todas as regras. Quando todas as regras são aprovadas, [certificados](/docs/protocol/certificates) e [créditos](/docs/protocol/credits) são emitidos.
Para uma visão detalhada de como a plataforma recebe dados da cadeia de suprimentos e executa as regras da metodologia, veja [Execução da Metodologia](/docs/protocol/methodology-execution).
## Ecossistema aberto [#ecossistema-aberto]
Todas as regras da metodologia são de código aberto sob a licença LGPL-3.0. Qualquer pessoa pode auditar a lógica de verificação, propor melhorias ou submeter propostas de metodologia, frameworks de verificação de metodologia e aplicações de dMRV de terceiros para revisão e aprovação na infraestrutura compartilhada.
* **Código-fonte**: [github.com/carrot-foundation/methodology-rules](https://github.com/carrot-foundation/methodology-rules)
* **Governança**: Gerenciada pela [Carrot Foundation](/docs/network/the-foundation) com expansão progressiva da participação comunitária.
* **Infraestrutura compartilhada**: Metodologias reutilizam processadores de regras comuns. A maioria das regras é compartilhada entre todas as metodologias ativas.
## Explorar [#explorar]
* **[Catálogo de Metodologias](/docs/methodologies)** — Navegue pelas metodologias ativas, seus frameworks, aplicações e regras.
* **[BOLD Recycling](/docs/methodologies/bold-recycling)** — Desvio de resíduos orgânicos de aterros para compostagem, gerando Tokenized Recycling Credits ([TRC](/docs/protocol/credits#tokenized-recycling-credits-trc)).
* **[BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon)** — Reduções de emissões de metano por meio da compostagem, gerando Tokenized Carbon Credits ([TCC](/docs/protocol/credits#tokenized-carbon-credits-tcc)).
* **[MvA](/docs/standard/concepts/mva)** — Como as regras da metodologia são estruturadas e implementadas.
* **[Guia do MvF Author](/docs/standard/guides/mvf-author-guide)** — Como escrever um Methodology Verification Framework.
* **[Guia do MvA Developer](/docs/standard/guides/mva-developer-guide)** — Como implementar regras da metodologia em código.
[Saiba mais sobre dMRV](/docs/protocol/dmrv) · [Saiba mais sobre o Carrot dMRV Standard](/docs/standard)
# Governança
## Propósito imutável [#propósito-imutável]
A [Fundação Carrot](/docs/network/the-foundation) existe para construir a economia circular de baixo carbono e inclusiva. Esse propósito está registrado em registros públicos da Fundação e é vinculante nos estatutos da Fundação: decisões ordinárias de governança, transições de liderança e mudanças do ecossistema não podem se sobrepor a ele. As regras, [estruturas de metodologia (MvFs)](/docs/standard/concepts/mvf) e a governança operacional da [Rede Carrot](/docs/network) devem permanecer alinhadas com esse compromisso.
## Modelo de administração [#modelo-de-administração]
A Fundação atua como administradora da Rede Carrot — não como sua proprietária. Propriedade implica discricionariedade sobre o ativo; administração implica obrigação com a missão. O Conselho da Fundação pode evoluir como o ecossistema opera, mas a governança ordinária não pode se sobrepor ao propósito que o ecossistema existe para servir.
Este é o modelo de confiança atual: uma instituição responsável e identificável administra a rede hoje, e essa administração é limitada por propósito, registros públicos, regras versionadas e desenho de sistema auditável.
## Governança por arquitetura [#governança-por-arquitetura]
O modelo de governança da Carrot é projetado para que a responsabilização não dependa apenas da confiança na liderança atual ou do acesso a sistemas privados. Governança de valor público não pode se apoiar apenas em linguagem de valores: a rede usa administração pela Fundação, registros públicos, regras versionadas, lógica de metodologia inspecionável, evidências de Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)) — incluindo créditos de carbono e de reciclagem —, garantia independente, dados de créditos rastreáveis e mecânicas de recompensa publicadas para que decisões e resultados possam ser revisados posteriormente.
Isso não substitui a governança institucional nem a revisão independente. Torna a governança mais responsável ao permitir que decisões lideradas pela Fundação, mudanças de metodologia, resultados de verificação, evidências de garantia, registros de créditos e mecânicas de recompensa sejam revisados em relação às regras que os produziram.
Essa arquitetura de governança é parte do motivo pelo qual a Rede Carrot é construída como [infraestrutura pública digital](/docs/network/digital-public-infrastructure), não como uma plataforma privada de mensuração.
## Como o ecossistema é governado hoje [#como-o-ecossistema-é-governado-hoje]
A [Fundação Carrot](/docs/network/the-foundation) é responsável pela governança da camada de rede e protocolo — incluindo direção do standard, administração do registro, conformidade das metodologias, desenvolvimento do protocolo, continuidade operacional e alocação de recursos.
Participantes, integradores, contribuidores de metodologia, auditores e aplicações operam dentro da rede conforme seus próprios papéis e responsabilidades. A participação deles informa o ecossistema, mas não significa que o controle já tenha saído da Fundação.
As decisões são tomadas pelo Conselho da Fundação, composto por membros fundadores e conselheiros com experiência em produto, tecnologia, operações, meio ambiente, jurídico e finanças. Essa estrutura fornece um órgão claramente responsável durante o estágio atual de desenvolvimento, ao mesmo tempo em que permite que evidências, feedback e especialidade de domínio do ecossistema orientem decisões de governança.
A autoridade da Fundação permanece limitada pelo propósito público e pelas regras, registros de evidências e processos de garantia inspecionáveis que outras partes podem revisar.
### Responsabilidades atuais de decisão [#responsabilidades-atuais-de-decisão]
| Área de decisão | Responsabilidade atual | Responsabilização pública e caminho de participação |
| -------------------------------------------------- | ------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| Propósito e administração da Fundação | Conselho da Fundação | O propósito é ancorado em registros públicos da Fundação; a governança pode evoluir ao redor dele |
| Direção do protocolo e do standard | Conselho da Fundação | Contribuições estruturadas de conselheiros, Autores de MvF, Desenvolvedores de MvA, integradores, auditores e participantes ativos |
| Aprovação e evolução de metodologias | Processo liderado pela Fundação | Evidências e recomendações de Autores de MvF, Desenvolvedores de MvA, auditores e especialistas de domínio |
| Conformidade operacional e qualidade de evidências | Processo liderado pela Fundação | Revisão de qualidade de dados, revisão de evidências, trilhas de auditoria e apoio a escalonamentos por participantes qualificados |
| Modelo de participação | Conselho da Fundação | Canais atuais de contribuição podem se expandir apenas com critérios de papéis, registros e salvaguardas documentados |
## Participação comunitária progressiva [#participação-comunitária-progressiva]
À medida que o ecossistema amadurece e a base de participantes cresce, a Fundação expandirá progressivamente os mecanismos de participação. Este é um caminho de participação, não uma afirmação de que o controle já saiu da Fundação. O objetivo é passar de contribuições estruturadas para responsabilidades definidas para contribuidores qualificados, sem reduzir a qualidade das evidências nem a auditabilidade.
Essa transição segue três fases:
### Engajamento [#engajamento]
Participação aberta e estruturada em discussões, feedback, revisão de documentação e alinhamento técnico. Os contribuidores constroem vocabulário compartilhado e standards de avaliação com a comunidade existente do ecossistema.
### Consultiva [#consultiva]
A comunidade produz análises técnicas estruturadas e recomendações que apoiam decisões de curadoria e ciclo de vida lideradas pela Fundação. Isso inclui identificação de lacunas de auditabilidade e recomendações para melhoria de estruturas de metodologia e aplicações de verificação.
### Deliberativa [#deliberativa]
Contribuidores qualificados podem assumir responsabilidades definidas de governança apenas quando os papéis, critérios de elegibilidade, registros e salvaguardas relevantes estiverem documentados. Esta fase deve ser introduzida somente com qualidade de evidências, auditabilidade e proteções de continuidade suficientes para preservar a confiança na rede.
Os critérios para níveis de participação e responsabilidades serão documentados antes de serem usados para governança.
## Salvaguardas de integridade [#salvaguardas-de-integridade]
Mesmo com o crescimento da participação comunitária, a Fundação Carrot mantém um papel de administração de último recurso para preservar a transparência, confiabilidade e continuidade dos processos. Isso inclui:
* Preservação e versionamento de registros de governança e metodologia para que mudanças possam ser revisadas
* Pacotes de evidências que permanecem intactos e consultáveis independentemente de quem toma a decisão
* Registros públicos de créditos e recompensas que permanecem revisáveis de forma independente
* Mecanismos de resposta a riscos de integridade
A evolução da governança e a integridade das evidências caminham juntas. Mudanças nos processos de tomada de decisão não reduzem a auditabilidade dos resultados — decisões, mudanças de metodologia e resultados de verificação permanecem explicáveis e auditáveis.
## Conformidade e auditabilidade [#conformidade-e-auditabilidade]
Independentemente da estrutura de governança, a Rede Carrot é projetada para tornar inspecionável a base dos resultados de crédito:
* O código de verificação ([MvA](/docs/standard/concepts/mva)) é de código aberto (LGPL-3.0) e publicamente inspecionável
* Registros públicos e finais, incluindo [MassIDs](/docs/protocol/mass-ids), [Certificados](/docs/protocol/certificates), créditos e recibos de aposentadoria, são registrados em infraestrutura blockchain pública
* A execução de regras e os resultados de verificação permanecem inspecionáveis por meio do [Carrot Registry](/docs/protocol/registry) e dos registros de evidências
* A garantia independente permanece disponível por meio da [verificação de terceiros](/docs/protocol/third-party-verification) de instalações, frameworks, evidências de dMRV e processos de garantia
A transparência não depende apenas da estrutura de governança atual — ela é incorporada à arquitetura do sistema.
O modelo de governança se apoia em duas camadas fundamentais:
* **[A Fundação](/docs/network/the-foundation)** — Missão, equipe fundadora e a estrutura do conselho que orienta as decisões do ecossistema.
* **[Segurança blockchain](/docs/protocol/smart-contracts)** — Como registros on-chain, imutabilidade e verificabilidade pública fornecem a infraestrutura que torna a governança auditável.
A governança define quem decide. Registros de governança e metodologia versionados apoiam a auditabilidade das decisões, enquanto registros públicos on-chain fornecem verificabilidade para registros da infraestrutura de créditos.
# A Rede
## Propósito [#propósito]
A Rede Carrot existe para um propósito declarado, definido no Deed da [Fundação Carrot](/docs/network/the-foundation): **construir a economia circular inclusiva e de baixo carbono**.
Decisões de governança, regras de protocolo e processos operacionais dentro da rede devem se alinhar a esse propósito. A rede não é um produto a ser otimizado para extração — é infraestrutura projetada para permanecer focada em sua missão ao longo do tempo.
É isso que torna a rede uma infraestrutura *pública* — governada para servir à missão, e não como um produto privado otimizado para extração. [Por que a Rede Carrot é infraestrutura pública digital →](/docs/network/digital-public-infrastructure)
## Responsabilidade incorporada ao desenho [#responsabilidade-incorporada-ao-desenho]
A Rede Carrot inclui uma camada de governança habilitada por tecnologia para sua infraestrutura de mercado compartilhada. Software determinístico do registry apoia registros duráveis de créditos — incluindo créditos de carbono e de reciclagem — e mecânicas de recompensa, enquanto a responsabilidade de governança vem da administração pela Fundação, de registros públicos, lógica de metodologia versionada, evidências de Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)), [garantia independente](/docs/protocol/third-party-verification) e rastreabilidade no [Carrot Registry](/docs/protocol/registry). A rede é projetada para reduzir o risco de abuso por meio de visibilidade, responsabilidade e regras compartilhadas.
## Por que isso é infraestrutura [#por-que-isso-é-infraestrutura]
A rede fornece trilhos de mercado compartilhados para mercados de créditos ambientais: regras de metodologia, registros de evidências, rastreabilidade de créditos, distribuição de recompensas e processos de governança que múltiplos participantes podem usar. Ela é projetada para coordenar um mercado, não para operar como um único projeto privado.
Esse papel de infraestrutura importa porque reciclagem e tratamento biológico envolvem muitos atores independentes ao longo da [cadeia de suprimentos](/docs/protocol/supply-chain). [Geradores de Resíduos](/docs/protocol/supply-chain), [Transportadores](/docs/protocol/supply-chain), [Processadores](/docs/protocol/supply-chain), [Recicladores](/docs/protocol/supply-chain), [Integradores](/docs/protocol/network-integrators), autores de [Methodology Verification Framework (MvF)](/docs/standard/concepts/mvf), desenvolvedores de [Methodology Verification Application (MvA)](/docs/standard/concepts/mva), auditores e compradores precisam de regras compartilhadas sobre como o trabalho ambiental é registrado, avaliado e recompensado.
## Por que uma fundação? [#por-que-uma-fundação]
Uma estrutura de fundação organiza a rede em torno de um propósito declarado, e não da propriedade por acionistas. Essa estrutura apoia a administração institucional do standard, do registro, da conformidade das metodologias e da continuidade operacional da rede à medida que ela cresce.
## Características de valor público [#características-de-valor-público]
Essa orientação de valor público vem de várias escolhas de design trabalhando em conjunto:
* **Administração pela Fundação** — a Fundação é organizada em torno da economia circular inclusiva e de baixo carbono e administra o standard, o registro, a conformidade das metodologias e a continuidade operacional.
* **Caminho de participação progressiva** — integradores, contribuidores de metodologia, auditores e participantes ativos da rede podem contribuir para a evolução da rede à medida que a governança amadurece.
* **Lógica de metodologia inspecionável** — frameworks de metodologia e aplicações definem como reivindicações são avaliadas e preservam as versões das regras por trás de cada resultado.
* **Evidências de dMRV** — a execução da metodologia cria registros de evidências que conectam o trabalho físico de economia circular à elegibilidade para créditos.
* **Garantia independente** — auditores terceiros e [Organismos de Validação/Verificação (VVBs)](/docs/glossary#vvb) revisam instalações, frameworks, evidências de dMRV e processos de garantia.
* **Registros públicos duráveis** — registros finais de créditos são mantidos em um registry público e imutável, podem ser verificados de forma independente por qualquer pessoa e reutilizados por sistemas interoperáveis.
* **Compartilhamento de recompensas** — os recursos das compras de créditos são distribuídos de acordo com políticas de recompensas publicadas para os papéis relevantes de cadeia de suprimentos e metodologia.
Juntas, essas características fazem da Rede Carrot uma [infraestrutura pública digital](/docs/network/digital-public-infrastructure) para a economia circular de baixo carbono e eficiente no uso de recursos.
## Partes interessadas e governança [#partes-interessadas-e-governança]
A rede reúne diversas partes interessadas — operadores de gestão de resíduos, recicladores, compradores de créditos, autores de metodologias, auditores e integradores de tecnologia — sob uma estrutura de governança compartilhada. A [Fundação Carrot](/docs/network/the-foundation) administra essa estrutura, governando a aprovação de metodologias, o desenvolvimento do protocolo, a conformidade operacional e a alocação de recursos.
À medida que o ecossistema amadurece, a Fundação expandirá progressivamente os mecanismos de participação, permitindo que contribuidores ativos tenham voz na evolução do protocolo. A responsabilidade da rede se estende à governança sobre protocolos específicos de domínio, começando pelo [Protocolo da Economia Circular](/docs/protocol).
## Por que o registry é construído dessa forma [#por-que-o-registry-é-construído-dessa-forma]
Os registros finais do registry são ancorados em infraestrutura blockchain pública porque isso lhes dá durabilidade, verificação independente, auditabilidade e interoperabilidade. Essa infraestrutura não é a fonte da autoridade de governança: regras de metodologia, revisão independente e processos de governança liderados pela Fundação continuam sendo a autoridade sobre o que se qualifica.
## Saiba mais [#saiba-mais]
Por que a Rede Carrot é infraestrutura pública digital — e como ela é governada para o bem comum
Como decisões são tomadas dentro da Rede Carrot
O papel, a estrutura e o propósito da Fundação Carrot
O argumento completo: formação de mercado, teste de governança pública, financiamento e
salvaguardas
# A Fundação
## A Fundação Carrot [#a-fundação-carrot]
A Fundação Carrot é a guardiã da Rede Carrot — responsável pelo desenvolvimento do [standard](/docs/standard) e do [registry](/docs/registry), pela conformidade das metodologias e pela continuidade operacional da rede.
A Fundação é governada por um Conselho que orienta a direção estratégica e garante que o ecossistema evolua de forma responsável e auditável. À medida que a rede cresce, a participação será progressivamente expandida por meio do caminho de [participação comunitária progressiva](/docs/network/governance#progressive-community-participation) descrito na página de governança.
Essa administração vinculada ao propósito faz parte do que torna a Rede Carrot [infraestrutura pública digital](/docs/network/digital-public-infrastructure), e não uma plataforma privada.
## Missão [#missão]
Acelerar a transição para uma economia circular eficiente em recursos, de baixo carbono e inclusiva.
## Visão [#visão]
Acreditamos que um futuro circular e de baixo carbono só pode ser alcançado por meio da colaboração, apoiada por incentivos compartilhados e sistemas transparentes. A meta da Fundação é ajudar a escalar as taxas globais de reciclagem de menos de 18% para mais de 90% até 2040.
## Forma jurídica e propósito [#forma-jurídica-e-propósito]
A Carrot Fndn é uma fundação suíça nos termos do Artigo 80 e seguintes do Código Civil Suíço, com sede registrada em Zug, Suíça. Ela foi constituída em outubro de 2023 e está listada no registro comercial suíço sob o UID `CHE-152.448.302` e o número de Handelsregister `CH-170.7.001.078-2`.
| Campo | Registro público |
| ------------------------- | ----------------------------------------------------------------------------------------------------------- |
| Forma jurídica | Fundação suíça |
| Sede registrada | Zug, Suíça |
| Constituição | Outubro de 2023 |
| UID | `CHE-152.448.302` |
| Número de Handelsregister | `CH-170.7.001.078-2` |
| Supervisão | Supervisão federal de fundações na Suíça; registros públicos listam `Eidg. Departement des Innern, in Bern` |
Em linguagem simples, o propósito público da Fundação é desenvolver e apoiar arquiteturas de software abertas que nenhuma parte controla sozinha, o Carrot Protocol e aplicações que usam o protocolo para apoiar uma gestão de recursos mais sustentável.
O registro público apresenta o propósito formal da Fundação em alemão:
> Der Zweck der Stiftung ist die Entwicklung und Förderung von neuen Technologien und Applikationen, insbesondere in den Bereichen von neuen offenen und dezentralisierten Softwarearchitekturen. Im Vordergrund - aber nicht ausschliesslich - steht dabei die Entwicklung und Förderung des so genannten Carrot Protokolls und der entsprechenden Technologien, sowie die Förderung und Unterstützung von Applikationen unter Anwendung des Carrot Protokolls. Mit der Entwicklung und der Förderung des Carrot Protokoll strebt die Stiftung neben anderen Teilbereichen die Förderung der Nachhaltigkeit der Gesellschaft im Umgang mit den natürlichen Ressourcen an, insbesondere durch eine bessere Ressourcenverwaltung, um die natürlichen Ressourcen zu erhalten, deren Nutzung zu optimieren und Abfall und Verschmutzung zu reduzieren.
Este é o texto original do registro público; não é uma tradução jurídica oficial.
A supervisão federal de fundações é administrada pela Eidgenössische Stiftungsaufsicht (ESA) / Federal Supervisory Authority for Foundations, vinculada à Secretaria-Geral do Federal Department of Home Affairs.
Essa forma jurídica importa porque a Fundação é organizada em torno de um propósito declarado, não da propriedade por acionistas. Seu papel é administrar o standard, o registro, a conformidade das metodologias e a continuidade operacional da rede em serviço desse propósito.
Referências públicas de registro e supervisão: [Moneyhouse](https://www.moneyhouse.ch/de/company/carrot-fndn-13252793071), [Wirtschaftsregister](https://www.wirtschaftsregister.ch/uid.cfm?firma=Carrot-Fndn\&id=CHE-152.448.302) e [ESA](https://www.esa.admin.ch/).
## Membros do Conselho [#membros-do-conselho]
**[Ian McKee](https://www.linkedin.com/in/ianmckee10/) — Fundador e Presidente**
Anteriormente no Goldman Sachs Sales & Trading, fundador de três empresas de tecnologia com mais de 15 anos em sustentabilidade. Consultor de tecnologia da Zero Waste International Alliance e Accredited Professional em TRUE Zero Waste & LEED Certification.
**[Marcelo Doria](https://www.linkedin.com/in/marcelodoria/) — Fundador e Vice-Presidente**
Empreendedor serial com experiência em produção de mídia, negócios esportivos, publicidade e big data. Construiu sua primeira empresa na faculdade. Trouxe os Global X-Games para o Brasil e venceu o prêmio de melhor filme no Rio.
**[Silvan Andermatt](https://www.linkedin.com/in/silvanandermatt/) — Membro do Conselho**
Empreendedor serial e consultor de empresas de blockchain e FinTech. Especialista em gestão de fundações suíças com paixão por sustentabilidade. Mestre em Direito e MBA com estudos avançados em Blockchain e FinTech.
## Comitês consultivos [#comitês-consultivos]
A Fundação convoca comitês consultivos em cinco áreas-chave para orientar o desenvolvimento do ecossistema:
* **Pessoas e Governança** — Inclusão, equidade, construção e engajamento comunitário
* **Meio Ambiente** — Gestão de recursos em ciclo fechado, saúde dos ecossistemas, redução de GEE
* **Economia e Finanças** — ESG, EPR, gestão de capital, modelos de negócios emergentes
* **Jurídico** — Direito ambiental, commodities, advocacia política
* **Tecnologia** — Segurança, IA, IoT, blockchain
Para a lista atual de conselheiros, visite [carrot.eco](https://www.carrot.eco/).
# Papéis no Ecossistema de Créditos
[Créditos ambientais](/docs/protocol/credits) dependem de vários papéis distintos. Alguns definem
as regras, alguns executam o trabalho físico, alguns transformam dados operacionais em evidências
auditáveis, alguns fornecem garantia independente, e alguns emitem, compram ou aposentam créditos.
Esta página mapeia esses papéis no sistema de créditos da Carrot. Ela é um guia de orientação: cada
papel aponta para a página onde o tema é explicado em profundidade.
Uma organização pode assumir mais de um papel. Por exemplo, a Carrot pode atuar como
[standard](/docs/standard), operar infraestrutura de [registry](/docs/registry) e fornecer
infraestrutura de Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)), seja para créditos de reciclagem ou de
carbono, dependendo do contexto da metodologia. A garantia independente deve permanecer separada:
[organismos de validação e verificação (VVBs)](/docs/glossary#vvb) e auditores independentes não são
substituídos pela infraestrutura da Carrot.
## Os principais papéis [#os-principais-papéis]
| Papel | O que faz | Saiba mais |
| ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------- |
| Standard | Governa as regras, o ciclo de vida das metodologias e os requisitos de integridade que os créditos devem seguir. | [O Standard](/docs/standard) |
| Metodologia | Define a base científica para medir uma alegação ambiental específica. | [Metodologias](/docs/methodologies) |
| Responsável pelo Programa | Lidera o desenvolvimento de um programa de créditos e coordena metodologia, MvF, MvA e proposta de política de recompensas. | [Responsável pelo Programa](#program-owner) |
| Methodology Verification Framework (MvF) | Transforma uma metodologia em regras operacionais, requisitos de evidência, fórmulas e critérios verificáveis. | [MvF](/docs/standard/concepts/mvf) |
| Methodology Verification Application (MvA) | Implementa as regras do MvF como software determinístico que avalia os dados enviados. | [MvA](/docs/standard/concepts/mva) |
| dMRV | Executa regras de metodologia contra dados reais da cadeia de suprimentos e produz evidência digital auditável. | [dMRV](/docs/protocol/dmrv) |
| Infraestrutura da Carrot | Orquestra a execução do dMRV, registra evidências, gerencia a infraestrutura do ciclo de vida dos créditos e expõe visualizações públicas. | [Arquitetura da Plataforma](/docs/protocol/platform-architecture) |
| VVB ou auditor independente | Fornece garantia externa e revisão de fidelidade metodológica, acreditação de instalações ou pacotes de evidências. | [Verificação de Terceiros](/docs/protocol/third-party-verification) |
| Registry | Emite, rastreia e aposenta créditos com registros públicos que evitam dupla contagem. | [Registry](/docs/registry) |
| Desenvolvedor de Rede | Fomenta projetos de créditos e rastreabilidade ao integrar participantes e coordenar a homologação. | [Desenvolvedor de Rede](#network-developer) |
| Integrador | Conecta sistemas operacionais à Carrot enviando dados da cadeia de suprimentos pela API. | [Integradores](/docs/protocol/network-integrators) |
| Gestor de Resíduos | Coordena a destinação dos resíduos para um Gerador de Resíduos sem assumir a custódia física do material. | [Cadeia de Suprimentos](/docs/protocol/supply-chain#waste-manager) |
| Participantes da cadeia de suprimentos | Executam o trabalho físico: geração, coleta, transporte, processamento ou reciclagem de material. | [Cadeia de Suprimentos](/docs/protocol/supply-chain) |
| Comprador de créditos | Compra e aposenta créditos para reivindicar impacto ambiental verificado. | [Compra de Créditos](/docs/protocol/credit-purchase) |
## Como os papéis se conectam [#como-os-papéis-se-conectam]
Os papéis se conectam em uma sequência que vai da definição de regras à aposentadoria de créditos:
1. Um **standard** governa os requisitos de integridade dos créditos.
2. Uma **metodologia** define como um benefício ambiental específico é medido.
3. Um **Responsável pelo Programa** coordena a construção de um programa de créditos; a governança mantém a autoridade de aprovação.
4. A metodologia é traduzida em um **MvF** e implementada como uma **MvA**.
5. Um **Desenvolvedor de Rede** pode integrar participantes ao programa e coordenar a homologação.
6. [**Gestores de Resíduos**](/docs/protocol/supply-chain#waste-manager) coordenam decisões de destinação, enquanto participantes físicos manuseiam o material.
7. **Integradores** enviam dados da cadeia de suprimentos a partir de operações físicas.
8. O **dMRV** executa regras de metodologia contra esses dados e produz evidência auditável.
9. **VVBs e auditores independentes** fornecem garantia externa quando necessário.
10. Resultados verificados se tornam [certificados](/docs/protocol/certificates) e [créditos](/docs/protocol/credits).
11. O **registry** emite, rastreia e aposenta créditos.
12. **Compradores de créditos** compram e aposentam créditos.
13. Os recursos retornam aos participantes verificados por meio da [distribuição de recompensas](/docs/protocol/rewards-distribution).
## Responsável pelo Programa [#responsável-pelo-programa]
O **Responsável pelo Programa** lidera o desenvolvimento de um programa de créditos com a Carrot.
Ele avalia o mercado-alvo, coordena a metodologia, o Methodology Verification Framework (MvF) e a
Methodology Verification Application (MvA), e propõe uma política de recompensas específica para o
programa dentro dos requisitos do Carrot dMRV Standard.
O papel coordena a construção, mas não aprova o próprio programa. A aprovação da metodologia, do
framework e da aplicação permanece com a Comunidade de Especialistas e os processos de governança
da Carrot. O Responsável pelo Programa não detém os créditos do programa e nunca recebe recompensas
do protocolo. Serviços comerciais separados são regidos por contrato, fora da distribuição do
protocolo.
## Desenvolvedor de Rede [#desenvolvedor-de-rede]
O **Desenvolvedor de Rede** fomenta projetos de créditos e rastreabilidade ao prospectar
participantes para a Rede Carrot e programas de créditos específicos. Ele coordena o processo de
homologação definido pelo framework de metodologia aplicável e envia dados e documentos
comprobatórios à Carrot.
O Desenvolvedor de Rede não aprova participantes. Quando houver exigência de garantia de terceira
parte, os participantes ainda precisam contratar um auditor independente; o Desenvolvedor de Rede
coordena o processo, mas não substitui essa garantia. Como envia dados de terceiros, responde pela
qualidade e exatidão das informações enviadas e está sujeito às
[regras de self-policing](/docs/standard/policies/rewards-distribution).
Um Desenvolvedor de Rede pode assumir outros papéis do ecossistema quando não houver conflito de
interesses. Ele nunca recebe recompensas do protocolo; qualquer remuneração por seus serviços é
contratual e fica fora da distribuição de recompensas.
## Onde a Carrot se encaixa [#onde-a-carrot-se-encaixa]
A Carrot pode assumir diferentes papéis dependendo do contexto da metodologia.
Para [BOLD Recycling](/docs/methodologies/bold-recycling), a Carrot atua como standard porque não há
um standard global estabelecido para créditos de reciclagem que cubra esse caso de uso. A Carrot
governa o ciclo de vida da metodologia e os requisitos de integridade dos créditos emitidos sob essa
metodologia.
Para metodologias de carbono como [AMS-III.F](/docs/methodologies/ams-iii-f) e [BOLD Carbon
(CH₄)](/docs/methodologies/ams-iii-f/bold-carbon), a base científica referencia um standard externo.
Nesse contexto, a Carrot fornece infraestrutura de dMRV e funções de registry enquanto o framework
da metodologia referencia o standard externo.
Em toda a rede, a Carrot fornece infraestrutura que registra evidências, executa regras de
metodologia e torna os resultados publicamente verificáveis.
## O que permanece independente [#o-que-permanece-independente]
A infraestrutura da Carrot não substitui a garantia independente. VVBs e auditores independentes
fornecem revisão externa de acordo com o escopo de governança aplicável.
A garantia independente pode cobrir fidelidade metodológica, auditorias de instalações, acreditação
de participantes e pacotes de evidências. A infraestrutura de dMRV da Carrot produz a evidência
digital que torna essa revisão mais contínua, escalável e auditável.
## Analogias do dia a dia [#analogias-do-dia-a-dia]
Essas analogias são imperfeitas, mas ajudam a separar os papéis:
| Papel | Analogia |
| --------------------------- | ------------------------------------------------------------------------------------- |
| Metodologia | Uma receita para medir impacto ambiental |
| dMRV | Um fluxo de evidências digitais que verifica se a receita foi seguida |
| VVB ou auditor independente | Garantia independente que revisa o método, as evidências ou as condições operacionais |
| Registry | O registro público que impede que o mesmo crédito seja reivindicado duas vezes |
## Para onde ir a seguir [#para-onde-ir-a-seguir]
* [Como Funciona](/docs/protocol/how-it-works) — Fluxo completo do trabalho físico aos créditos
* [Arquitetura da Plataforma](/docs/protocol/platform-architecture) — Arquitetura do sistema para verificação e emissão de créditos
* [O Standard](/docs/standard) — Como a Carrot governa a qualidade das metodologias
* [Registry](/docs/registry) — Como créditos são emitidos, rastreados e aposentados
* [Verificação de Terceiros](/docs/protocol/third-party-verification) — O que VVBs e auditores fazem
* [Ecossistema de Metodologias](/docs/standard/concepts/ecosystem) — Como metodologias se tornam verificação executável
* [Compra de Créditos](/docs/protocol/credit-purchase) — Como compradores de créditos compram créditos
* [Aposentadoria de Créditos](/docs/protocol/credit-retirement) — Como compradores reivindicam impacto verificado
# Como Funciona
Se você está chegando agora aos mercados de créditos ambientais — incluindo créditos de carbono e
de reciclagem —, comece por [Papéis no Ecossistema de
Créditos](/docs/protocol/credit-ecosystem-roles) para entender como padrões, metodologias, MRV
digital ([dMRV](/docs/protocol/dmrv)), registry, VVBs, compradores e participantes da cadeia de
suprimentos se conectam.
## A cadeia de suprimentos da reciclagem [#a-cadeia-de-suprimentos-da-reciclagem]
Os [Integradores](/docs/protocol/network-integrators) digitalizam a cadeia de suprimentos da reciclagem ao conectar suas operações à Rede Carrot — capturando o caminho que os materiais percorrem desde a geração de resíduos, passando pela coleta, triagem, transporte e processamento em instalações de reciclagem ou [tratamento biológico](/docs/glossary#biological-treatment) homologadas. Em cada etapa, o trabalho físico realizado pelos participantes é registrado digitalmente, criando uma cadeia de custódia verificável.
Entender como funciona a logística de resíduos é essencial para compreender como Carrot gera valor. Separar e limpar resíduos misturados após a contaminação é caro demais e tecnicamente complexo para a maioria dos locais. A reciclagem de alto desempenho exige chegar à **origem** da geração de resíduos — o [Gerador de Resíduos](/docs/protocol/supply-chain) — porque a triagem adequada deve acontecer antes da coleta dos materiais, não depois.
[Mergulhe na cadeia de suprimentos da reciclagem](/docs/protocol/supply-chain)
## De resíduo a ativo digital [#de-resíduo-a-ativo-digital]
Quando os materiais residuais são coletados e triados, eles são codificados em [MassIDs](/docs/protocol/mass-ids) — registros digitais que capturam tipo de material, peso e cadeia de custódia. Os MassIDs acompanham o material físico ao longo da cadeia de suprimentos, criando um gêmeo digital que rastreia cada transferência e transformação.
Cada MassID registra a cadeia de custódia completa — construída a partir dos dados enviados pelos [Integradores](/docs/protocol/network-integrators) — permitindo rastreabilidade de ponta a ponta desde a geração do resíduo até o processamento final.
## Verificando o impacto ambiental [#verificando-o-impacto-ambiental]
Quando os MassIDs chegam a uma instalação de reciclagem ou tratamento biológico homologada, eles entram no processo de dMRV, onde os MvAs (Methodology Verification Agents) executam automaticamente as regras de validação da metodologia. Separadamente, auditores terceirizados homologam as instalações de reciclagem e tratamento biológico, enquanto a Carrot Foundation exerce a supervisão no nível do ecossistema — garantindo conjuntamente que o trabalho ambiental declarado foi de fato realizado.
Esta etapa de verificação é o que separa Carrot dos sistemas tradicionais baseados em comprovantes. Em vez de depender de recibos em papel que podem ser duplicados e manipulados, o processo de dMRV executa regras específicas de [metodologia](/docs/methodologies) contra resultados físicos, produzindo resultados verificáveis e auditáveis.
## Gerando créditos ambientais [#gerando-créditos-ambientais]
MassIDs que passam pela verificação da metodologia geram [Certificados](/docs/protocol/certificates) — registros digitais únicos que representam um resultado ambiental verificado específico:
* **[GasID](/docs/protocol/certificates#gasid)** — Representa reduções de emissões de gases de efeito estufa (ex.: reduções de metano alcançadas pelo tratamento biológico de resíduos orgânicos em vez de envio a aterros)
* **[RecycledID](/docs/protocol/certificates#recycledid)** — Representa material reciclado certificado, processado em uma instalação homologada
Certificados, por sua vez, respaldam a emissão de créditos: [Tokenized Carbon Credits (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc) e [Tokenized Recycling Credits (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc). Os créditos são padronizados dentro da classe de material ou metodologia aplicável, tornando-os commodities negociáveis.
[Explore o ciclo de vida dos créditos](/docs/protocol/credit-lifecycle)
## Criando um mercado para créditos [#criando-um-mercado-para-créditos]
Créditos tornam-se ativos negociáveis em um mercado transparente e público. Organizações e indivíduos compram e aposentam créditos para cumprir mandatos de [Responsabilidade Estendida do Produtor (EPR)](/docs/protocol/the-solution#epr) e metas ESG.
Os créditos são adquiridos por meio de interfaces Carrot que gerenciam precificação e liquidação — substituindo os mercados de balcão opacos e repletos de intermediários onde a maioria dos créditos ambientais é atualmente negociada. A plataforma estabelece preços para cada tipo de crédito (ex.: 1 tonelada de resíduo orgânico desviado) e oferece um mercado transparente acessível a organizações de qualquer porte, com tipos de crédito adicionais esperados à medida que novas metodologias são lançadas.
[Saiba mais sobre a compra de créditos](/docs/protocol/credit-purchase)
## Distribuindo recompensas [#distribuindo-recompensas]
Os recursos das compras de créditos são distribuídos diretamente aos participantes verificados na cadeia de suprimentos da reciclagem por meio de um processo automatizado e baseado em regras. A distribuição segue a [Política de Distribuição de Recompensas](/docs/standard/policies/rewards-distribution), garantindo que o valor chegue a cada participante que contribuiu para o resultado ambiental — desde os geradores de resíduos que fizeram a triagem corretamente, até transportadores e processadores.
Isso cria um ciclo de incentivos autorreforçante:
1. Geradores de resíduos são recompensados pela triagem, cobrindo seus custos e incentivando a participação contínua
2. [Recicladores](/docs/protocol/supply-chain#o-papel-do-reciclador), [Transportadores](/docs/protocol/supply-chain) e [Processadores](/docs/protocol/supply-chain) recebem novas fontes de receita, permitindo investir na expansão das operações
3. Não participantes são atraídos para o ecossistema por meio de incentivos (Recycle-to-Earn)
[Leia sobre a distribuição de recompensas](/docs/protocol/rewards-distribution)
## Como o ecossistema cresce [#como-o-ecossistema-cresce]
A Rede Carrot cresce por meio dos [Integradores](/docs/protocol/network-integrators) — provedores locais de gestão de resíduos e logística que conectam suas operações existentes à Rede Carrot. Ao se integrar com Carrot, esses provedores ganham acesso a uma nova fonte de receita proveniente de créditos ambientais, incentivando-os a integrar toda a sua base de clientes de reciclagem.
O primeiro caso de uso do ecossistema — tratamento biológico de resíduos orgânicos sob [BOLD Recycling](/docs/methodologies/bold-recycling) e [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) (BOLD: Breakthrough in Organics Landfill Diversion) — foi escolhido porque os resíduos orgânicos representam aproximadamente 50% do volume global de resíduos e quase todos acabam em aterros sanitários. Desviar resíduos orgânicos para tratamento biológico gera tanto créditos de carbono (prevenção de metano) quanto créditos de reciclagem, além de remover a contaminação por alimentos que degrada a qualidade de outros materiais recicláveis.
A partir deste caso de uso inicial, o ecossistema se expande introduzindo novas [metodologias](/docs/methodologies) para fluxos de resíduos adicionais e crescendo geograficamente à medida que mais Integradores se juntam em novos mercados.
***
Entenda como comprar créditos e quais evidências você recebe nos guias de [compra de
créditos](/docs/protocol/credit-purchase) e [aposentadoria de
créditos](/docs/protocol/credit-retirement).
# Protocolo da Economia Circular
## O que é o Protocolo da Economia Circular? [#o-que-é-o-protocolo-da-economia-circular]
O Protocolo da Economia Circular é o conjunto de regras tecnológicas e financeiras que coordena a atividade de economia circular na Rede Carrot. Ele conecta dados da cadeia de suprimentos, registros de cadeia de custódia, certificados, créditos rastreáveis, aposentadoria, recompensas e liquidação em um fluxo auditável.
No centro do protocolo está a padronização de como o trabalho real de economia circular se transforma em evidência digital rastreável. Movimentos de resíduos são registrados como MassIDs, resultados verificados se tornam certificados RecycledID ou GasID, e esses certificados lastreiam Tokenized Recycling Credits (TRC) ou Tokenized Carbon Credits (TCC). O mesmo fluxo do protocolo também governa como os créditos são comprados, aposentados e conectados à liquidação e à distribuição de recompensas.
Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)) é o processo de execução e evidência dentro desse protocolo mais amplo, abrangendo desde reciclagem até créditos de carbono. Ele executa os critérios de frameworks de metodologia aprovados contra dados da cadeia de suprimentos e registra a evidência que verificadores independentes, compradores, auditores e o público podem revisar.
## O que é coberto nesta seção [#o-que-é-coberto-nesta-seção]
Por que a economia linear de extrair-fabricar-descartar falha e o que precisa mudar
Como a Carrot transforma reciclagem verificada em ativos ambientais negociáveis
O fluxo completo da coleta de resíduos à emissão de créditos
Quem faz o quê entre padrões, metodologias, dMRV, registry, VVBs, compradores e participantes da
cadeia de suprimentos
Fluxo operacional ponta a ponta dos dados da cadeia de suprimentos à emissão e aposentadoria de
créditos
Como terceiros revisam conformidade metodológica, evidência de dMRV e integridade dos créditos
dMRV, MassIDs, execução de metodologia e a cadeia de suprimentos da reciclagem
MassIDs, certificados, ciclo de vida dos créditos, emissão, compra e aposentadoria
Como o Registry executa e registra transações e como interopera com outros sistemas
# Arquitetura da Plataforma
## Como a Rede Carrot funciona [#como-a-rede-carrot-funciona]
Esta página oferece a visão operacional ponta a ponta da Rede Carrot. Ela mostra como dados da cadeia de suprimentos se tornam evidência auditável, como critérios de frameworks de metodologia aprovados produzem resultados verificados e como esses resultados passam por emissão de certificados, emissão de créditos, compra, distribuição de recompensas e aposentadoria.
Esta página é um mapa de orientação. Ela não define o Protocolo da Economia Circular sozinha: a página [Protocolo da Economia Circular](/docs/protocol) explica as regras específicas da economia circular — incluindo créditos de reciclagem e de carbono —, Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)) explica execução e evidência, e [Registry](/docs/registry) explica emissão de créditos, compra, aposentadoria, contas de custódia e registros de liquidação.
Para um mapa não técnico das organizações e papéis por trás desta arquitetura, veja [Papéis no
Ecossistema de Créditos](/docs/protocol/credit-ecosystem-roles).
## Visão geral [#visão-geral]
### 1. Captura de dados da cadeia de suprimentos [#1-captura-de-dados-da-cadeia-de-suprimentos]
Os [Integradores](/docs/protocol/network-integrators) digitalizam as operações de gestão de resíduos, capturando tipo de material, peso e cadeia de custódia em cada transferência. Esses dados entram na plataforma via [Carrot API](/docs/integrations/api), criando um registro digital do trabalho físico realizado ao longo da [cadeia de suprimentos da reciclagem](/docs/protocol/supply-chain).
### 2. Criação de MassID [#2-criação-de-massid]
Os dados da cadeia de suprimentos são codificados em [MassIDs](/docs/protocol/mass-ids) — as unidades de dados fundamentais do ecossistema. Cada MassID registra tipo de material, peso e a cadeia de custódia completa, desde a origem do resíduo até a instalação de reciclagem. À medida que os materiais percorrem a cadeia de suprimentos, os MassIDs são criados e atualizados, construindo o registro de Proof-of-Physical-Work e Proof-of-Provenance que a execução da metodologia verificará posteriormente.
### 3. Execução da metodologia [#3-execução-da-metodologia]
A plataforma processa os MassIDs por meio do seu pipeline de dMRV — verificando conformidade com standards científicos, avaliando condições e produzindo resultados verificados. Cada metodologia é implementada como um [Methodology Verification Framework (MvF)](/docs/standard/concepts/mvf) que define as regras, e um [Methodology Verification Application (MvA)](/docs/standard/concepts/mva) que automatiza sua execução. Quando um MassID passa pela verificação da metodologia, ele é marcado como elegível para registro no registry público de créditos.
[Saiba mais sobre a execução da metodologia](/docs/protocol/methodology-execution)
### 4. Registro no Registry [#4-registro-no-registry]
Cada MassID verificado é registrado no registry público de créditos — os metadados são construídos, enviados a uma infraestrutura pública independente ([IPFS](https://ipfs.tech/)), e uma entrada única é criada no Registry: um registro publicamente verificável do lote de resíduos. As entradas podem ser revogadas mais tarde se os dados subjacentes se mostrarem incorretos; a revogação é ela mesma registrada no registry público de créditos (veja [Revogação](/docs/protocol/smart-contracts/on-chain-flows#revogação)).
[Saiba como os registros do Registry são criados](/docs/protocol/on-chain-minting)
### 5. Emissão de certificados [#5-emissão-de-certificados]
Quando um MassID passa pela verificação da metodologia sob uma metodologia específica em uma instalação credenciada, [certificados](/docs/protocol/certificates) ([GasID](/docs/protocol/certificates#gasid) ou [RecycledID](/docs/protocol/certificates#recycledid)) são emitidos. Os certificados vinculam resultados ambientais verificados — material reciclado ou reduções de emissões de gases de efeito estufa — ao MassID subjacente que comprova que o trabalho físico foi realizado.
### 6. Geração de créditos [#6-geração-de-créditos]
Os certificados geram [Tokenized Recycling Credits (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc) e [Tokenized Carbon Credits (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc), cuja unidade é definida pela metodologia aplicável. A metodologia [BOLD Recycling](/docs/methodologies/bold-recycling) emite TRCs `C-BIOW` em toneladas métricas de material reciclado certificado; a metodologia [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) emite TCCs `C-CARB.CH4` em toneladas métricas de reduções de CO₂e. Os créditos são intercambiáveis apenas dentro da classe e do símbolo de metodologia aplicáveis. Outras metodologias podem emitir símbolos de crédito diferentes. Os créditos usam um formato de implementação aberto e amplamente compatível, projetado para atividade de mercado: compra, custódia e aposentadoria.
### 7. Compra de créditos [#7-compra-de-créditos]
Compradores (organizações ou indivíduos) [compram créditos](/docs/protocol/credit-purchase) por meio de interfaces Carrot — por exemplo, a [Loja Carrot](https://store.carrot.eco) para indivíduos, ou interfaces fornecidas por Carrot para organizações. As compras são liquidadas diretamente no registry público de créditos em moeda digital rastreável (USDC); todas as etapas são concluídas em uma única transação ou nenhuma delas é.
### 8. Distribuição de recompensas [#8-distribuição-de-recompensas]
Os recursos das compras de créditos são [distribuídos](/docs/protocol/rewards-distribution) a todos os participantes da cadeia de suprimentos da reciclagem, proporcionalmente à sua contribuição verificada. Esse modelo Recycle-to-Earn garante que [Geradores de Resíduos](/docs/protocol/supply-chain), [Custodiantes de Ponto de Coleta](/docs/protocol/supply-chain), [Transportadores](/docs/protocol/supply-chain), [Processadores](/docs/protocol/supply-chain), [Recicladores](/docs/protocol/supply-chain#o-papel-do-reciclador) e Integradores sejam todos recompensados pelo trabalho ambiental que realizam.
### 9. Aposentadoria de créditos [#9-aposentadoria-de-créditos]
Os créditos comprados são [aposentados](/docs/protocol/credit-retirement) para reivindicar permanentemente o benefício ambiental que representam. A aposentadoria remove permanentemente os créditos de circulação no registry público de créditos e cria um Recibo de Aposentadoria de Crédito intransferível como prova permanente. Os créditos podem ser aposentados de forma independente a qualquer momento após a compra, desde que estejam de volta à custódia do [Vault](/docs/protocol/smart-contracts), ou por meio de aposentadoria integrada (comprados e aposentados em uma única transação atômica).
## Verificabilidade pública [#verificabilidade-pública]
Toda a atividade do Registry — desde o registro do MassID até a aposentadoria de créditos — é gravada no registry público de créditos imutável como transações executadas por software determinístico. Esses dados são publicamente verificáveis e acessíveis por qualquer pessoa e qualquer plataforma: auditores, reguladores, indexadores e aplicações de terceiros podem ler e verificar diretamente no Registry, sem depender da infraestrutura da Carrot. Esse design possibilita **interoperabilidade** (outros sistemas podem construir sobre os mesmos dados) e **transparência e confiança** independentes da disponibilidade da Carrot.
O [Carrot Registry](/docs/protocol/registry) oferece uma visualização amigável e focada no domínio dos dados do registry público de créditos, além de dados da plataforma (definições de metodologia, execução de regras, homologações). Para verificação independente da infraestrutura apenas dos dados do Registry, qualquer explorador público de blockchain (ex.: [PolygonScan](https://polygonscan.com/)) fornece acesso direto a transações brutas e logs de eventos. Consulte [Interoperabilidade](/docs/protocol/interoperability) para saber como sistemas externos podem monitorar, indexar e verificar dados da Carrot.
## Tópicos aprofundados [#tópicos-aprofundados]
* [Ciclo de Vida dos Créditos](/docs/protocol/credit-lifecycle) — O ciclo de vida e as relações entre MassID, Certificado e Crédito
* [Contratos Inteligentes](/docs/protocol/smart-contracts) — O software automatizado do registry que executa transações da rede
* [dMRV](/docs/protocol/dmrv) — Execução e evidência dos critérios de frameworks de metodologia
* [Cadeia de Suprimentos](/docs/protocol/supply-chain) — Papéis dos participantes, fluxos logísticos e o modelo de validação
* [Carrot Registry](/docs/protocol/registry) — A interface pública de verificação e os exploradores de blockchain públicos independentes que verificam os dados públicos do ledger sem depender dela
### Diagram: platform-architecture-flow
Este fluxo de arquitetura da plataforma mostra como dados capturados se transformam em crédito aposentado por meio da criação de MassID, execução da metodologia, emissão de certificados e créditos, compra e aposentadoria. O ramo de recompensas mostra o valor da compra retornando à cadeia, ao Integrador de Rede, à metodologia e à Carrot Network, unindo operação e distribuição de incentivos.
# O Problema
## A economia linear está falhando [#a-economia-linear-está-falhando]
Mais de 80% de tudo que é produzido e consumido pela humanidade acaba como poluente — enterrado em aterros sanitários, despejado em corpos d'água ou queimado na atmosfera. O modelo extrair-produzir-descartar, conhecido como economia linear, transfere os custos ambientais da produção de resíduos para os bens comuns e distribui os custos de descarte uniformemente entre os contribuintes, não oferecendo nenhum incentivo para reduzir, separar, reutilizar ou reciclar.
Os números são alarmantes:
* O mundo gera mais de **2 bilhões de toneladas** de resíduos sólidos urbanos anualmente, com previsão de alcançar **3,4 bilhões de toneladas até 2050** ([World Bank, What a Waste 2.0](https://datatopics.worldbank.org/what-a-waste/)).
* **33%** dos resíduos globais são descartados a céu aberto. Apenas **19%** são recuperados por meio de reciclagem ou tratamento biológico.
* Toxinas e material particulado provenientes de aterros e resíduos queimados estão associados a doenças respiratórias e câncer.
* O chorume drena para corpos d'água, contaminando solo e aquíferos.
À medida que o PIB global cresce, cresce também a geração de resíduos per capita — e os países em desenvolvimento experimentam os maiores aumentos na geração de resíduos em relação ao crescimento da renda.
## A escassez de recursos agrava a crise [#a-escassez-de-recursos-agrava-a-crise]
O uso global de recursos mais que triplicou desde 1970. Os preços das commodities começaram a superar o crescimento econômico, sinalizando escassez crescente. Sem uma mudança para reutilização e reciclagem, as cadeias de suprimentos enfrentam riscos crescentes devido à disponibilidade limitada de matérias-primas.
Um caminho sustentável requer desacoplar o crescimento econômico do consumo de recursos virgens — mantendo os materiais existentes na economia pelo maior tempo possível e fazendo a transição para materiais regenerativos onde viável.
## As soluções existentes não estão escalando [#as-soluções-existentes-não-estão-escalando]
Aterros sanitários, incineração, infraestrutura de tratamento biológico, programas de responsabilidade do produtor e mercados de carbono tentaram resolver a crise dos resíduos — mas nenhum alcançou a escala ou a confiança necessárias para uma mudança sistêmica.
Aterros sanitários e incineração com recuperação energética (WtE) sustentam o modelo de economia linear. Os aterros emitem metano — um gás de efeito estufa com [27 vezes o potencial de aquecimento do CO₂](https://www.ipcc.ch/assessment-report/ar6/) — e mesmo os melhores sistemas de captura de metano eliminam no máximo 50% das emissões. A incineração produz energia de forma ineficiente, transferindo a poluição do solo para a atmosfera, e ambas as abordagens eliminam o incentivo para a separação na fonte.
Contratos municipais de longo prazo com operadores de aterros e incineração perpetuam soluções caras e de baixo desempenho, restringindo a inovação em reciclagem e tratamento biológico.
O tratamento biológico de resíduos orgânicos — incluindo compostagem, digestão anaeróbia, processamento por larvas black soldier fly e processamento microbiano — elimina quase todas as emissões de metano ao processar o material em condições controladas. Esses métodos produzem produtos ricos em nutrientes que restauram o solo, reduzem a necessidade de fertilizantes intensivos em carbono e potencializam a captura de carbono por meio do crescimento vegetal. Estima-se que para cada tonelada de resíduo orgânico tratado biologicamente, **1,0 a 2,75 toneladas de CO2 equivalente** em reduções ou capturas de emissões ([EPA WARM model](https://www.epa.gov/warm)).
Apesar desses benefícios, os resíduos orgânicos continuam fluindo majoritariamente para aterros e incineradores devido à ausência de incentivos de mercado e infraestrutura para separação na fonte.
Leis de Responsabilidade Estendida do Produtor (EPR) — que exigem que fabricantes e importadores assumam parte dos custos ambientais de seus produtos — e programas de pagamento proporcional à geração (PAYT) tiveram adoção limitada em sua forma atual. Ambos são abordagens centralizadas que não criaram a dinâmica de mercado necessária para escalar a reciclagem de alto desempenho no nível individual e empresarial.
Os mercados de carbono, tanto obrigatórios (Sistemas de Comércio de Emissões) quanto voluntários, enfrentam desafios persistentes que limitam sua eficácia:
* **Cobertura limitada** — Grandes economias (incluindo EUA, Brasil, Índia e Indonésia) ainda não possuem mecanismos obrigatórios de precificação de carbono.
* **Preços muito baixos** — Em muitos mercados, ainda é mais barato comprar créditos baratos ou pagar multas do que investir em descarbonização.
* **Gargalos de certificação** — A certificação por terceiros (ex.: [Gold Standard](https://www.goldstandard.org/), [Verra](https://verra.org/)) é lenta (3-5 anos), cara (US$250-500K por projeto) e limitada aos maiores projetos poluidores.
* **Déficit de confiança** — A contabilidade de carbono é inerentemente difícil para emissões intangíveis. Dupla contagem, alegações não verificadas de desempenho futuro e falta de registros públicos minam a confiança.
* **Greenwashing** — Empresas sob pressão ESG frequentemente recorrem a alegações superficiais de sustentabilidade em vez de melhorias ambientais mensuráveis. A regulamentação está melhorando (ex.: propostas de divulgação climática da SEC, expansão do EU ETS), mas lacunas de transparência permanecem.
Resíduos físicos, diferentemente do carbono, são **tangíveis, mensuráveis e verificáveis**. Reciclagem e tratamento biológico oferecem métodos documentados e baseados em ciência para reduzir gases de efeito estufa — respaldados por frameworks da [UNFCCC](https://unfccc.int/), do [EPA WARM model](https://www.epa.gov/warm) e do [Greenhouse Gas Protocol](https://ghgprotocol.org/). Isso torna os créditos ambientais baseados em resíduos uma alternativa potencialmente de maior qualidade aos offsets tradicionais de carbono.
## A oportunidade [#a-oportunidade]
A transição de uma economia linear para uma economia circular requer forças de mercado e incentivos em todos os níveis — desde geradores individuais de resíduos até processadores industriais. As empresas precisam de incentivos financeiros para adquirir insumos reciclados e projetar para a reciclabilidade. Os indivíduos precisam confiar que seus esforços de separação resultam em reciclagem real e ser recompensados por participar.
O que falta é um sistema capaz de **rastrear, verificar e incentivar** a reciclagem e o tratamento biológico em escala — desde resultados de reciclagem até créditos de carbono — criando uma economia circular orientada pelo mercado onde o impacto ambiental seja transparente, negociável e confiável. Isso requer rastreabilidade robusta da [cadeia de suprimentos](/docs/protocol/supply-chain) e Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)) para garantir que cada alegação seja respaldada por dados auditáveis.
[Leia sobre a solução da Carrot](/docs/protocol/the-solution)
# A Solução
## De linear para circular [#de-linear-para-circular]
A economia circular é um redesenho fundamental de como os materiais fluem pela economia. Em vez do modelo extrair-produzir-descartar, a economia circular mantém os materiais em uso pelo maior tempo possível e os recupera ao final de sua vida útil para reuso e reciclagem.
Os materiais se dividem em duas grandes categorias, cada uma representando aproximadamente metade do consumo total de recursos:
* **Materiais técnicos** — Recursos finitos (metais, vidro, plásticos) que não se degradam naturalmente. A maioria pode ser reciclada repetidamente se os produtos forem desmontados e separados por tipo de material. Volumes maiores de reciclagem também melhoram a eficiência do processamento — por exemplo, fornos de vidro que operam com cacos reciclados funcionam a temperaturas mais baixas, reduzindo custos de energia e emissões de CO2.
* **Materiais biológicos** — Recursos renováveis (alimentos, resíduos verdes, embalagens compostáveis) que podem ser devolvidos ao ambiente natural por meio do tratamento biológico (ex.: compostagem, digestão anaeróbia, processamento por larvas black soldier fly, processamento microbiano), restaurando o solo e sustentando o crescimento futuro de plantas. Produtos biológicos não devem ser confundidos com biodegradáveis, que são derivados de petróleo e produzem microplásticos ao se degradar.
Uma economia circular eficiente reduz a dependência da extração de recursos virgens, diminui cadeias de suprimentos carbono-intensivas e cria novas oportunidades econômicas em reciclagem, remanufatura e tratamento biológico.
## Contexto: conceitos da economia circular [#contexto-conceitos-da-economia-circular]
A economia circular se baseia em marcos conceituais estabelecidos. A Carrot constrói sobre essas bases para criar uma abordagem orientada pelo mercado.
O Resíduo Zero fornece o referencial para o desempenho da economia circular. Conforme definido pela [Zero Waste International Alliance (ZWIA)](https://zwia.org/zero-waste-definition/), é a conservação de todos os recursos por meio de produção, consumo, reuso e recuperação responsáveis — sem queima ou descarte em solo, água ou ar.
Instituições como a ZWIA e o programa [TRUE (Total Resource Use and Efficiency)](https://true.gbci.org/) do US Green Building Council estabelecem uma taxa mínima de **90,1% de desvio de resíduos** de aterros, incineradores e do meio ambiente para certificação. Embora isso pareça ambicioso comparado à média global de 19%, a experiência prática mostra que é alcançável.
Uma percepção crítica dos dados de composição de resíduos: aproximadamente **50% de todos os resíduos globais são matéria orgânica**. Como os resíduos orgânicos são 100% recicláveis por meio do tratamento biológico, desviá-los do fluxo de lixo é o primeiro passo de maior impacto. A remoção de resíduos orgânicos também elimina a contaminação alimentar dos recicláveis, normalmente melhorando o desempenho de reciclagem dos materiais restantes em **2-4x**.
O Pay-As-You-Throw (PAYT) atribui a responsabilidade pelos resíduos a cada gerador com base na quantidade real de resíduos que produz — semelhante a uma conta de serviço público de água ou eletricidade. Essa simples mudança na precificação cria incentivos diretos para a redução de resíduos e a separação na fonte.
Quando empresas e indivíduos pagam por unidade de resíduo, são motivados a reduzir, separar e reciclar. O PAYT também abre o mercado de reciclagem para empresas privadas que podem oferecer serviços de coleta, reciclagem e tratamento biológico de alto desempenho, criando competição e inovação onde os sistemas municipais centralizados falharam em escalar.
A Responsabilidade Estendida do Produtor (EPR) exige que fabricantes e importadores de produtos assumam uma parcela dos custos ambientais de seus produtos por meio de compensações de reciclagem. As empresas reportam os resíduos gerados por suas operações e produtos e, em seguida, compram compensações — créditos de reciclagem ou carbono — para compensar o material não recuperado.
Os programas de EPR estão ganhando força globalmente. Grandes corporações endossaram o modelo e as regulamentações estão se expandindo em diversas jurisdições. No entanto, os sistemas atuais de EPR enfrentam desafios fundamentais:
* **Contagem dupla** — Sistemas de validação baseados em recibos são facilmente manipuláveis, com múltiplos recibos gerados para a mesma massa de resíduos em diferentes jurisdições.
* **Sem cadeia de custódia** — As recompensas das vendas de compensações chegam apenas ao operador final da cadeia de suprimentos, sem mecanismo para remunerar os contribuidores a montante (coletores, separadores, transportadores).
* **Centralizado e burocrático** — A coordenação entre municípios, estados e governo federal leva a uma qualidade de dados ruim e alocação ineficiente de recursos.
## Como a Carrot preenche a lacuna [#como-a-carrot-preenche-a-lacuna]
Muitas soluções do mercado de carbono — intemperismo aprimorado de rochas, captura direta de ar, sequestro de biochar — dependem de modelagem complexa, estimativas e inferência de longo prazo. A abordagem da Carrot é diferente: seu sistema de Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)) verifica eventos físicos reais. Os resíduos são coletados, pesados, transportados e processados em uma instalação homologada. Os dados são diretos, os resultados são mensuráveis e cada crédito está vinculado a um evento físico específico e verificável.
A Carrot combina PAYT e EPR com dMRV para resolver os problemas fundamentais de confiança, transparência e distribuição justa de recompensas.
Resíduos físicos — diferente das emissões de carbono — são **tangíveis, mensuráveis e verificáveis**. [Integradores](/docs/protocol/network-integrators) fornecem rastreabilidade da cadeia de suprimentos por meio de dados de cadeia de custódia, desde a geração até o processamento final. O sistema dMRV da Carrot verifica esses dados, e os [MassIDs](/docs/protocol/mass-ids) preservam as evidências de suporte, criando uma cadeia de custódia que impede a contagem dupla e permite que as recompensas sejam distribuídas aos contribuidores verificados por meio de liquidação executada por software determinístico.
Os benefícios de redução de carbono da reciclagem e do tratamento biológico são bem documentados e baseados em ciência, com marcos de medição da [UNFCCC](https://unfccc.int/), do [modelo EPA WARM](https://www.epa.gov/warm) e do [Greenhouse Gas Protocol](https://ghgprotocol.org/). Ao aplicar esses marcos a dados verificáveis de resíduos físicos, o sistema dMRV da Carrot produz créditos ambientais — [Tokenized Recycling Credits (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc) emitidos sob metodologias como [BOLD Recycling](/docs/methodologies/bold-recycling), e [Tokenized Carbon Credits (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc) emitidos sob metodologias como [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) — que são respaldados por resultados reais e mensuráveis, em vez de estimativas ou projeções futuras.
Os recursos das compras de créditos são distribuídos aos participantes, criando um ciclo de incentivos autorreforçante: mais reciclagem gera mais créditos, que financiam mais capacidade de reciclagem. Essa abordagem orientada pelo mercado escala a participação sem exigir fiscalização centralizada ou tributação.
[Leia sobre como o sistema funciona de ponta a ponta](/docs/network)
## Visão: fechando o ciclo [#visão-fechando-o-ciclo]
A Rede Carrot estabelece as bases para uma economia de consumo totalmente circular. À medida que amadurece, os participantes poderão construir soluções que trazem transparência a todo o ciclo de vida do produto:
* **Prova de conteúdo reciclado** — MassIDs de materiais certificados como reciclados podem ser vinculados a novos produtos, permitindo que os produtores provem de forma verificável o conteúdo de material reciclado, em vez de depender de alegações de marketing não verificadas.
* **Composição do produto** — Auditores terceirizados podem analisar a composição material e química de produtos e atribuir Identificadores de Tipo de Produto (PTIs), permitindo a criação automatizada de MassIDs quando os produtos entram no fluxo de reciclagem.
* **Reciclabilidade local** — Os consumidores podem verificar se um produto é reciclável em sua região — não apenas teoricamente reciclável — e aprender como descartá-lo corretamente para os operadores de reciclagem locais.
Essas capacidades fecham a lacuna de informação entre produtores e consumidores, tornando a reciclabilidade uma vantagem competitiva para empresas e uma escolha informada para compradores.
***
[Ver como comprar](/docs/protocol/credit-purchase) | [Falar com nossa
equipe](https://carrot.eco/pt-BR/contact)
### Diagram: solution-overview-flow
Esta visão geral da solução expande o ciclo em etapas operacionais físicas e digitais. Geração de resíduos, coleta e processamento avançam para criação de MassID, verificação dMRV, certificados, créditos e mercado de créditos; a distribuição de recompensas retorna ao mundo físico. A mensagem é um sistema autorreforçante em que atividade verificada financia mais reciclagem.
# Verificação de Terceiros
## Garantia de terceiros em todos os níveis [#garantia-de-terceiros-em-todos-os-níveis]
A Carrot não depende de sua própria avaliação para gerar [créditos](/docs/protocol/credits). Em cada nível do ecossistema, terceiros independentes validam que o processo é íntegro. Essa separação entre as operações da Carrot e a asseguração independente é fundamental para a integridade dos créditos.
O resultado: o framework de metodologia do qual um crédito depende, e as instalações e participantes por trás dele, são validados por partes independentes da Carrot, e não pela própria avaliação da Carrot. A execução das regras é determinística e todo resultado é auditável.
Para o mapa mais amplo de papéis, incluindo onde VVBs e auditores se encaixam no sistema de
créditos, veja [Papéis no Ecossistema de Créditos](/docs/protocol/credit-ecosystem-roles).
## Quatro níveis de validação independente [#quatro-níveis-de-validação-independente]
Cada nível aborda uma dimensão diferente de confiança — desde as operações físicas até a execução digital de regras.
| Nível | O que é validado | Quem valida |
| ----------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Auditoria de instalação** | Inspeção física de instalações de reciclagem e tratamento biológico. Verifica que a instalação opera conforme declarado e atende aos requisitos definidos na metodologia. | Auditores independentes |
| **Homologação** | Validação de documentos e processos. Verifica que os participantes (geradores, transportadores, processadores, recicladores) possuem documentação, licenciamento e capacidade operacional adequados. | Auditores independentes |
| **Validação do framework de metodologia** | O framework de metodologia (MvF) é validado contra a metodologia científica de origem. Assegura que as regras operacionais representam fielmente a base científica. | Organismos de Validação e Verificação (VVBs) |
| **Execução do dMRV** | A aplicação de verificação automatizada (MvA) executa as regras da metodologia contra os dados da cadeia de suprimentos. Resultados de execução, execuções de regras e entradas permanecem como dados da plataforma; compromissos selecionados são registrados no registry público imutável. | Software determinístico, com decisões humanas registradas pela Carrot quando uma regra não pode ser resolvida em código; auditável por VVBs e pelo público |
Quando uma regra não pode ser resolvida em código, ela retorna um resultado indeterminado, e o
julgamento é feito por uma decisão registrada do lado da Carrot — aprovar ou rejeitar, cada uma com
justificativa escrita obrigatória e um revisor identificado. Se a janela de revisão se encerrar sem
decisão, as regras pendentes são rejeitadas automaticamente e a verificação falha. Essas decisões
ficam guardadas junto à execução da verificação, para que a asseguração externa possa revisar tanto
os resultados das regras quanto os julgamentos aplicados a eles.
## O que a Carrot faz vs. o que terceiros fazem [#o-que-a-carrot-faz-vs-o-que-terceiros-fazem]
### Carrot — infraestrutura e aprovação [#carrot--infraestrutura-e-aprovação]
A Carrot Foundation aprova e zela por metodologias, frameworks de verificação e aplicações de dMRV de terceiros para uso na Rede Carrot. Separadamente, o sistema de Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)) executa os critérios dos frameworks aprovados contra os dados submetidos e preserva a evidência resultante para créditos de reciclagem e de carbono.
A Carrot não cria metodologias, frameworks de verificação ou aplicações de dMRV. Ela também não substitui a garantia externa: seu papel é executar critérios aprovados, registrar resultados e tornar a evidência revisável.
A infraestrutura da Carrot inclui:
* Validar entradas de dados contra critérios de frameworks aprovados
* Executar cálculos e regras de elegibilidade ou exclusão
* Registrar evidências digitais e trilhas de auditoria, incluindo logs, versões, eventos e decisões automatizadas
* Aplicar controles de integridade e prevenção de dupla contagem, inclusive entre metodologias sobrepostas
### Terceiros — garantia independente [#terceiros--garantia-independente]
[Organismos de Validação e Verificação](/docs/glossary#vvb), auditores independentes e outros provedores de garantia aprovados revisam a evidência e o processo de governança com escopo e profundidade definidos pela metodologia, framework, processo de homologação ou requisito de mercado aplicável.
Eles podem:
* Validar a fidelidade do MvF contra a metodologia de origem
* Avaliar se o MvA implementa fielmente o MvF
* Revisar o [pacote de evidências digitais](/docs/glossary#digital-evidence-package) gerado pelo sistema de dMRV da Carrot e realizar testes, amostragens e auditorias adicionais
* Emitir relatórios independentes com achados, não conformidades e recomendações
## O pacote de evidências [#o-pacote-de-evidências]
O sistema dMRV da Carrot organiza e entrega um pacote de evidências digitais — dados, documentos, logs, versões e eventos — que os VVBs utilizam para realizar sua análise independente. Esse pacote é a interface entre a verificação automatizada e o julgamento humano: tudo o que o sistema registra se torna insumo para a revisão independente.
A infraestrutura de verificação conecta dados da cadeia de suprimentos, regras de metodologia e trilhas de auditoria em um único pipeline verificável. Os Integradores fornecem dados da cadeia de suprimentos de suas operações, o sistema aplica as regras de metodologia a esses dados, e as evidências resultantes ficam disponíveis para revisão independente.
* [dMRV](/docs/protocol/dmrv)
* [Integradores](/docs/protocol/network-integrators)
* [Execução da Metodologia](/docs/protocol/methodology-execution)
# O Standard - Programa de Créditos da Economia Circular
## O que é um standard nos mercados ambientais? [#o-que-é-um-standard-nos-mercados-ambientais]
Nos mercados ambientais, um **standard** é o programa de créditos que define e governa as regras de como os créditos ambientais são medidos e verificados. O organismo de standards aprova [metodologias](/docs/methodologies), gerencia seu ciclo de vida — desde o design inicial, passando pelo versionamento, até a eventual descontinuação — e garante que os créditos produzidos sob essas metodologias atendam a um nível consistente de qualidade.
Sem um organismo de standards, não existe autoridade independente governando o que conta como um crédito válido. O standard é a camada de confiança entre o projeto que gera impacto ambiental — incluindo créditos de carbono e outras categorias — e o comprador que paga por ele.
Para o mapa mais amplo de standards, metodologias, Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)), [registry](/docs/registry), VVBs e compradores, veja [Papéis
no Ecossistema de Créditos](/docs/protocol/credit-ecosystem-roles).
## Por que a Carrot é um standard [#por-que-a-carrot-é-um-standard]
A Carrot atua como organismo de standards e governança para metodologias, frameworks de verificação de metodologia e aplicações de dMRV aprovados para uso na Rede Carrot. Ela define o Carrot dMRV Standard, avalia se metodologias e frameworks submetidos atendem a esse standard e gerencia seu ciclo de vida por meio de aprovação, versionamento e descontinuação.
O Carrot dMRV Standard estabelece a base comum que permite que múltiplas metodologias coexistam em infraestrutura compartilhada, cada uma contribuindo com dados verificados de impacto ambiental para o mesmo ecossistema.
Esse papel de autoridade independente é parte do motivo pelo qual a Rede Carrot é construída como [infraestrutura pública digital](/docs/network/digital-public-infrastructure), não como um produto privado de verificação.
## Arquitetura do programa de créditos [#arquitetura-do-programa-de-créditos]
A arquitetura avança de regras compartilhadas do programa para registros públicos de créditos. O [Protocolo](/docs/protocol) define os requisitos do domínio. O Standard governa metodologias; cada metodologia é operacionalizada por um [Framework de Verificação de Metodologia (MvF)](/docs/standard/concepts/mvf); aplicações de dMRV executam essas regras; e o Registry registra o ciclo de vida resultante dos créditos.
## O que isso significa para a qualidade dos créditos [#o-que-isso-significa-para-a-qualidade-dos-créditos]
Cada [crédito](/docs/protocol/credits) emitido dentro da Rede Carrot é respaldado por uma metodologia governada sob o Carrot dMRV Standard. Três propriedades sustentam a integridade dos créditos:
* **Regras de código aberto** — Toda lógica de verificação é publicada sob uma licença de código aberto e publicamente auditável. Qualquer pessoa pode inspecionar as regras que produziram um determinado resultado.
* **Verificação automatizada e auditável** — A verificação é executada por software determinístico ([MvAs](/docs/standard/concepts/mva)) que produz o mesmo resultado para a mesma entrada, todas as vezes. Os resultados são registrados no registry público de créditos e visíveis através do [Carrot Registry](/docs/protocol/registry).
* **Garantia independente** — [Organismos de Validação e Verificação (VVBs)](/docs/glossary#vvb) terceirizados fornecem revisão independente, adicionando uma camada de supervisão além do processo automatizado.
## Explore esta seção [#explore-esta-seção]
* **[Conceitos](/docs/standard/concepts/mvf)** — Fundamentos de MvF, MvA, ecossistema e ciclo de vida.
* **[Guias](/docs/standard/guides/mvf-author-guide)** — Guias práticos para autoria de frameworks, desenvolvimento de aplicações de verificação e participação em RFPs.
* **[Políticas](/docs/standard/policies/versioning)** — Versionamento, garantia de qualidade, homologação, descontinuação e distribuição de recompensas.
### Diagram: crediting-architecture-flow
A arquitetura parte do Protocolo e do Standard como programa de créditos da economia circular, passa por uma Metodologia aprovada e seu Framework de dMRV e chega à execução de dMRV. As aplicações de dMRV executam as regras do framework e produzem evidências auditáveis; o Registry registra o ciclo de vida resultante dos créditos, da emissão à aposentadoria.
# Termos e Condições de Venda de Créditos Ambientais
{/* cspell:words Fndn Sielva Gubelstrasse LGPD RGPD OFAC SECO ITMOs mutandis Lugano dMRV Tokenizados escriturais escrituração */}
**Versão 2.0 — 31 de agosto de 2026**
Estes Termos regem toda compra de Créditos Ambientais na plataforma da Carrot, por consumidores (PF) e empresas (PJ); negócios corporativos negociados individualmente podem ser regidos, adicionalmente, por contrato marco que prevalece no que dispuser (cláusula 1.4). Para Compradores domiciliados no Brasil, rege a versão em português destes Termos; para os demais, rege a versão em inglês.
## 1. Quem somos e o que estes Termos regulam [#1-quem-somos-e-o-que-estes-termos-regulam]
1.1. Estes Termos e Condições ("Termos") regulam a compra de Créditos Ambientais junto à Carrot Fndn, fundação constituída sob o direito suíço (arts. 80 e seguintes do Código Civil Suíço), com sede em Zug, Suíça, c/o Sielva Management SA, Gubelstrasse 11, 6300 Zug, UID CHE-152.448.302 ("Fundação" ou "Carrot").
1.2. Atendimento em português: [support@carrot.eco](mailto:support@carrot.eco). Encarregado de proteção de dados (LGPD): [legal@carrot.eco](mailto:legal@carrot.eco).
1.3. Ao concluir uma compra, você ("Comprador") celebra com a Fundação um contrato de cessão definitiva de Créditos Ambientais, nos termos abaixo. Estes Termos aplicam-se em conjunto com os [Termos e Condições Gerais](/docs/terms/terms-and-conditions) e a [Política de Privacidade](/docs/terms/privacy-policy) da Fundação; em caso de conflito, prevalecem estes Termos quanto à compra de Créditos.
1.4. **Compradores e âmbito.** Estes Termos regem toda compra de Créditos Ambientais realizada na plataforma, por consumidores (pessoas físicas ou quem adquire como destinatário final) e por empresas (pessoas jurídicas). Outros produtos e serviços oferecidos na plataforma — como planos de acesso (membership), acesso a dados e APIs e serviços de certificação baseados nos dados verificados da Carrot Network (por exemplo, certificação de aterro zero, passaportes de produto que comprovam uso de conteúdo reciclado, inset tracking ou documentação de transporte (hauling) para Escopo 3) — são contratados sob termos próprios e separados, não constituem venda de Créditos e não conferem, por si, Alegações Ambientais; nada nestes Termos os rege, e a sua contratação não altera a natureza da compra de Créditos prevista na cláusula 3. As disposições referentes ao "Comprador consumidor" (em especial a cláusula 7) aplicam-se somente quando incidentes as normas de proteção do consumidor. Negócios corporativos negociados individualmente podem ser regidos, adicionalmente, por contrato marco B2B, que complementa e, nos pontos que dispuser, prevalece sobre estes Termos para aquele negócio.
## 2. Definições [#2-definições]
* "**Crédito Ambiental**" ou "**Crédito**": ativo intangível, escritural e individualizado, representativo de uma contribuição ambiental verificada — (i) "**Crédito de Reciclagem**" (TRC): massa determinada de resíduo efetivamente reciclada ou reutilizada, verificada conforme Metodologia aprovada; ou (ii) "**Crédito de Carbono**" (TCC): tonelada de CO₂ equivalente reduzida ou removida, verificada conforme Metodologia aprovada.
* "**Carrot Registry**": o registro escritural mantido e operado pela Fundação, sob o direito suíço, a partir de sua sede na Suíça, no qual os Créditos são emitidos, escriturados, transferidos e aposentados, e no qual os Créditos se situam. Utiliza tecnologia de registro distribuído (blockchain) como forma de escrituração e prova de integridade: os Créditos são escriturados como lançamentos digitais ("tokenizados") — origem do "T" nas siglas TRC e TCC. A tokenização é a forma de escrituração do registro; não transforma o Crédito em criptomoeda, meio de pagamento ou instrumento financeiro. O Carrot Registry escritura a titularidade própria de cada titular, à maneira de um registro de propriedade; a Fundação atua como emissora e operadora do registro — não como depositária ou custodiante de ativos de terceiros.
* "**Conta**": a conta do titular na plataforma da Carrot, na qual ficam registrados os Créditos em Conta (ainda não aposentados) e os já aposentados em seu nome, com os respectivos Certificados.
* "**Créditos em Conta**" ou "**em Conta**": o estado do Crédito adquirido e ainda não aposentado, de titularidade do respectivo titular da Conta, registrado na sua Conta, passível de Aposentadoria ou de Transferência nos termos da cláusula 6.
* "**Transferência**": a cessão definitiva do Crédito em Conta a outro titular de Conta, registrada no Carrot Registry (cláusula 6).
* "**Aposentadoria**" (retirement): o ato, definitivo e irreversível, de baixa do Crédito no Carrot Registry — ou, para os Créditos da cláusula 5.4, no registro de terceiro aplicável — em nome do titular indicado (beneficiário), que consuma o uso do Crédito e é o único ato que confere o direito de reportar a contribuição ambiental correspondente ("Alegações Ambientais").
* "**Certificado**": o documento emitido pela Fundação após a Aposentadoria, com identificação do beneficiário, quantidade, tipo, vintage, lote e referência pública de verificação (incluindo os identificadores de dados associados — RecycledID para TRC, GasID para TCC), acompanhado, quando houver, de comprovante digital intransferível (receipt token) emitido ao Comprador ou ao beneficiário, que serve exclusivamente como evidência da Aposentadoria e não confere direitos, valor, transferibilidade ou função além dessa evidência.
* "**Metodologias**": as metodologias de medição, relato e verificação (dMRV) aprovadas no âmbito da Carrot Network. Para os Créditos da cláusula 5.4, incluem o padrão ou a metodologia de terceiro ali designados.
* "**titular**": qualquer pessoa que registre Créditos em uma Conta, adquiridos por compra ou por Transferência. A abertura de Conta exige a aceitação destes Termos, que vinculam todo titular.
## 3. Natureza da operação — o que você compra (e o que você não compra) [#3-natureza-da-operação--o-que-você-compra-e-o-que-você-não-compra]
3.1. A compra regida por estes Termos é a aquisição definitiva de um ativo intangível (o Crédito), destinado à contribuição ambiental por meio da Aposentadoria — imediata ou futura — em nome do Comprador ou de quem ele indicar nos limites destes Termos.
3.2. **O que a compra não é:** (i) não é prestação de serviços; (ii) não é investimento, valor mobiliário, oferta pública de distribuição, título, participação societária ou direito a rendimentos — o Crédito não confere expectativa de lucro, e a Fundação não promete liquidez, recompra nem valorização; (iii) não é criptomoeda nem meio de pagamento; (iv) não confere direitos sobre a Fundação, a Carrot Network ou sua propriedade intelectual.
3.3. **Finalidade de contribuição.** O valor do Crédito realiza-se com a sua Aposentadoria. A manutenção de Créditos em Conta e a Transferência (cláusula 6) existem para dar flexibilidade de uso — inclusive calendários próprios de reporte — e não constituem convite à especulação. A comunicação comercial da Carrot não constitui recomendação de investimento. O Carrot Registry, as Metodologias e as páginas públicas de verificação são infraestrutura aberta, mantida para a rede como um todo e consultável por qualquer pessoa, sem cobrança; o Crédito é o ativo privado e transacionável emitido sobre essa infraestrutura. A emissão, a escrituração e a Aposentadoria dos Créditos, bem como a manutenção do Carrot Registry, são atributos inerentes aos Créditos e ao papel da Fundação como emissora e operadora do registro; não são serviços prestados ao Comprador, e nenhuma parcela do preço os remunera. Os Créditos vendidos derivam de alegações ambientais cedidas à Fundação, de forma exclusiva e irrevogável, pelos participantes da rede, nos termos da rede; a Fundação define os preços dos Créditos a seu exclusivo critério, e nenhum participante, Comprador ou terceiro tem direito a que Créditos sejam ofertados por qualquer preço específico. A distribuição de recursos de venda aos participantes é regida pelos termos da rede, não por estes Termos.
3.4. **Alegações voluntárias; sem ajuste correspondente.** Os Créditos são vendidos para Alegações Ambientais voluntárias. Não são resultados de mitigação transferidos internacionalmente (ITMOs) nos termos do Artigo 6 do Acordo de Paris; nenhum ajuste correspondente por qualquer Estado é fornecido, providenciado ou implícito; e nenhum Crédito constitui instrumento de conformidade em qualquer sistema de comércio de emissões ou regime compulsório.
3.5. **Revenda profissional somente por credenciamento.** A intermediação, distribuição ou revenda profissional de Créditos — inclusive por plataformas que adquirem para revender — somente é permitida mediante contrato de credenciamento específico com a Fundação, que disciplina as obrigações do intermediário perante seus clientes e as normas dos países em que atue. Estes Termos não autorizam oferta pública de Créditos por terceiros.
## 4. Compra, preço e pagamento [#4-compra-preço-e-pagamento]
4.1. A compra é realizada na plataforma da Carrot, mediante aceite destes Termos no checkout.
4.2. **Preço e tributos.** O preço é o exibido no checkout, na moeda ali indicada, com os tributos aplicáveis discriminados ("impostos inclusos" ou destacados, conforme o caso). Tributos, encargos ou custos do meio de pagamento suportados pelo Comprador (por exemplo, IOF em operações internacionais) são informados no checkout ou cobrados pelo emissor/provedor do meio de pagamento, conforme a legislação aplicável. Para consumidores, a compra de Créditos não é dedutível de imposto de renda e não constitui doação.
4.3. **Meios de pagamento:** os disponíveis no checkout (cartão, PIX, transferência bancária ou outros), processados por prestadores de serviços de pagamento. A compra se confirma com a aprovação do pagamento. Nas compras por transferência bancária, a venda se completa com o crédito dos recursos compensados na conta da Fundação, e os Créditos são escriturados na Conta do Comprador (ou aposentados, conforme o modo escolhido) em até 5 (cinco) dias úteis contados da compensação, salvo cronograma diverso em contrato marco B2B.
4.4. **Documentos da compra:** o Comprador recebe a fatura da Fundação e, quando aplicável, o documento fiscal eletrônico brasileiro correspondente, além do Certificado quando houver Aposentadoria.
4.5. **Estornos e chargebacks.** Havendo contestação ou estorno do pagamento, a Fundação poderá suspender entrega, Transferências, Aposentadorias e emissão de Certificados vinculados à compra afetada enquanto pendente a contestação, e poderá tratar o estorno confirmado como resolução da compra. Nesse caso: para os Créditos daquela compra ainda em Conta, o cancelamento dos Créditos encerra a questão e nenhum preço permanece devido por eles; para os Créditos já aposentados ou transferidos antes do estorno, o preço correspondente permanece devido — tudo sem prejuízo dos direitos irrenunciáveis do consumidor.
4.6. **Créditos promocionais.** Créditos gratuitos ou promocionais são regidos pelas regras específicas de cada campanha, publicadas com ela.
4.7. **Identificação e domicílio do Comprador.** A compra, a manutenção de Créditos em Conta e a Transferência exigem cadastro com dados verdadeiros, completos e atualizados. O Comprador declara seu país e endereço de domicílio e autoriza a Fundação a utilizar dados do meio de pagamento e IP/geolocalização para determinar a jurisdição tributária aplicável e a versão aplicável destes Termos. O Comprador garante a exatidão e a atualização dessas informações.
## 5. Entrega: aposentadoria imediata ou Créditos em Conta [#5-entrega-aposentadoria-imediata-ou-créditos-em-conta]
5.1. No checkout, o Comprador escolhe entre:
**(a) Aposentadoria imediata** — confirmado o pagamento, a Fundação escritura os Créditos no Carrot Registry como adquiridos pelo Comprador e, imediatamente e no mesmo assentamento de registro, executa a instrução expressa de Aposentadoria do Comprador (cláusula 7.3), aposentando os Créditos do Comprador em seu nome ou no do beneficiário que ele indicar. A titularidade passa ao Comprador com a escrituração; a Aposentadoria é o consumo dos Créditos próprios do Comprador, por instrução sua. Não há taxa destacada de Aposentadoria.
**(b) Créditos em Conta** — o Crédito é registrado na Conta do Comprador, para Aposentadoria futura (a qualquer tempo, por comando seu, em seu nome ou de terceiro identificado que indique) ou Transferência nos termos da cláusula 6.
5.2. Em qualquer dos modos, a Conta exibe os Créditos com tipo, quantidade, lote e vintage. Consumada a Aposentadoria, a Fundação emite o Certificado e disponibiliza a referência pública de verificação no Carrot Registry. A Aposentadoria é definitiva e irreversível.
5.3. Créditos em Conta não conferem Alegações Ambientais (cláusula 2, "Aposentadoria") — o relato da contribuição exige a Aposentadoria.
5.4. **Créditos vinculados a registros e padrões de terceiros.** A Fundação poderá emitir e vender Créditos sob metodologias, padrões ou programas de terceiros, ou vinculados a créditos emitidos em registros de terceiros (por exemplo, programas internacionais de certificação de carbono e seus registros). Créditos emitidos e mantidos em registros de terceiros são entregues exclusivamente na forma da cláusula 5.1(a), aplicada mutatis mutandis ao registro de origem — aposentadoria imediata no registro de origem, em nome do beneficiário indicado —, não sendo elegíveis a permanência em Conta nem a Transferência. A Fundação designa no ponto de venda, por tipo de Crédito, os modos de entrega disponíveis e o registro em que a Aposentadoria ocorre. A Fundação poderá habilitar, no futuro, conta segregada para esses créditos, mediante atualização destes Termos.
## 6. Créditos em Conta e Transferência [#6-créditos-em-conta-e-transferência]
6.1. O titular pode manter Créditos emitidos no Carrot Registry em Conta pelo tempo que desejar, aposentá-los a qualquer momento (em nome próprio ou de terceiro que indique, identificado) e transferi-los nos termos desta cláusula. Créditos vinculados a registros de terceiros seguem a cláusula 5.4.
6.2. **Condições de Transferência:** (i) o cessionário deve ser titular de Conta com cadastro e verificação (KYC/KYB) aprovados; (ii) são vedadas transferências a pessoas sancionadas ou em violação a normas de prevenção à lavagem de dinheiro, podendo a Fundação recusar ou suspender transferências nessas hipóteses; (iii) a Transferência é registrada no Carrot Registry e é definitiva — o cedente perde todos os direitos sobre o Crédito transferido; (iv) eventual pagamento entre cedente e cessionário é relação exclusiva entre eles, fora da plataforma — a Fundação não intermedeia, não precifica e não garante liquidez ou contraparte; (v) a Fundação poderá cobrar taxa administrativa fixa pelo processamento da Transferência, informada com antecedência — nunca calculada sobre o valor de eventual negócio entre as partes.
6.3. **A Fundação não opera mercado.** A plataforma não constitui bolsa, balcão organizado ou sistema de negociação de Créditos; não há livro de ofertas, formação pública de preços, cotações, nem intermediação ou pareamento de negociações entre titulares pela Fundação.
6.4. **Intermediários credenciados.** A aquisição de Créditos para revenda profissional segue a cláusula 3.5 (contrato de credenciamento). O intermediário credenciado responde integralmente, perante seus clientes, pelas obrigações da revenda — inclusive normas de consumo e tributárias dos países em que atuar.
## 7. Direito de arrependimento (compradores consumidores) [#7-direito-de-arrependimento-compradores-consumidores]
7.1. O Comprador consumidor pode exercer o direito de arrependimento no prazo legal do seu domicílio — no Brasil, 7 (sete) dias corridos da confirmação da compra (art. 49 do Código de Defesa do Consumidor); no Espaço Econômico Europeu e no Reino Unido, 14 dias contados da celebração do contrato (confirmação da compra), observada a cláusula 7.3 — pelo canal de atendimento indicado (cláusula 1.2), mediante confirmação de identidade e com confirmação imediata do recebimento do pedido. Consumidores do EEE e do Reino Unido podem usar o [formulário-modelo de retratação](/docs/terms/withdrawal-form), sem obrigatoriedade; os reembolsos ocorrem sem demora indevida e, em qualquer caso, em até 14 dias do pedido. Se a lei do seu país não previr direito de arrependimento, a compra é definitiva após concluída — aplicando-se ainda a cláusula 7.4 e a política de atendimento.
7.2. **Efeitos, conforme o estado do Crédito no momento do pedido:**
(a) **Créditos em Conta:** a compra é desfeita — os Créditos retornam à Fundação e o valor integral é restituído pelo mesmo meio de pagamento, de forma imediata e corrigido monetariamente quando a lei o exigir.
(b) **Créditos aposentados a pedido expresso do Comprador** (cláusulas 5.1(a) e 7.3): para consumidores cujo domicílio preserve o direito de arrependimento nesta hipótese (inclusive o Brasil), a Fundação restitui integralmente o valor pago, pelo mesmo meio de pagamento, corrigido monetariamente quando a lei o exigir; o Crédito já aposentado não retorna — é absorvido pela Fundação. O atendimento não pode negar reembolso pedido dentro do prazo legal.
(c) **Créditos transferidos a terceiro:** a restituição do valor está condicionada à devolução dos Créditos à Conta do Comprador antes do exercício — não sendo possível restituí-los, o arrependimento não produz reembolso, sem prejuízo dos direitos legais irrenunciáveis do consumidor.
7.3. **Consentimento para execução imediata.** Ao optar pela Aposentadoria imediata no checkout, o Comprador manifesta, por checkbox próprio e dedicado, nunca pré-marcado e de marcação ativa obrigatória, que: (i) solicita que a Fundação aposente os Créditos imediatamente após a confirmação do pagamento, antes do fim de qualquer prazo de retratação; (ii) compreende estar adquirindo um Crédito que será imediata e irreversivelmente aposentado e que não poderá mais ser transferido nem devolvido; e (iii) reconhece que, consumada a Aposentadoria, perde o direito de retratação — salvo onde a lei do seu domicílio o preserve (no Brasil, aplica-se a cláusula 7.2(b)). No Espaço Econômico Europeu e no Reino Unido, esse consentimento expresso com reconhecimento extingue o direito de retratação com a execução integral (art. 16, alíneas "a" e "m", da Diretiva 2011/83/UE e normas equivalentes do Reino Unido, conforme aplicável). A manifestação é registrada com data, hora, conteúdo e versão dos Termos, e a confirmação da compra reproduz esse consentimento e reconhecimento em suporte duradouro (e-mail).
7.4. Após o prazo legal, a operação está consumada. Pedidos posteriores serão tratados conforme a política de atendimento da Fundação, que poderá, a seu critério e como cortesia comercial, oferecer créditos equivalentes — sem que isso constitua obrigação legal.
7.5. **Não aplicação a compras empresariais.** O direito de arrependimento desta cláusula é direito do consumidor e não se aplica às compras realizadas por empresas no exercício de sua atividade profissional. Ressalva-se a pessoa jurídica que, no caso concreto, seja qualificada como consumidora (destinatária final) nos termos da legislação e da jurisprudência aplicáveis.
## 8. Aposentadoria, prova pública e dados pessoais [#8-aposentadoria-prova-pública-e-dados-pessoais]
8.1. A Aposentadoria é registrada no Carrot Registry com referência pública consultável (página do Certificado), que comprova: beneficiário, quantidade, tipo, vintage, lote e data.
8.2. **Privacidade do beneficiário (LGPD).** No registro público, a pessoa física é identificada por nome civil somente se autorizar (opt-in); caso contrário, por identificador não sensível. O Certificado privado contém a identificação completa (nome e CPF/CNPJ). Pessoas jurídicas são identificadas por razão social e CNPJ.
8.3. O tratamento de dados pessoais observa a [Política de Privacidade](/docs/terms/privacy-policy) e a legislação aplicável (a LGPD para titulares no Brasil e, quando aplicável, o RGPD e a LPD suíça), incluindo as informações sobre transferência internacional de dados.
## 9. Cadastro, identificação e prevenção à lavagem de dinheiro [#9-cadastro-identificação-e-prevenção-à-lavagem-de-dinheiro]
9.1. A Fundação pode solicitar informações e documentos adicionais, de forma proporcional ao valor e ao perfil da operação (KYC/KYB/AML), e pode recusar ou desfazer operações que violem normas de sanções internacionais ou de prevenção à lavagem de dinheiro. As verificações podem ser realizadas por prestadores de pagamento ou de identidade em nome da Fundação.
9.2. O Comprador declara que: (i) é maior de 18 anos e capaz (ou pessoa jurídica regularmente constituída, por representante com poderes); (ii) os recursos utilizados têm origem lícita; (iii) não figura em listas de sanções (ONU, UE, EUA/OFAC, SECO suíça) nem reside em jurisdição embargada; (iv) compra em nome próprio (ou da organização que representa) e por conta própria.
## 10. Garantias e responsabilidade [#10-garantias-e-responsabilidade]
10.1. A Fundação garante que os Créditos vendidos: (i) existem e estão validamente emitidos no Carrot Registry conforme as Metodologias ou, para os Créditos da cláusula 5.4, validamente emitidos no registro de terceiro designado conforme o padrão designado; (ii) são de sua titularidade e estão livres de ônus na entrega; (iii) não foram objeto de dupla venda ou dupla contagem; e (iv) serão escriturados, transferidos e aposentados conforme estes Termos.
10.2. A Fundação responde pelos vícios e defeitos da operação nos termos da legislação aplicável, inclusive o Código de Defesa do Consumidor quando incidente. Nada nestes Termos exclui ou limita direitos do consumidor previstos em normas de ordem pública.
10.3. **NAS RELAÇÕES NÃO SUJEITAS A NORMAS IMPERATIVAS DE PROTEÇÃO DO CONSUMIDOR, A RESPONSABILIDADE TOTAL DA FUNDAÇÃO LIMITA-SE AO VALOR EFETIVAMENTE PAGO PELO COMPRADOR NA OPERAÇÃO, RESSALVADOS DOLO OU CULPA GRAVE.** Em jurisdições que não admitem determinadas exclusões ou limitações, a limitação aplica-se apenas na medida permitida pela lei.
10.4. A Fundação empregará esforços razoáveis para manter a plataforma e o Carrot Registry disponíveis e íntegros, mas não responde por indisponibilidades temporárias decorrentes de manutenção, força maior ou falhas de terceiros, hipóteses em que os prazos destes Termos ficam suspensos pelo período correspondente. A Fundação não faz qualquer declaração sobre valor ou preço de Créditos em qualquer momento e não responde pelas consequências da decisão do titular de manter Créditos em Conta em vez de aposentá-los, nem por perdas decorrentes de Transferências entre titulares.
## 11. Alegações Ambientais e uso do Certificado [#11-alegações-ambientais-e-uso-do-certificado]
11.1. Somente após a Aposentadoria o beneficiário pode reportar as Alegações Ambientais correspondentes (relatórios, comunicação institucional, cumprimento de compromissos voluntários), sempre com referência ao Certificado e sem alterar seu conteúdo. É vedado reportar contribuição com base em Créditos em Conta. O uso do Certificado pelo beneficiário indicado constitui aceitação desta cláusula 11.
11.2. As declarações públicas do beneficiário baseadas em Créditos devem observar as normas aplicáveis a essas declarações — inclusive regras de proteção do consumidor e de alegações ambientais e estatutos de divulgação, quando aplicáveis (como os FTC Green Guides e a lei AB 1305 da Califórnia, nos EUA) — e não podem reportar a mesma Aposentadoria em mais de um programa, padrão ou alegação. Toda Alegação Ambiental deve ser apresentada como alegação voluntária, sem que qualquer ajuste correspondente do Artigo 6 do Acordo de Paris tenha sido realizado, providenciado ou representado. A Fundação mantém páginas públicas de verificação por projeto, que comprovam origem, metodologia, verificação e status de aposentadoria.
11.3. O titular não adquire direitos sobre marcas, softwares, Metodologias ou qualquer propriedade intelectual da Fundação ou da Carrot Network, além do uso do Certificado previsto na cláusula 11.1. O beneficiário pode reproduzir o Certificado e as referências públicas do registro em relatórios de sustentabilidade, arquivamentos regulatórios, processos de asseguração e comunicações institucionais.
## 12. Compras recorrentes [#12-compras-recorrentes]
12.1. O Comprador pode optar por um plano de compra recorrente de Créditos, autorizando cobranças periódicas destinadas à aquisição, a cada ciclo, de Créditos com o destino escolhido (Aposentadoria imediata ou Créditos em Conta, cláusula 5.1). A compra recorrente é aquisição periódica de ativo — não contratação de serviço de assinatura ou compensação continuada.
12.2. Cada cobrança constitui compra autônoma, documentada individualmente. O preço de cada ciclo é o vigente na data da cobrança; alterações são comunicadas com antecedência mínima de 30 (trinta) dias e valem só para ciclos futuros.
12.3. Cancelamento a qualquer tempo, pela Conta ou pelos canais de atendimento, com efeito a partir do ciclo seguinte — sem multa. Valor, periodicidade e forma de cancelamento são informados antes da adesão, e o cancelamento está disponível on-line.
12.4. O direito de arrependimento (cláusula 7) aplica-se, de forma autônoma, a cada cobrança recorrente.
12.5. Falha na cobrança suspende a entrega do ciclo correspondente, sem obrigação da Fundação enquanto não confirmado o pagamento.
## 13. Tributos [#13-tributos]
13.1. Cada parte responde pelos tributos que a lei lhe atribui. A Fundação responde pelos tributos suíços sobre sua atividade e, quando exigível, recolhe os tributos brasileiros sobre o consumo (CBS/IBS) na condição de fornecedora não residente cadastrada, emitindo o documento fiscal correspondente.
13.2. Os preços não incluem tributos sobre valor agregado, sobre vendas ou sobre o consumo, salvo conforme exibido no checkout; quando a lei exigir que a Fundação os recolha, eles são identificados na tela de compra e destacados na fatura ou no documento fiscal. Valores recolhidos por mecanismo de split payment ou autolançamento são apurados conforme esse mecanismo.
13.3. Para Compradores pessoas jurídicas, a alocação específica de tributos, retenções e eventual gross-up, quando o negócio for negociado individualmente, pode ser detalhada no contrato marco B2B ou nas condições da fatura.
13.4. **Revenda e transferência:** os tributos incidentes sobre Transferências entre titulares e sobre a revenda por intermediários credenciados são de responsabilidade exclusiva das respectivas partes, conforme a legislação de cada jurisdição.
## 14. Alterações dos Termos, acordo integral e cessão [#14-alterações-dos-termos-acordo-integral-e-cessão]
14.1. A Fundação pode atualizar estes Termos a qualquer tempo, com publicação da nova versão e data. A versão aplicável a cada compra é a aceita no respectivo checkout, arquivada e disponível ao Comprador. Alterações que afetem Créditos já em Conta produzem efeitos somente 30 (trinta) dias após aviso individual (e-mail e Conta); até lá, o titular pode aposentar ou transferir os Créditos sob a versão anterior. Alterações exigidas por lei podem vigorar antes, com aviso. Nas compras sob contrato marco B2B, a versão aplicável é a anexada ao contrato ou nele designada.
14.2. **Acordo integral.** Estes Termos, os documentos neles expressamente referidos e as informações essenciais do checkout constituem o acordo integral sobre a compra. Materiais técnicos, white papers, documentação do protocolo e comunicações de marketing têm caráter informativo e não integram o contrato, salvo incorporação expressa — sem prejuízo das normas segundo as quais declarações públicas e publicidade vinculam a Fundação ou integram aquilo a que o Comprador tem direito.
14.3. **Cessão da posição contratual.** O Comprador não pode ceder sua posição contratual nestes Termos sem consentimento prévio e por escrito da Fundação. A Transferência de Créditos é regida pela cláusula 6, não por esta cláusula.
## 15. Lei aplicável, foro e idioma [#15-lei-aplicável-foro-e-idioma]
15.1. Estes Termos regem-se pelo direito suíço, ressalvadas as normas de ordem pública e de proteção do consumidor do domicílio do Comprador — no Brasil, em especial o Código de Defesa do Consumidor —, que prevalecem no que forem imperativas.
15.2. Quando norma imperativa assegurar ao consumidor o foro do próprio domicílio — inclusive consumidores domiciliados no Brasil e consumidores domiciliados em Estados vinculados à Convenção de Lugano —, esse foro prevalece. Nos demais casos, fica eleito, com exclusividade, o foro de Zug, Suíça.
15.3. As partes buscarão solução amigável pelos canais de atendimento antes de medidas formais.
15.4. **Idioma.** Para Compradores domiciliados no Brasil, rege a versão em português destes Termos; para os demais Compradores, rege a versão em inglês. Traduções são disponibilizadas por conveniência.
# Contrato de Uso da Plataforma
{/* cspell:words Fndn LGPD ANPD USDC criptoativos homologado homologados Destinador Recicladores Transportadores Processadores stablecoin Sielva Gubelstrasse McKee */}
> **Sobre este documento**
>
> Este é o instrumento que participantes no Brasil aceitam eletronicamente durante o cadastro na plataforma Carrot, nos termos da Cláusula 10. A versão publicada aqui é a 1.4, atualmente vigente.
>
> Os Termos e Condições globais, a Política de Privacidade, os Termos e Condições de Compra e Venda de Créditos Ambientais Tokenizados e a Política de Distribuição de Recompensas integram este Contrato por referência, na ordem de prevalência da Cláusula 1.3.
**Versão 1.4 — Março de 2026**
# CONTRATO DE USO DA PLATAFORMA [#contrato-de-uso-da-plataforma]
Rede de Economia Circular e Ativos Ambientais
## ENTENDA O QUE ESTE CONTRATO SIGNIFICA [#entenda-o-que-este-contrato-significa]
**VOCÊ faz...** · **A CARROT faz...** · **Como você é recompensado?**
Você compartilha dados sobre suas ações ambientais (ex.: coleta, separação e reciclagem) na plataforma Carrot por meio do Integrador de Rede, plataforma intermediária de rastreabilidade homologada pela Carrot.
A Carrot valida essas ações e as transforma em Créditos Ambientais (Crédito de Reciclagem ou Crédito de Carbono) tokenizados e os disponibiliza para venda em mercados regulados ou voluntários, nacionais ou internacionais.
Quando a venda acontece, você recebe automaticamente a sua parcela do resultado, conforme o seu papel na cadeia, sem precisar vender nada por conta própria e sem qualquer custo.
> **✓ O que isso significa para você**
>
> * Você não paga nada para usar a plataforma.
> * Você não precisa vender nada por conta própria.
> * Você pode sair do programa de créditos da Carrot a qualquer momento, sem multa.
> * Seus dados pessoais são protegidos por criptografia e não são expostos publicamente sem sua autorização.
## IDENTIFICAÇÃO DAS PARTES [#identificação-das-partes]
### O USUÁRIO [#o-usuário]
Usuário: é a pessoa física ou jurídica identificada pelos dados fornecidos e validados no processo de cadastro e verificação de identidade (KYC/KYB) realizado na plataforma Carrot, operada pela Carrot Foundation. As informações fornecidas pelo Usuário no formulário de cadastro — incluindo, sem limitação, nome completo ou razão social, CPF ou CNPJ, endereço, e-mail, dados de contato e demais informações de identificação, bem como eventuais documentos anexados — integram este Contrato por referência, como se aqui transcritos estivessem, e compõem o conjunto indissociável do instrumento contratual, tendo o Usuário plena ciência de que quaisquer alterações cadastrais posteriores, devidamente registradas na plataforma, passarão automaticamente a integrar este Contrato.
### A PLATAFORMA [#a-plataforma]
**CARROT FOUNDATION**
Fundação Suíça — arts. 80 e ss. do Código Civil Suíço.
Sede: Sielva Management SA, Gubelstrasse 11, Zug 6300, Suíça.
Tax ID: UID# CHE-152.448.302.
Presidente: Ian Clayton McKee.
[legal@carrot.eco](mailto:legal@carrot.eco)
A Carrot e o Usuário (em conjunto, as "Partes") aceitam e estabelecem os seguintes termos e condições:
## 1. OBJETO [#1-objeto]
> **✓ O que isso significa para você**
>
> Este contrato regula como você usa a plataforma Carrot e como funciona a parceria ambiental — do primeiro registro até o recebimento das suas recompensas.
1.1 Este Contrato regula o acesso e uso da Plataforma de Verificação Digital Ambiental (VDA/dMRV) pelo Usuário, incluindo o registro de ações de economia circular, a emissão de Créditos Ambientais Tokenizados (CRT/CCT) e a distribuição de Recompensas Ambientais aos Participantes elegíveis.
1.2 O Usuário reconhece que a Rede integra diferentes perfis — Geradores, Transportadores, Processadores, Recicladores/Destinadores, Integradores e Auditores — sendo que permissões, obrigações e percentuais de Recompensa de cada perfil estão detalhados nos Termos e Condições de Uso da plataforma (T\&C) e na Política de Distribuição de Recompensas, incorporados a este Contrato por referência.
> **✓ O que isso significa para você**
>
> Adesão por Referência: Seguindo o padrão global de empresas de tecnologia, este instrumento formaliza nossa união, enquanto os detalhes operacionais e metodologias técnicas permanecem no T\&C ([https://docs.carrot.eco/pt-BR/docs/terms/terms-and-conditions](https://docs.carrot.eco/pt-BR/docs/terms/terms-and-conditions)). Isso permite que o ecossistema evolua sem a necessidade de burocracias contratuais constantes, permitindo a escalabilidade do ecossistema.
1.3 Os documentos que integram este Contrato prevalecem pela seguinte ordem em caso de conflito: (a) T\&C ([https://docs.carrot.eco/pt-BR/docs/terms/terms-and-conditions](https://docs.carrot.eco/pt-BR/docs/terms/terms-and-conditions)); (b) Termos e Condições de Compra e Venda de Créditos Ambientais Tokenizados ([https://docs.carrot.eco/pt-BR/docs/terms/credit-sales-terms](https://docs.carrot.eco/pt-BR/docs/terms/credit-sales-terms)); (c) este instrumento; (d) Política de Privacidade ([https://docs.carrot.eco/pt-BR/docs/terms/privacy-policy](https://docs.carrot.eco/pt-BR/docs/terms/privacy-policy)) e Política de Distribuição de Recompensas ([https://docs.carrot.eco/pt-BR/docs/standard/policies/rewards-distribution](https://docs.carrot.eco/pt-BR/docs/standard/policies/rewards-distribution)).
## 2. ADESÃO AOS TERMOS E CONDIÇÕES [#2-adesão-aos-termos-e-condições]
> **✓ O que isso significa para você**
>
> Ao assinar este Contrato, você confirma que leu e entendeu as regras da plataforma.
>
> Quando as regras mudarem, você será avisado por e-mail com antecedência. Se não concordar, pode sair sem custo.
2.1 O Usuário declara ter lido, compreendido e aceito integralmente: (a) os Termos e Condições de Uso ([https://docs.carrot.eco/pt-BR/docs/terms/terms-and-conditions](https://docs.carrot.eco/pt-BR/docs/terms/terms-and-conditions)) e (b) os Termos e Condições de Compra e Venda de Créditos de Reciclagem e de Carbono Tokenizados ([https://docs.carrot.eco/pt-BR/docs/terms/credit-sales-terms](https://docs.carrot.eco/pt-BR/docs/terms/credit-sales-terms)).
2.2 A Plataforma poderá atualizar este Contrato ou os documentos a ele incorporados para refletir mudanças operacionais, tecnológicas ou legais. O Usuário será notificado por e-mail com antecedência mínima de 15 (quinze) dias antes da entrada em vigor das alterações.
2.3 Caso o Usuário não concorde com qualquer atualização, poderá encerrar sua conta sem ônus antes da data de vigência. A ausência de manifestação será interpretada como aceite.
2.4 As comunicações oficiais ocorrerão por e-mail. O Usuário compromete-se a manter seu endereço de e-mail atualizado.
2.5 O Usuário deverá fornecer, no processo KYC/KYB (Identificação de Cliente/Identificação de Empresa), informações de identificação verdadeiras e completas. Em caso de pessoa jurídica, o representante legal deverá comprovar sua representação.
## 3. COMO SEU IMPACTO AMBIENTAL SE TORNA UM ATIVO DE VALOR [#3-como-seu-impacto-ambiental-se-torna-um-ativo-de-valor]
> **✓ O que isso significa para você**
>
> Para que seu impacto ambiental tenha valor de mercado, precisamos demonstrar aos compradores de créditos que o sistema de validação, verificação e mensuração da emissão dos créditos é completo e preciso e que a mensuração do impacto gerado é calculada de forma conservadora.
>
> Também é fundamental para a integridade dos créditos que não exista a possibilidade de dupla contagem, ou seja, as massas enviadas ao programa de geração de créditos da Carrot não podem também ser enviadas a outro sistema de geração de créditos.
>
> Isso é o que garante que o comprador pague por ele — e que você receba a sua parte. Por isso, ao registrar uma ação na plataforma, você nos transfere exclusivamente o direito de emitir e vender o crédito daquela ação específica.
>
> Você continua livre para sair da plataforma quando quiser. O que não pode fazer é registrar a mesma ação em outro lugar — isso destruiria o valor do crédito em específico, como também a reputação do sistema, prejudicando a todos os outros participantes.
3.1 Para que seu impacto ambiental tenha valor de mercado, a Plataforma precisa ser a única entidade autorizada a emitir o crédito associado a cada ação registrada. Essa exclusividade é o que garante ao comprador que o crédito é único, verificado e íntegro — e é o que garante a você que receberá sua parcela do resultado. Por isso, ao registrar uma ação na plataforma, o Usuário transfere à Plataforma, de forma exclusiva e irrevogável, o direito de emitir e vender o Crédito Ambiental Tokenizado (CRT/CCT) correspondente a essa ação específica, incluindo os direitos de reporte ambiental (por meio de créditos aposentados) e as Declarações Ambientais e Sociais ("Environmental & Social Claims") dela decorrentes, conforme Seção 4 do T\&C. O comprador, a partir da aposentadoria do crédito, se apropriará do direito de declarar a compensação ambiental (Environmental Claim).
3.2 Essa transferência de direitos tem alcance restrito à ação registrada: o Usuário cede o direito sobre o crédito daquela ação — não sobre sua empresa, suas operações futuras ou qualquer outro ativo.
3.2.1 A transferência de direitos prevista nesta Cláusula 3 não reflete nem implica qualquer valor monetário presente nos dados ou nas ações ambientais compartilhadas pelo Usuário. O valor comercial de qualquer Declaração Ambiental e Social surge exclusivamente da aplicação da Metodologia pela Plataforma, da validação da ação de economia circular, da emissão do crédito ou token correspondente e de sua efetiva venda a um Token Buyer — ciclo que pode ou não ser concluído. Nenhum Usuário individual detém titularidade sobre qualquer MassID, uma vez que o ganho ambiental representado por cada crédito resulta da contribuição coletiva de múltiplos Participantes da cadeia de custódia, cada qual recebendo apenas sua parcela proporcional dos resultados, conforme a Política de Distribuição de Recompensas, quando houver venda efetiva. O caráter exclusivo e irrevogável da transferência serve exclusivamente para preservar a integridade do programa de créditos, em proteção de todos os Participantes, Token Buyers e do ecossistema como um todo. Nenhuma responsabilidade recai sobre a Plataforma exclusivamente em razão desta transferência na hipótese de o Token não ser emitido ou vendido em conexão com a respectiva ação de economia circular.
3.3 A Plataforma Carrot, após validação de dados da ação de Economia Circular (MassID, ProductID) e confirmados por documentos oficiais do local (ex. Manifesto de Transporte de Resíduos (MTR) e/ou documentos equivalentes), detém direito exclusivo de emitir e vender os créditos (CRT/CCT) relacionados ao MassID. A rastreabilidade da massa, MassID, identificando os participantes da rota final até um reciclador auditado e homologado pela Fundação Carrot, e a comprovação da destinação final via MTR com dados verificados pelo sistema da Carrot são os únicos requisitos para a validade da emissão no Brasil. A venda dos créditos não está condicionada ao onboarding prévio de outros Participantes da Cadeia de Custódia além do Reciclador — apenas à identificação dos participantes da rota final. (Obs.: as recompensas atribuídas aos demais participantes ficarão disponíveis por um período determinado.)
3.4 Registrar a mesma ação ambiental em outro sistema de certificação e emissão de créditos — total ou parcialmente — configura dupla contagem. Isso compromete a integridade do crédito vendido ao comprador e do programa de créditos da Carrot. Isso prejudica os demais participantes da rede e sujeita o Usuário a suspensão imediata, devolução de valores recebidos e responsabilização civil e penal, nos termos do item 11 do T\&C.
3.5 O encerramento da conta pelo Usuário não afeta a transferência de direitos realizada sobre ações já registradas e validadas antes do encerramento. Os créditos correspondentes permanecem válidos e as recompensas serão distribuídas normalmente.
## 4. SUAS RECOMPENSAS AMBIENTAIS · COMO FUNCIONA O RETORNO FINANCEIRO [#4-suas-recompensas-ambientais--como-funciona-o-retorno-financeiro]
> **✓ O que isso significa para você**
>
> Quando um comprador adquire o crédito gerado pela sua ação, você recebe automaticamente a sua parte do resultado — sem precisar fazer nada além de registrar os dados corretamente.
>
> Você tem 90 dias para fornecer uma carteira digital para receber as recompensas e sacar o valor.
>
> Tudo funciona via contrato inteligente, sem intermediários.
>
> O quanto você recebe depende do seu papel na cadeia e do valor de venda do crédito — os percentuais estão na Política de Distribuição de Recompensas.
> **⚖ Natureza jurídica da Recompensa — com efeito tributário**
>
> As Recompensas constituem distribuição de parcela dos resultados obtidos pela Plataforma na venda dos Créditos a terceiros compradores.
>
> As Recompensas NÃO configuram, para nenhum efeito jurídico ou fiscal: (a) contraprestação por serviço prestado pelo Usuário; (b) remuneração, salário ou honorário; (c) produto de venda de bem ou direito pelo Usuário; nem (d) receita operacional própria do Usuário.
>
> Cada parte é individualmente responsável pelos tributos que lhe couberem sobre os valores recebidos, nos termos da Cláusula 6.
4.1 A Plataforma distribuirá ao Usuário, de forma automatizada por meio de Contratos Inteligentes, uma parcela dos resultados obtidos na venda dos Créditos Ambientais, conforme os percentuais definidos na Política de Distribuição de Recompensas vigente na data de cada venda ([https://docs.carrot.eco/pt-BR/docs/standard/policies/rewards-distribution](https://docs.carrot.eco/pt-BR/docs/standard/policies/rewards-distribution)).
4.2 As Recompensas constituem, para todos os fins jurídicos e fiscais, distribuição de resultado de operação comercial realizada pela Plataforma — não contraprestação por serviço, produto de venda ou remuneração pelo Usuário. Essa qualificação tem efeito vinculante entre as Partes.
4.3 O direito à Recompensa está condicionado a: (a) conclusão do onboarding com aprovação no KYC/KYB; (b) aceite integral deste Contrato e dos documentos incorporados; e (c) validação dos dados da ação ambiental pela metodologia aplicável.
4.4 O prazo para saque é de 90 (noventa) dias corridos a partir da disponibilização no Contrato Inteligente. Transcorrido esse prazo sem resgate, o valor será transferido ao Fundo de Impacto Comunitário (Community Impact Pool), extinguindo-se o direito do Usuário sobre aquele montante.
4.5 A Plataforma não garante valor mínimo de Recompensa nem prazo determinado para a ocorrência de vendas. As Recompensas são condicionadas à efetiva comercialização dos Créditos Ambientais junto a compradores. Na hipótese de os Créditos não serem vendidos, nenhuma Recompensa será devida, e o Usuário não terá direito a qualquer compensação, ressarcimento ou contraprestação em razão da ausência de venda. O Usuário declara ciência de que a transferência de direitos prevista na Cláusula 3 não gera, por si só, direito adquirido a recebimento de valores.
4.6 As Recompensas serão pagas em USDC, conforme Política de Distribuição. O Usuário é responsável por manter carteira digital ativa e compatível. A Plataforma não se responsabiliza por perda de acesso à carteira.
**Responsabilidade especial do Reciclador / Destinador**
4.7 O Reciclador homologado que atua como Destinador Final e Desenvolvedor de Projeto (Project Developer) assume responsabilidade pela destinação e tratamento final do resíduo e pelo convite ativo aos demais participantes da cadeia (Gerador, Transportador, Processador) para que realizem o onboarding e resgatem suas Recompensas dentro do prazo de 90 dias, tratando seus dados em conformidade com a LGPD.
## 5. PROTEÇÃO DE DADOS PESSOAIS — LGPD [#5-proteção-de-dados-pessoais--lgpd]
> **✓ O que isso significa para você**
>
> Coletamos apenas os dados necessários para validar sua identidade, registrar suas ações, verificar e certificar créditos e transferir suas Recompensas.
>
> Dados sensíveis ficam em servidores criptografados. Nenhum dado é publicado sem sua autorização.
>
> Você pode acessar, corrigir ou pedir exclusão dos seus dados: [operations@carrot.eco](mailto:operations@carrot.eco).
As Partes garantem a observância da Lei nº 13.709/2018 (LGPD) e comprometem-se a tratar dados pessoais exclusivamente para as finalidades deste Contrato.
**5.1 Papéis na LGPD**
5.1.1 Para os dados que o Usuário insere sobre suas próprias operações (MassIDs, dados de geração, informações de colaboradores), o Usuário atua como Controlador e a Plataforma como Operadora.
5.1.2 Para os dados necessários ao KYC/KYB, emissão de Créditos e distribuição de Recompensas, a Plataforma atua como Controladora independente.
5.1.3 Uma parte não será responsabilizada por atos ou infrações à legislação de proteção de dados praticados pela outra parte, seus prepostos e/ou contratados. Para entender como seus dados pessoais são coletados, tratados, armazenados e protegidos pela Plataforma, consulte nossa Política de Privacidade e Proteção de Dados, disponível em ([https://docs.carrot.eco/pt-BR/docs/terms/privacy-policy](https://docs.carrot.eco/pt-BR/docs/terms/privacy-policy)) elaborada em conformidade com a Lei nº 13.709/2018 (LGPD).
**5.2 Obrigações das Partes**
* Promover cultura de proteção de dados entre colaboradores.
* Adotar medidas de segurança aptas a proteger os dados de acessos não autorizados.
* Eliminar ou anonimizar os dados após atingida a finalidade ou encerrado o Contrato.
* Manter plano de resposta a incidentes e programa ativo de governança de dados.
**5.3 Tratamento específico de dados**
5.3.1 O Usuário consente que seus dados de identificação sejam utilizados para: (i) identificação e validação dos participantes (KYC/KYB); (ii) rastreabilidade da cadeia de custódia; (iii) emissão de Créditos; (iv) distribuição de Recompensas; (v) cumprimento de obrigações legais; e (vi) reconhecimento público de impacto ambiental da organização, nos termos da Seção 7A dos Termos e Condições Globais (Impact Recognition Program), podendo o Usuário revogar essa autorização a qualquer momento mediante notificação escrita a [legal@carrot.eco](mailto:legal@carrot.eco).
5.3.2 Dados de Geradores e Transportadores serão mascarados nas interfaces públicas, visíveis apenas à Plataforma e a Auditores homologados. Visibilidade pública depende de consentimento expresso no onboarding.
5.3.3 A Plataforma implementa criptografia TLS/SSL em trânsito e AES-256 em repouso. Dados identificadores não são gravados diretamente on-chain — utiliza-se hashing para rastreabilidade sem exposição de identidade.
5.3.4 O descumprimento das obrigações da LGPD pelo Usuário poderá ensejar rescisão imediata deste Contrato.
5.3.5 Em caso de incidente de segurança com risco relevante, a Plataforma notificará o Usuário e a ANPD nos prazos legais.
## 6. RESPONSABILIDADE TRIBUTÁRIA [#6-responsabilidade-tributária]
> **Em linguagem simples**
>
> Cada parte é responsável pelos próprios impostos. A Plataforma não retém nem recolhe imposto em nome do Usuário — exceto quando a lei expressamente obrigar.
>
> A Recompensa que você recebe não é salário, não é nota de serviço. Mas pode ter incidência de Imposto de Renda dependendo do valor e da sua situação fiscal.
>
> Recomendamos fortemente que você consulte um contador ou advogado tributarista.
6.1 Cada Parte é exclusivamente responsável pelo cumprimento de suas obrigações tributárias perante as autoridades fiscais de sua jurisdição.
6.2 As Recompensas constituem distribuição de resultado de operação comercial de terceiro — não receita de serviços nem produto de alienação de bem. Essa qualificação não exclui a possível incidência de tributos sobre o ingresso patrimonial, cuja apuração é de responsabilidade exclusiva do Usuário.
6.3 A recompensa é distribuída para todos os participantes no mesmo formato globalmente, utilizando a moeda digital (stablecoin) USDC depositada na carteira digital do participante. O Usuário declara ciência de que operações com criptoativos podem estar sujeitas a declaração perante a Receita Federal (IN RFB nº 1.888/2019 e alterações) e ao recolhimento de IR sobre ganho de capital, quando aplicável.
6.4 Caso o usuário escolha não receber suas recompensas, o valor será automaticamente destinado ao Fundo da Comunidade (Community Pool) da Carrot, voltado para fomentar o desenvolvimento da economia circular. Usuários poderão também declarar a destinação de suas recompensas para o Community Pool durante o onboarding ou a qualquer momento, ou mesmo trocá-las por créditos aposentados para compensação ambiental, fomentando o crescimento do próprio ecossistema do qual participam.
6.5 A Plataforma não presta aconselhamento fiscal e não assume responsabilidade por obrigações tributárias do Usuário. O Usuário concorda em indenizar a Plataforma de qualquer responsabilidade decorrente do não cumprimento de suas obrigações fiscais.
## 7. RESPONSABILIDADES DAS PARTES [#7-responsabilidades-das-partes]
> **✓ O que isso significa para você**
>
> Somos responsáveis pela segurança e funcionamento da plataforma.
>
> Você é responsável pela veracidade dos dados que inserir.
>
> Se algo der errado por falha nossa, nossa responsabilidade se limita ao maior valor entre: as recompensas que você recebeu nos últimos 12 meses, ou o valor das ações ambientais que você nos transferiu e que deram origem ao problema.
>
> Não somos responsáveis por perdas indiretas, lucros cessantes ou variação no valor dos créditos ou tokens.
**7.1 Obrigações da Plataforma**
* Manter a infraestrutura tecnológica disponível e segura.
* Validar os dados ambientais conforme as metodologias aplicáveis.
* Emitir e comercializar os Créditos Ambientais com diligência.
* Distribuir as Recompensas conforme a Política de Distribuição vigente.
* Comunicar com antecedência qualquer alteração relevante nos termos.
**7.2 Obrigações do Usuário**
* Fornecer dados verdadeiros, completos e atualizados.
* Não registrar os mesmos dados ambientais em outros programas de geração de créditos de reciclagem ou de carbono (Cláusula 3.4).
* Manter credenciais de acesso e carteira digital com segurança.
* Comunicar à Plataforma Carrot qualquer irregularidade de que tome conhecimento.
* Cumprir o Código de Conduta previsto no T\&C.
7.3 O Usuário aceita e reconhece os riscos relacionados ao uso da plataforma, conforme detalhados no T\&C. A Plataforma não se responsabiliza por riscos inerentes ao uso de blockchain ou criptoativos fora de seu controle.
7.4 A responsabilidade da Plataforma por perdas diretas decorrentes de falha sua fica limitada ao valor pago pelo Usuário à Plataforma nos 12 (doze) meses anteriores ao evento. São expressamente excluídos danos indiretos, lucros cessantes, danos reputacionais e perdas por variação de valor de créditos, tokens ou criptoativos.
7.5 A divulgação de Declarações Ambientais e Sociais para o mesmo dado junto a terceiros configura dupla contagem e é expressamente vedada, nos termos da Cláusula 3.4 e do item 11 do T\&C.
7.6 A Plataforma não é responsável por erros no registro de ações de economia circular causados por dados incorretos ou incompletos submetidos pelo Usuário ou por Integradores de Rede. No entanto, a Plataforma responde pelos danos diretos causados por erros de registro atribuíveis aos seus próprios sistemas ou processos, sujeito ao teto estabelecido na Cláusula 7.4.
## 8. LEI APLICÁVEL E RESOLUÇÃO DE CONFLITOS [#8-lei-aplicável-e-resolução-de-conflitos]
> **✓ O que isso significa para você**
>
> Para a sua relação de uso da plataforma no Brasil, aplicam-se as leis brasileiras — foro de São Paulo.
>
> Para os Créditos Ambientais Tokenizados, aplica-se a lei suíça — mais adequada para esse instrumento financeiro internacional.
>
> Tentamos resolver tudo amigavelmente antes de qualquer medida judicial.
8.1 O presente Contrato será regido e interpretado de acordo com as leis da República Federativa do Brasil. As Partes elegem o Foro Central da Comarca de São Paulo, Estado de São Paulo, para dirimir quaisquer controvérsias relativas à relação de uso da Plataforma.
8.2 A emissão, transferência e venda dos Créditos Ambientais Tokenizados são regidas pela legislação suíça, aplicável à Carrot Fndn como fundação constituída em Zug, Suíça.
8.3 Em caso de conflito entre este Contrato e os Termos e Condições (T\&C), as disposições do T\&C prevalecerão, conforme Cláusula 1.3.
8.4 As Partes comprometem-se a buscar solução amigável para qualquer divergência, mediante notificação prévia e prazo de 30 (trinta) dias para negociação direta, antes de qualquer medida judicial.
8.5 Sem prejuízo da escolha de lei estabelecida nas Cláusulas 8.1 e 8.2, e em conformidade com a Seção 21.4 dos Termos e Condições Globais (T\&C), as disposições de ordem pública e as normas imperativas da legislação brasileira aplicáveis ao Usuário — incluindo, sem limitação, o Código de Defesa do Consumidor (Lei 8.078/1990), a Lei Geral de Proteção de Dados (Lei 13.709/2018) e o Marco Legal dos Criptoativos (Lei 14.478/2022) — aplicar-se-ão na medida em que não possam ser afastadas por convenção entre as partes. A aplicação de normas imperativas locais não afeta a validade ou exequibilidade das demais cláusulas deste Contrato, nem constitui renúncia à lei suíça como lei aplicável para as matérias que as partes possam livremente contratar.
## 9. DISPOSIÇÕES GERAIS [#9-disposições-gerais]
9.1 Invalidade parcial: Se qualquer cláusula for inválida ou inexequível, as demais permanecem vigentes. A cláusula inválida será interpretada da forma mais próxima à intenção original das Partes.
9.2 Tolerância: A omissão de qualquer Parte no exercício de seus direitos não configura renúncia, novação ou precedente.
9.3 Cessão: O Usuário não pode ceder este Contrato a terceiros sem anuência prévia e escrita da Plataforma. A Plataforma pode ceder direitos a entidade sucessora, mediante notificação ao Usuário.
9.4 Serviços adicionais: Mediante aviso prévio e aceite do Usuário, a Plataforma poderá cobrar por serviços adicionais como armazenamento de dados e certificação de circularidade, conforme item 8 do T\&C.
9.5 Integralidade: Este Contrato e os documentos a ele incorporados constituem o inteiro teor do acordo entre as Partes, substituindo entendimentos anteriores sobre o mesmo objeto.
## 10. DO ACEITE ELETRÔNICO [#10-do-aceite-eletrônico]
10.1 Do Aceite Eletrônico. O aceite deste Contrato pelo Usuário se dá por meio de manifestação eletrônica inequívoca, consistente em ato afirmativo de marcação do campo próprio de aceite na plataforma, após disponibilização integral do presente instrumento e dos demais documentos a ele vinculados para leitura, e imediatamente seguida do registro em sistema de: (i) data e hora sincronizadas; (ii) endereço IP; (iii) identificador do dispositivo e navegador (user agent); (iv) geolocalização aproximada, quando disponível; e (v) código hash SHA-256 da versão específica do Contrato então vigente. Essa manifestação equivale à assinatura eletrônica para todos os efeitos legais, nos termos do art. 10, §2º, da Medida Provisória nº 2.200-2/2001, do art. 4º, inciso I, da Lei nº 14.063/2020 e do art. 107 do Código Civil, sendo reconhecida pelas Partes como meio válido, eficaz e suficiente para a formalização deste instrumento, dispensando qualquer outra forma de assinatura. O Usuário poderá, a qualquer tempo, solicitar o comprovante de aceite contendo os elementos acima por meio dos canais oficiais da Carrot.
10.2 Provedor de Assinatura. Para os fins desta cláusula e do art. 784, §4º, do Código de Processo Civil, a Plataforma atua como provedor de assinatura, sendo responsável pela verificação e preservação da integridade do documento eletrônico por meio dos mecanismos técnicos descritos no parágrafo anterior, bem como pela custódia e disponibilização, mediante requisição do Usuário ou de autoridade competente, da respectiva trilha de auditoria.
10.3 Título Executivo Extrajudicial. As Partes reconhecem expressamente que o presente instrumento, uma vez aceito eletronicamente na forma desta cláusula, constitui título executivo extrajudicial, nos termos do art. 784, inciso III e §4º, do Código de Processo Civil, com a redação dada pela Lei nº 14.195/2021, sendo dispensada a assinatura de testemunhas em razão da conferência da integridade pelo provedor de assinatura indicado acima.
***
Dúvidas jurídicas: [legal@carrot.eco](mailto:legal@carrot.eco) · Suporte operacional: [operations@carrot.eco](mailto:operations@carrot.eco)
Este documento substitui todas as versões anteriores do Contrato de Uso da Plataforma Carrot.
# Política de Privacidade
{/* cspell:words Fndn LGPD GDPR revDSG ANPD FDPIC CCPA DPRK COAF criptoativos suboperadores homologação homologados */}
**Versão 1.0 — Março de 2026**
Encarregado de Dados (DPO): [legal@carrot.eco](mailto:legal@carrot.eco)
## 1. Introdução e Âmbito de Aplicação [#1-introdução-e-âmbito-de-aplicação]
A Carrot Fndn é uma fundação suíça constituída nos termos dos artigos 80 e seguintes do Código Civil Suíço, com sede em Zug, Suíça (Tax ID: UID# CHE-152.448.302), que desenvolve e opera a Rede Carrot — plataforma tecnológica que combina infraestrutura de nuvem (*cloud*) e *blockchain* para rastreamento de ações de economia circular e emissão de Créditos Ambientais Tokenizados (TRC/TCC).
Esta Política de Privacidade e Proteção de Dados ("Política") descreve como a Carrot Fndn coleta, trata, armazena, compartilha e protege dados pessoais, em conformidade com:
* Lei nº 13.709/2018 — Lei Geral de Proteção de Dados Pessoais (LGPD);
* Resolução CD/ANPD nº 15/2024 — procedimento de comunicação de incidentes de segurança à ANPD;
* Lei nº 14.478/2022 — Marco Legal dos Criptoativos e regulamentação do Banco Central do Brasil aplicável a Prestadores de Serviços de Ativos Virtuais (PSAVs), no que couber;
* Regulamento Geral sobre Proteção de Dados (GDPR — Regulamento UE 2016/679), no que aplicável a titulares residentes no Espaço Econômico Europeu;
* Lei Federal Suíça de Proteção de Dados (revDSG — em vigor desde 1º de setembro de 2023), aplicável às operações da Fundação em razão de sua sede em Zug, Suíça.
Esta Política aplica-se a todos os Usuários que acessam os sites e subdomínios operados pela Carrot Fndn sob o domínio carrot.eco, incluindo, sem limitação: [www.carrot.eco](http://www.carrot.eco), registry.carrot.eco, store.carrot.eco, docs.carrot.eco e my.carrot.eco, bem como quaisquer outros subdomínios que venham a ser criados, a Rede Carrot e seus contratos inteligentes, ou que interagem com a Fundação em qualquer capacidade.
> **Nota sobre jurisdição**
>
> Para os fins da LGPD, a Carrot Fndn pode atuar como Controladora ou Operadora de dados pessoais, conforme o contexto da operação (detalhado na Seção 2). A lei aplicável ao relacionamento de uso da Plataforma no Brasil é a legislação brasileira; a lei suíça (revDSG) rege as operações da Fundação e a emissão e venda dos Créditos Ambientais Tokenizados.
## 2. Papéis e Responsabilidades no Tratamento de Dados [#2-papéis-e-responsabilidades-no-tratamento-de-dados]
A definição dos papéis de cada parte no tratamento de dados é fundamental para a correta atribuição de responsabilidades nos termos do art. 5º, incs. VI e VII, da LGPD e do art. 4º do GDPR.
### 2.1 Quando o Usuário é o Controlador [#21-quando-o-usuário-é-o-controlador]
Para os dados que o Usuário insere na Plataforma sobre suas próprias operações — incluindo dados de colaboradores, clientes, Geradores, Transportadores e Processadores —, o Usuário atua como Controlador, cabendo-lhe garantir a licitude do tratamento antes de compartilhá-los com a Plataforma. Cabe destacar que, na maioria dos casos, esses dados são enviados à Rede Carrot diretamente pelos *Network Integrators*, em nome do Usuário Controlador.
### 2.2 Quando a Carrot é Operadora [#22-quando-a-carrot-é-operadora]
A Carrot Fndn atua como Operadora quando processa dados pessoais por conta e em nome do Usuário Controlador — por exemplo, ao validar dados inseridos pelos *Network Integrators* para fins de emissão de créditos.
### 2.3 Quando a Carrot é Controladora Independente [#23-quando-a-carrot-é-controladora-independente]
A Carrot Fndn atua como Controladora independente nos tratamentos que realiza por conta própria, tais como:
* KYC/KYB — identificação e verificação de Usuários, realizada diretamente ou por meio de provedores terceiros especializados;
* Distribuição de Recompensas (*Rewards*) via contratos inteligentes;
* Cumprimento de obrigações legais e regulatórias, incluindo as decorrentes da Lei nº 14.478/2022;
* Prevenção a fraudes, lavagem de dinheiro (AML) e financiamento ao terrorismo (CFT);
* Processo de homologação (*accreditation*) de participantes realizado diretamente pela Carrot Fndn.
### 2.4 Network Integrators e Validadores como Suboperadores [#24-network-integrators-e-validadores-como-suboperadores]
Os *Network Integrators* são aplicativos e plataformas de terceiros que se integram à Rede Carrot por meio de APIs para registrar eventos da cadeia de custódia de resíduos. Ao inserir dados pessoais de participantes da cadeia (Geradores, Transportadores, Processadores) na Plataforma, os *Network Integrators* atuam como Suboperadores da Carrot Fndn, nos termos do art. 39 da LGPD.
A admissão de *Network Integrators* à Rede Carrot está condicionada à celebração de Acordo de Processamento de Dados (*Data Processing Agreement — DPA*) com a Carrot Fndn, que estabelecerá as obrigações de conformidade, os limites do tratamento e as medidas de segurança exigíveis. A Carrot Fndn manterá registro atualizado dos *Network Integrators* homologados em [www.carrot.eco](http://www.carrot.eco).
Os Validadores e Auditores são agentes autorizados que confirmam transações e certificam operações ao longo da cadeia de custódia. Quando o exercício de suas funções implica acesso a dados pessoais contidos em MassIDs ou registros de auditoria, esses agentes operam como Suboperadores limitados, com acesso restrito ao mínimo necessário para a validação ou certificação da operação correspondente, igualmente sujeitos a DPA.
*Independentemente do papel exercido, uma parte não será responsabilizada por atos, omissões ou infrações à legislação de proteção de dados praticados pela outra parte, seus prepostos e/ou contratados (cf. art. 42, §3º, LGPD).*
## 3. Tecnologia: Infraestrutura Cloud e Blockchain [#3-tecnologia-infraestrutura-cloud-e-blockchain]
A Carrot Fndn adota arquitetura de dados que combina armazenamento em nuvem (*off-chain*) e em *blockchain* (*on-chain*), com o objetivo de garantir simultaneamente rastreabilidade, auditabilidade e privacidade dos titulares.
### 3.1 Dados Off-chain (Servidores em Nuvem) [#31-dados-off-chain-servidores-em-nuvem]
Informações pessoais sensíveis — nome, e-mail, documentos de identificação, dados KYC/KYB — são armazenadas em infraestrutura de nuvem segura, atualmente hospedada em servidores localizados nos Estados Unidos da América (provedores como AWS e *Google Cloud*), com criptografia em repouso (AES-256) e em trânsito (TLS 1.2+). Esses dados são passíveis de acesso, correção e exclusão pelo titular, conforme a Seção 7. Para o componente de login tradicional da Plataforma, existe mecanismo de recuperação de senha, diferentemente do acesso a carteiras digitais (tratado na Seção 8.3).
### 3.2 Dados On-chain (Blockchain) [#32-dados-on-chain-blockchain]
Registros de transações de economia circular, emissão de créditos (TRC/TCC) e hashes de validação são gravados de forma imutável na *blockchain*. Em atenção ao princípio da privacidade desde a concepção (*privacy by design*), a Carrot Fndn não grava dados pessoais identificáveis diretamente on-chain de forma pública: utiliza-se técnica de *hashing* criptográfico para preservar a integridade das informações sem expor a identidade do titular.
> **Procedimento de anonimização on-chain**
>
> Quando o titular exercer o direito de eliminação previsto no art. 18, IV, da LGPD em relação a dados gravados on-chain, a Carrot Fndn adotará o seguinte procedimento: (i) exclusão definitiva do dado pessoal identificador nos registros off-chain; (ii) invalidação do mapeamento entre o endereço de carteira pública (*wallet address*) e a identidade do titular no banco de dados da Fundação; (iii) emissão de certidão de anonimização ao titular no prazo de 30 (trinta) dias. O hash remanescente *on-chain* manterá a integridade das transações ambientais sem permitir a reidentificação do titular.
## 4. Coleta, Finalidade e Base Legal do Tratamento [#4-coleta-finalidade-e-base-legal-do-tratamento]
A Carrot Fndn coleta exclusivamente os dados necessários ao cumprimento das finalidades descritas nesta Política, em observância ao princípio da necessidade (art. 6º, inc. III, LGPD).
### 4.1 Categorias de Dados Coletados [#41-categorias-de-dados-coletados]
| Categoria | Exemplos | Finalidade |
| ------------------------------------- | --------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ |
| **Dados de Cadastro (KYC/KYB)** | Nome, CPF/CNPJ, e-mail, documento de identidade, endereço, representação legal | Verificação de identidade, conformidade regulatória e cumprimento da Lei 14.478/2022 |
| **Dados Web3** | Endereço de carteira pública (*wallet address*) | Processamento de Recompensas e registro de ativos ambientais |
| **Dados de Operação** | Origem, massa e tipo de resíduo; MassID; ProductID; MTR | Emissão e validação de Créditos Ambientais Tokenizados |
| **Dados de Navegação e Rastreamento** | Endereço IP, data/hora de acesso, logs de sessão, cookies funcionais e analíticos | Segurança da Rede, prevenção a fraudes e funcionamento da Plataforma (ver Seção 5) |
| **Dados Financeiros** | Conta para recebimento, histórico de Recompensas, operações com criptoativos | Distribuição de Recompensas, cumprimento de obrigações fiscais e AML/CFT |
#### 4.1.1 Uso de dados de cadastro para reconhecimento público (Seção 7A do T\&C) [#411-uso-de-dados-de-cadastro-para-reconhecimento-público-seção-7a-do-tc]
O nome, logotipo e website da organização Participante, que fazem parte dos dados coletados no processo de cadastro (KYC/KYB), poderão também ser utilizados para fins de reconhecimento público de impacto ambiental, nos termos da Seção 7A dos [Termos e Condições](/docs/terms/terms-and-conditions) Globais (*Impact Recognition Program*).
Essa utilização é condicionada à autorização concedida pelo Usuário ao aceitar os Termos e Condições, podendo ser revogada a qualquer momento mediante notificação escrita a [legal@carrot.eco](mailto:legal@carrot.eco), sem prejuízo das divulgações realizadas anteriormente.
### 4.2 Base Legal do Tratamento [#42-base-legal-do-tratamento]
O tratamento de dados pessoais pela Carrot Fndn está fundamentado nas seguintes hipóteses legais do art. 7º da LGPD:
* **Execução de contrato** (art. 7º, inc. V): tratamento necessário à prestação dos serviços contratados pelo Usuário;
* **Cumprimento de obrigação legal ou regulatória** (art. 7º, inc. II): KYC/KYB, obrigações fiscais, reportes regulatórios e cumprimento da Lei nº 14.478/2022, Resolução BCB nº 1/2020 e obrigações AML/CFT;
* **Legítimo interesse** (art. 7º, inc. IX): utilizado especificamente para (i) prevenção a fraudes e segurança da Rede; (ii) detecção de anomalias e ataques; (iii) melhoria técnica dos serviços; e (iv) reconhecimento público de impacto ambiental dos Participantes, incluindo a divulgação de nome, logotipo e website da organização em canais institucionais da Carrot Fndn, nos termos da Seção 7A dos [Termos e Condições](/docs/terms/terms-and-conditions) (*Impact Recognition Program*). O uso desta base está condicionado ao teste de proporcionalidade e documentado em Relatório de Impacto à Proteção de Dados (RIPD) mantido internamente;
* **Consentimento** (art. 7º, inc. I): para cookies não essenciais e finalidades de marketing, coletado de forma específica, destacada e inequívoca no momento do primeiro acesso.
### 4.3 Dados que Não Coletamos [#43-dados-que-não-coletamos]
A Carrot Fndn não coleta, em nenhuma circunstância: chaves privadas de carteira (private keys), frases de recuperação (seed phrases) ou quaisquer credenciais que permitam acesso direto aos ativos digitais do Usuário.
### 4.4 Uso da Plataforma por Menores [#44-uso-da-plataforma-por-menores]
Os serviços da Carrot Fndn são destinados exclusivamente a pessoas físicas maiores de 18 (dezoito) anos e a pessoas jurídicas representadas por seus representantes legais, nos termos do art. 14 da LGPD e do art. 8º do GDPR. Ao utilizar a Rede Carrot, o Usuário declara ter capacidade civil plena. Caso o Usuário seja pessoa jurídica, o representante legal declara ter poderes para aceitar esta Política em nome da entidade.
Caso a Carrot Fndn identifique que dados de menor de idade foram inadvertidamente coletados sem o consentimento verificável dos pais ou responsáveis legais, tais dados serão imediatamente eliminados. Usuários que tomarem conhecimento de tal situação devem comunicar o DPO pelo endereço [legal@carrot.eco](mailto:legal@carrot.eco).
### 4.5 Decisões Automatizadas [#45-decisões-automatizadas]
A Rede Carrot utiliza contratos inteligentes (*smart contracts*) para processar automaticamente decisões com efeitos sobre o Usuário, incluindo:
* (i) cálculo e distribuição de Recompensas com base na cadeia de custódia de resíduos registrada nos MassIDs;
* (ii) validação ou rejeição de MassIDs para fins de emissão de Créditos Ambientais Tokenizados;
* (iii) suspensão temporária de participantes identificados como potencialmente irregulares pelos Auditores da Rede.
Nos termos do art. 20 da LGPD, o Usuário tem direito de solicitar revisão humana de qualquer decisão automatizada que lhe afete significativamente, incluindo suspensões e bloqueios de Recompensas. A solicitação deve ser encaminhada ao DPO ([legal@carrot.eco](mailto:legal@carrot.eco)), com descrição da decisão contestada, e será respondida em até 15 dias úteis, podendo ser prorrogado por mais 15 dias corridos.
## 5. Cookies e Tecnologias de Rastreamento [#5-cookies-e-tecnologias-de-rastreamento]
A Carrot Fndn utiliza *cookies* e tecnologias similares em seus sites para garantir o funcionamento adequado da Plataforma, analisar o desempenho e aprimorar a experiência do Usuário.
### 5.1 Categorias de Cookies [#51-categorias-de-cookies]
| Categoria | Finalidade | Ferramentas / Destino | Base Legal |
| ------------------------ | ----------------------------------------------------------- | --------------------------------------------------------------------------------- | ------------------------------------------------------------- |
| Estritamente necessários | Autenticação de sessão, segurança e preferências essenciais | Infraestrutura própria Carrot (sem transferência) | Execução de contrato (art. 7º, V, LGPD) |
| Analíticos/Desempenho | Análise de tráfego e comportamento de navegação | Google Analytics 4 (GA4) — EUA via SCCs; Vercel Analytics — infraestrutura Vercel | Legítimo interesse (art. 7º, IX, LGPD) / Consentimento (GDPR) |
| Funcionais | Personalização de idioma, região e preferências do Usuário | Infraestrutura própria Carrot | Legítimo interesse (art. 7º, IX, LGPD) |
### 5.2 Gestão de Consentimento e Opt-out [#52-gestão-de-consentimento-e-opt-out]
No primeiro acesso a qualquer site operado pela Carrot Fndn, o Usuário será apresentado a um banner de consentimento de *cookies*, permitindo aceitar, recusar ou personalizar cada categoria não essencial. O consentimento é registrado com *timestamp* e pode ser revogado a qualquer tempo na página de [Política de Privacidade](/docs/terms/privacy-policy). A recusa de *cookies* não essenciais não impede o uso da Plataforma.
Para *opt-out* específico das ferramentas de análise:
* Google Analytics 4: instalar o complemento de desativação disponível em tools.google.com/dlpage/gaoptout;
* Vercel Analytics: desabilitar nas configurações de privacidade do navegador ou utilizar extensões de bloqueio compatíveis.
> **Transferência GA4 → EUA**
>
> O Google Analytics 4 transfere dados para servidores nos EUA. A Carrot Fndn adota as Cláusulas Contratuais Padrão (SCCs) da Comissão Europeia como salvaguarda. Para titulares brasileiros, a transferência é realizada com base no art. 33, VIII, da LGPD (consentimento específico) e no contrato de processamento de dados com o Google.
## 6. Compartilhamento, Sub-processadores e Transferência Internacional [#6-compartilhamento-sub-processadores-e-transferência-internacional]
Os dados pessoais poderão ser compartilhados com terceiros nas seguintes hipóteses e condições:
* **Parceiros tecnológicos e sub-processadores:** exclusivamente para viabilizar a operação da Plataforma, sob DPA com obrigações de confidencialidade e conformidade;
* **Auditores independentes homologados:** para fins de certificação e verificação ambiental, nos limites estritamente necessários;
* **Autoridades regulatórias, judiciais e supervisoras de ativos virtuais:** quando exigido por lei, ordem judicial ou regulação aplicável, incluindo o Banco Central do Brasil e o COAF, nos termos da Lei nº 14.478/2022, para cumprimento de obrigações de prevenção à lavagem de dinheiro (AML) e ao financiamento do terrorismo (CFT).
### 6.1 Principais Sub-processadores [#61-principais-sub-processadores]
| Sub-processador | Serviço | Localização dos dados | Salvaguarda |
| ------------------------- | ------------------------------------------- | --------------------- | ----------- |
| Amazon Web Services (AWS) | Infraestrutura de nuvem e armazenamento | EUA | SCCs |
| Google LLC (GCP / GA4) | Infraestrutura de nuvem e análise de dados | EUA | SCCs |
| Vercel Inc. | Hospedagem de sites e análise de desempenho | EUA | SCCs |
Alterações relevantes serão comunicadas com antecedência mínima de 30 (trinta) dias.
### 6.2 Transferência Internacional de Dados [#62-transferência-internacional-de-dados]
A Carrot Fndn opera com infraestrutura de nuvem hospedada nos Estados Unidos da América e com sede institucional na Suíça, o que implica transferências internacionais de dados pessoais. A Suíça possui reconhecimento de adequação pela Comissão Europeia para fins do GDPR. Para fins da LGPD brasileira, a ANPD ainda não publicou lista oficial de países com nível adequado de proteção; enquanto tal decisão não é formalizada, as transferências internacionais são realizadas com fundamento em:
* **Cláusulas Contratuais Padrão (SCCs):** adotadas com todos os sub-processadores internacionais, nos termos do art. 33, II, da LGPD, como salvaguarda principal para transferências Brasil → EUA e Brasil → Suíça;
* **Consentimento específico do titular:** (art. 33, VIII, LGPD), quando aplicável e coletado de forma destacada.
> **Nota sobre adequação ANPD**
>
> A afirmação de adequação da Suíça é válida apenas no contexto do GDPR (Comissão Europeia). Para a LGPD, enquanto a ANPD não publicar lista oficial, a salvaguarda vigente são as SCCs. Esta Política será atualizada quando houver decisão formal da ANPD.
## 7. Direitos dos Titulares [#7-direitos-dos-titulares]
Nos termos do art. 18 da LGPD, o titular de dados pessoais tem os seguintes direitos, exercíveis mediante solicitação ao DPO no endereço [legal@carrot.eco](mailto:legal@carrot.eco):
### 7.1 Direitos sob a LGPD [#71-direitos-sob-a-lgpd]
| Direito | Como exercê-lo na Plataforma Carrot |
| ------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Confirmação e Acesso (art. 18, I-II)** | Solicitação via [legal@carrot.eco](mailto:legal@carrot.eco); resposta em até 15 dias. |
| **Correção (art. 18, III)** | Atualização cadastral diretamente na interface da Plataforma ou via DPO. |
| **Anonimização, Bloqueio ou Eliminação (art. 18, IV)** | Dados *off-chain*: exclusão definitiva. Dados on-chain: anonimização técnica com emissão de certidão em 30 dias (ver Seção 3.2). |
| **Portabilidade (art. 18, V)** | Fornecimento em formato estruturado e interoperável, mediante solicitação. |
| **Informação sobre compartilhamento (art. 18, VII)** | Esta Política descreve as categorias de destinatários; detalhamentos adicionais disponíveis via DPO. |
| **Revogação do consentimento (art. 18, IX)** | A qualquer tempo, para finalidades baseadas em consentimento, sem prejuízo dos tratamentos realizados anteriormente. |
| **Revisão de decisão automatizada (art. 20)** | Solicitação de revisão humana de decisões do *smart contract* com impacto financeiro (cálculo de Recompensa, suspensão de MassID). Envio a [legal@carrot.eco](mailto:legal@carrot.eco) com descrição da decisão contestada. |
> **Direitos de terceiros cujos dados chegam via Integrador**
>
> Participantes da cadeia (ex.: transportadoras cujos dados são inseridos pelos Network Integrators) são titulares de dados pessoais e conservam todos os direitos do art. 18 da LGPD, mesmo sem relação contratual direta com a Carrot Fndn. Ao receber solicitação de eliminação de tais dados, a Carrot Fndn avaliará se há conflito com obrigações de auditoria ambiental ou prazo de retenção legal. Em caso de conflito, poderá invocar as exceções do art. 18, §3º, da LGPD (cumprimento de obrigação legal ou exercício regular de direitos), comunicando o resultado ao titular no prazo de 15 dias.
### 7.2 Direitos Adicionais sob o GDPR (titulares no EEE) [#72-direitos-adicionais-sob-o-gdpr-titulares-no-eee]
Para titulares residentes no Espaço Econômico Europeu, aplicam-se adicionalmente:
* **Direito de oposição (art. 21 GDPR):** o titular pode se opor ao tratamento baseado em legítimo interesse, a qualquer momento;
* **Restrição do tratamento (art. 18 GDPR):** em determinadas circunstâncias, o titular pode solicitar que o tratamento de seus dados seja restrito;
* **Reclamação à autoridade supervisora:** o titular pode apresentar reclamação à autoridade de proteção de dados do Estado-Membro da UE de sua residência habitual ou onde ocorreu a suposta infração.
Caso a Carrot Fndn venha a operar de forma sistemática com dados de titulares europeus em escala relevante, avaliará a necessidade de nomear representante na UE nos termos do art. 27 do GDPR. Para exercer estes direitos: [legal@carrot.eco](mailto:legal@carrot.eco).
### 7.3 Direitos sob o revDSG (titulares na Suíça) [#73-direitos-sob-o-revdsg-titulares-na-suíça]
Para titulares residentes na Suíça, aplicam-se os direitos previstos no revDSG, incluindo: acesso, correção, eliminação, portabilidade e oposição. Reclamações podem ser apresentadas ao FDPIC (Federal Data Protection and Information Commissioner — [www.edoeb.admin.ch](http://www.edoeb.admin.ch)). Canal de exercício: [legal@carrot.eco](mailto:legal@carrot.eco).
A Carrot Fndn responderá às solicitações no prazo de 15 (quinze) dias, prorrogável por igual período quando justificado, nos termos do art. 18, §5º, da LGPD, e em prazo razoável conforme o GDPR e o revDSG.
## 8. Segurança da Informação [#8-segurança-da-informação]
A Carrot Fndn adota medidas técnicas e administrativas adequadas para proteger os dados pessoais contra acessos não autorizados, destruição, perda, alteração, comunicação ou qualquer outra forma de tratamento inadequado, em cumprimento ao art. 46 da LGPD e ao art. 32 do GDPR.
### 8.1 Medidas Técnicas [#81-medidas-técnicas]
* Criptografia em trânsito: protocolo TLS 1.2 ou superior para toda comunicação entre cliente e servidor;
* Criptografia em repouso: padrão AES-256 para dados armazenados em infraestrutura de nuvem;
* Hashing criptográfico on-chain: garante integridade matemática dos registros sem expor dados pessoais identificáveis;
* Controle de acesso por identidade (IAM): apenas usuários e sistemas autorizados podem acessar dados pessoais;
* Monitoramento contínuo: detecção de anomalias e tentativas de acesso não autorizado.
### 8.2 Medidas Administrativas [#82-medidas-administrativas]
* Programa de governança de privacidade e proteção de dados, com revisões periódicas;
* Treinamento e conscientização de colaboradores e prestadores de serviço;
* Plano de resposta a incidentes de segurança, com procedimento de notificação documentado;
* Data Processing Agreements (DPAs) com todos os sub-processadores e Suboperadores.
### 8.3 Custódia de Ativos Digitais [#83-custódia-de-ativos-digitais]
A Carrot Fndn não armazena, não gerencia e não possui acesso às chaves privadas (private keys) ou frases de recuperação (seed phrases) das carteiras digitais dos Usuários. A custódia dos ativos digitais é de exclusividade do Usuário, e a perda ou extravio de tais credenciais é de sua responsabilidade exclusiva, sem possibilidade de recuperação por parte da Plataforma.
Nota: o mecanismo descrito acima aplica-se exclusivamente ao componente de carteiras digitais Web3 da Plataforma. Para o acesso por login tradicional (e-mail e senha), a Carrot Fndn disponibiliza mecanismo padrão de recuperação de senha.
### 8.4 Comunicação de Incidentes de Segurança [#84-comunicação-de-incidentes-de-segurança]
Em caso de incidente de segurança que possa acarretar risco ou dano relevante aos titulares, a Carrot Fndn adotará os seguintes procedimentos:
| Lei aplicável | Autoridade | Prazo de notificação | Base normativa |
| -------------- | --------------------------------------- | ------------------------------------------------ | -------------------------------------- |
| LGPD (Brasil) | ANPD | 72 horas após ciência | Art. 48 LGPD + Res. CD/ANPD nº 15/2024 |
| GDPR (UE/EEE) | Autoridade supervisora do Estado-Membro | 72 horas após ciência | Art. 33 GDPR |
| revDSG (Suíça) | FDPIC | O mais rápido possível (sem prazo fixo em horas) | Art. 24 revDSG |
A notificação aos titulares afetados será realizada por e-mail cadastrado na Plataforma. Quando o volume de afetados impossibilitar a notificação individual, será publicado aviso em destaque em [www.carrot.eco](http://www.carrot.eco) e no painel de acesso autenticado da Plataforma pelo prazo mínimo de 30 (trinta) dias.
A notificação conterá: (i) natureza dos dados afetados; (ii) informações sobre os titulares envolvidos; (iii) medidas técnicas adotadas; e (iv) riscos relacionados e ações para mitigar seus efeitos.
### 8.5 Limites de Responsabilidade por Incidentes de Segurança [#85-limites-de-responsabilidade-por-incidentes-de-segurança]
Não obstante as medidas de segurança descritas nas Seções 8.1 e 8.2, os Usuários reconhecem que nenhum sistema tecnológico oferece segurança absoluta.
A Carrot Fndn não será responsável por incidentes de segurança decorrentes exclusivamente de: (i) vulnerabilidades zero-day ainda não identificadas pela comunidade de segurança no momento do incidente; (ii) ataques de nível estatal ou a infraestruturas críticas que estejam além do controle razoável da Fundação; ou (iii) falhas em sistemas, redes ou infraestruturas de terceiros sobre os quais a Fundação não possui controle operacional direto.
A Carrot Fndn permanece responsável por incidentes decorrentes de falhas em suas próprias medidas de segurança implementadas, sujeita às disposições de responsabilidade previstas nos [Termos e Condições](/docs/terms/terms-and-conditions) Globais (Seção 15).
## 9. Retenção e Eliminação de Dados [#9-retenção-e-eliminação-de-dados]
Os dados pessoais são conservados pelo período necessário ao cumprimento das finalidades que fundamentaram sua coleta, observados os prazos legais de guarda obrigatória. Após o encerramento da relação contratual e o término dos prazos aplicáveis, os dados off-chain serão eliminados ou anonimizados de forma segura.
| Categoria de dado | Prazo de retenção | Fundamento |
| ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------- |
| Dados contratuais e fiscais | Mínimo 5 anos | Art. 206, §5º, CC; legislação tributária federal |
| Dados de KYC/KYB | 5 anos após encerramento do relacionamento; até 10 anos se houver investigação regulatória ou judicial | Res. BCB nº 1/2020; Lei nº 14.478/2022 (AML/CFT) |
| MTR e dados de operação | Mínimo 5 anos | Res. CONAMA nº 313/2002; Lei nº 12.305/2010 (PNRS) |
| Logs de acesso e navegação | 6 meses | Art. 15, Marco Civil da Internet (Lei nº 12.965/2014) |
| Registros de auditoria ambiental (off-chain) | Conforme metodologias aplicáveis | Verra, Gold Standard e demais certificadoras internacionais |
| Registros on-chain (hashes) | Indefinido (imutabilidade técnica) | Anonimização técnica aplicada — desvinculação de identidade |
| Dados de cookies analíticos | Até 13 meses (padrão GA4) | Consentimento / legítimo interesse |
| Dados de reconhecimento público — Impact Recognition Program (Seção 7A do T\&C) | Até 15 dias úteis após solicitação de opt-out | Seção 7A dos Termos e Condições — prazo de processamento de opt-out |
## 10. Armazenamento e Processamento Global [#10-armazenamento-e-processamento-global]
Em razão da natureza descentralizada da Rede Carrot e dos requisitos de resiliência da infraestrutura, dados são processados e armazenados primariamente em servidores localizados nos Estados Unidos da América, além da sede institucional na Suíça. A Carrot Fndn assegura que todas as transferências internacionais observam os mecanismos previstos nos arts. 33 a 36 da LGPD, com adoção de Cláusulas Contratuais Padrão (SCCs) como salvaguarda principal, garantindo nível de proteção equivalente ao exigido pela legislação brasileira.
## 11. Encarregado de Dados (DPO) [#11-encarregado-de-dados-dpo]
Em cumprimento ao art. 41 da LGPD e à Resolução CD/ANPD nº 2/2022, a Carrot Fndn designou Encarregado de Proteção de Dados (Data Protection Officer — DPO), responsável por:
* Receber comunicações dos titulares, da ANPD, do FDPIC e das autoridades supervisoras GDPR competentes;
* Orientar colaboradores e contratados sobre práticas de proteção de dados;
* Atuar como canal de comunicação entre a Fundação, os titulares e as autoridades supervisoras.
**Contato do DPO:** [legal@carrot.eco](mailto:legal@carrot.eco)
*A identidade nominativa do DPO será divulgada em conformidade com a Resolução CD/ANPD nº 2/2022. Para fins de contato, o canal [legal@carrot.eco](mailto:legal@carrot.eco) é o endereço oficial designado para todas as comunicações relacionadas à proteção de dados.*
## 12. Alterações desta Política [#12-alterações-desta-política]
Esta Política poderá ser atualizada periodicamente para refletir mudanças legais, tecnológicas ou operacionais. As alterações são classificadas em dois tipos:
### 12.1 Alterações Materiais [#121-alterações-materiais]
Consideram-se materiais as alterações que impliquem: (i) nova finalidade de tratamento; (ii) nova categoria de dados coletados; (iii) novo compartilhamento com terceiros; ou (iv) mudança da base legal aplicável. Tais alterações serão comunicadas com antecedência mínima de 30 (trinta) dias por e-mail, exigindo manifestação expressa do Usuário (opt-in) para continuar utilizando a Plataforma.
### 12.2 Alterações Não Materiais [#122-alterações-não-materiais]
Alterações de redação, clarificações ou correções que não alterem o escopo do tratamento serão comunicadas com antecedência mínima de 15 (quinze) dias por e-mail. A continuidade do uso da Plataforma após a entrada em vigor das alterações implica aceitação tácita.
A versão vigente desta Política estará sempre disponível em [docs.carrot.eco/terms/privacy-policy](/docs/terms/privacy-policy).
## 13. Histórico de Versões [#13-histórico-de-versões]
| Versão | Data | Responsável | Principais alterações |
| ------ | ---------- | -------------------------- | --------------------- |
| 1.0 | Março/2026 | Jurídico e Tec Carrot Fndn | Versão Inicial |
## 14. Glossário [#14-glossário]
| Termo | Definição |
| ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **TRC** | Tokenized Recycling Credit — crédito de reciclagem tokenizado representando 1 tonelada de material reciclado verificado. |
| **TCC** | Tokenized Carbon Credit — crédito de carbono tokenizado representando reduções de emissões. |
| **MassID** | Ativo digital único que representa um lote de resíduos físicos, rastreando sua proveniência e cadeia de custódia na blockchain. |
| **ProductID** | Identificador digital de produto usado para rastrear composição de materiais pós-consumo e reciclabilidade. |
| **dMRV** | Monitoramento, Relato e Verificação digital — processo digital para monitorar, relatar e verificar ganho ambiental. |
| **MTR** | Manifesto de Transporte de Resíduos — documento regulatório brasileiro (Res. CONAMA nº 313/2002). |
| **Network Integrator** | Plataforma de terceiro integrada à API Carrot para registrar eventos da cadeia de custódia; atua como Suboperador nos termos do art. 39 da LGPD. |
| **KYC/KYB** | Know Your Customer / Know Your Business — processo de verificação de identidade de pessoas físicas e jurídicas. |
| **DPO** | Data Protection Officer (Encarregado de Dados) — responsável pela proteção de dados na Carrot Fndn. Contato: [legal@carrot.eco](mailto:legal@carrot.eco). |
| **SCCs** | Standard Contractual Clauses — Cláusulas Contratuais Padrão aprovadas para transferências internacionais de dados pessoais. |
| **FDPIC** | Federal Data Protection and Information Commissioner — autoridade supervisora de proteção de dados da Suíça ([www.edoeb.admin.ch](http://www.edoeb.admin.ch)). |
| **revDSG** | Lei Federal Suíça de Proteção de Dados revisada, em vigor desde 1º de setembro de 2023. |
| **RIPD** | Relatório de Impacto à Proteção de Dados — documento interno que documenta tratamentos baseados em legítimo interesse. |
| **DPA** | Data Processing Agreement — Acordo de Processamento de Dados celebrado entre a Carrot Fndn e sub-processadores e Suboperadores. |
| **PSAV** | Prestador de Serviços de Ativos Virtuais — categoria regulatória criada pela Lei nº 14.478/2022, sujeita à supervisão do Banco Central do Brasil. |
| **AML/CFT** | Anti-Money Laundering / Counter-Financing of Terrorism — prevenção à lavagem de dinheiro e ao financiamento do terrorismo. |
***
Dúvidas jurídicas: [legal@carrot.eco](mailto:legal@carrot.eco) · Suporte operacional: [operations@carrot.eco](mailto:operations@carrot.eco)
*Este documento substitui todas as versões anteriores do Contrato de Uso da Plataforma Carrot.*
# Termos e Condições
{/* cspell:words Fndn homologação homologados CCPA LGPD RPDC criptomoedas reputacionais majeure Suboperadores */}
**Versão 2.0 — Março de 2026**
## 1. Rede CARROT e Websites [#1-rede-carrot-e-websites]
A Carrot Fndn é uma fundação suíça nos termos do Artigo 80 e seguintes do Código Civil Suíço, com sede registrada em Zug ("Fundação").
A Fundação desenvolveu e implantou a rede baseada em blockchain CARROT ("Rede"), que é gerida pela Fundação Carrot em parceria com sua comunidade de partes interessadas. A Rede possibilita o registro on-chain e off-chain de ações de economia circular, incluindo logística da cadeia de suprimentos e atividades de gestão de resíduos; medição, relatório e verificação ambiental; auditoria; certificação de reciclagem, compostagem, reutilização e uso de conteúdo reciclado em produtos; bem como descarbonização. As ações de economia circular realizadas por participantes ("Participantes") (por exemplo, fornecedores de matéria-prima, embaladores, envasadores, produtores, geradores de resíduos, Custodiantes de Ponto de Coleta, transportadores, processadores, recicladores, compradores de matéria-prima, autores de metodologias, desenvolvedores de metodologias, auditores e ONGs, entre outros) são registradas na Rede por meio de aplicativos móveis, de software e web de Integradores da Rede Carrot ("INTs") terceirizados que se conectam à Rede via APIs. Recursos como matérias-primas ou massa de resíduos ("MassIDs") e produtos ("ProductIDs") são codificados como identificadores únicos que estabelecem a cadeia de custódia e a responsabilidade pelo material ou produto. Com base nas ações de economia circular registradas e nos ganhos ambientais e sociais correspondentes realizados, a Fundação gera Créditos de Reciclagem Tokenizados ("TRC") não fungíveis, Créditos de Carbono Tokenizados ("TCC"), bem como outros tipos de créditos, que são subsequentemente oferecidos pela Fundação a terceiros compradores interessados ("Compradores de Tokens"). A compra de TRCs e TCCs por Compradores de Tokens distribui os rendimentos ("Recompensas") aos Participantes da cadeia de suprimentos que contribuíram de forma colaborativa para recuperar recursos para reutilização ou reciclagem, evitando assim a poluição do solo, da água e da atmosfera e a necessidade de extração de novas matérias-primas. Para fins destes Termos e Condições ("Termos"), os Participantes e os INTs são coletivamente referidos como ("Usuários").
A Fundação hospeda e mantém websites sob o domínio [www.carrot.eco](http://www.carrot.eco) ("Websites") que permitem aos usuários conhecer a Carrot Fndn e a Rede, seu propósito e funcionamento; participar da comunidade; aprender sobre economia circular; visualizar dados reportados de economia circular e Reivindicações Ambientais e Sociais de seus Participantes, comprar e aposentar tokens (por exemplo, TRCs, TCCs e outros); confirmar a aposentadoria de créditos (tokens não fungíveis queimados) em um registro público; e verificar e comparar o desempenho ambiental de todos os Participantes, inclusive por meio de um ranking.
## 2. Aceitação e Alterações dos Termos e Condições [#2-aceitação-e-alterações-dos-termos-e-condições]
Estes Termos, juntamente com quaisquer documentos expressamente incorporados por referência neste instrumento, regem o acesso e o uso dos Websites, da Rede e dos contratos inteligentes relacionados. Além disso, regem o processo de medição, relatório e verificação das contribuições para a economia circular ("Reivindicações Ambientais e Sociais") (por exemplo, resíduos desviados; reduções, capturas ou remoções de emissões de gases de efeito estufa (GEE); empregos verdes; benefícios sociais e econômicos; entre outros) e as Recompensas que os Usuários poderão receber, conforme descrito mais adiante. Ao utilizar os Websites e/ou a Rede, os Usuários concordam em estar vinculados a estes Termos.
O uso dos aplicativos oferecidos pelos Integradores Blockchain Carrot (INTs) e quaisquer direitos e obrigações entre Participantes e INTs não são regidos por estes Termos, mas por outros termos e condições e/ou acordos estabelecidos entre as partes.
A Fundação reserva-se o direito de alterar ou modificar estes Termos a qualquer momento, a seu exclusivo critério. Ao continuar a acessar, utilizar, enviar ou ter dados enviados por terceiros (por exemplo, INT) para os Websites e/ou a Rede, os Usuários confirmam que aceitam os Termos atualizados e todos os termos neles incorporados por referência. Os INTs e prestadores de serviços ("Prestadores de Serviços"), como Transportadores, Processadores e Recicladores, também são responsáveis por informar seus clientes, que também são Usuários, sobre os termos atualizados e por obter sua aceitação de tais Termos, especialmente no que se refere ao recebimento de Recompensas que também envolvam esses Usuários.
Qualquer Participante/Usuário que participe da criação ou venda de Créditos de Reciclagem Tokenizados ou Créditos de Carbono Tokenizados também está vinculado aos [Termos e Condições para Vendas e Compras de Tokens de Crédito de Reciclagem e Carbono](/docs/terms/credit-sales-terms) publicados na seção de Termos e Condições da Rede Carrot. Os Termos e Condições para Vendas e Compras de Tokens de Crédito de Reciclagem e Carbono são incorporados a estes Termos por referência para todos os fins.
## 3. Conheça Seu Cliente/Empresa ("KYC") [#3-conheça-seu-clienteempresa-kyc]
Para participar da Rede Carrot, os Usuários devem fornecer informações de identificação individual, como nome completo, número de celular, data de nascimento, endereço de e-mail, endereço de carteira para o qual as Recompensas (conforme definido abaixo) poderão ser enviadas, endereço residencial, documento comprovante de endereço residencial, nacionalidades, documento de identidade governamental para cada nacionalidade e documentos comprovantes de identidade governamental, incluindo prova de posse, como uma foto da pessoa segurando o documento.
No caso de uma empresa, o representante legal deve, além de fornecer informações de identificação individual, apresentar documentos comprovando a representação legal, um e-mail corporativo, a razão social da empresa, o CNPJ/Tax ID da empresa e um documento comprovante do CNPJ/Tax ID, bem como quaisquer outras informações que possam ser razoavelmente solicitadas pela Fundação de tempos em tempos, a fim de concluir a verificação da Fundação ("Verificação KYC"). Os Usuários e INTs devem fornecer informações verdadeiras, precisas, atuais e completas e devem atualizar prontamente a Fundação por meio eletrônico com quaisquer alterações de dados. Informações adicionais serão exigidas de Participantes específicos, como Processadores e Recicladores (por exemplo, licenças ambientais para exercer a atividade) e ONGs Beneficiárias, para verificar as qualificações das partes em relação aos trabalhos ambientais realizados.
As verificações Conheça Seu Cliente (KYC) e Conheça Sua Empresa (KYB) podem ser conduzidas pela própria Rede Carrot ou por terceiros em nome da Rede Carrot.
## 4. Transferência de Direitos do Usuário [#4-transferência-de-direitos-do-usuário]
Os Usuários, por meio deste instrumento, transferem todos e quaisquer direitos, benefícios, interesses, créditos, certificados, notas, reivindicações ou autorizações passados, presentes ou futuros, incluindo direitos de reporte, reivindicações sobre reciclagem ou reutilização de produtos e materiais; redução, captura ou remoção de carbono; ou quaisquer outros direitos ambientais, de marketing e similares ou Reivindicações Ambientais e Sociais, resultantes de ou surgidos em conexão com os dados compartilhados com a Rede no que se refere a ações de economia circular (por exemplo, MassIDs, ProductIDs ou outros), em cada caso em caráter exclusivo para a Fundação.
Para evitar dúvidas, a transferência de direitos estabelecida nesta Seção 4 não reflete nem implica qualquer valor monetário presente nos dados ou ações ambientais compartilhados pelo Usuário. O valor comercial de qualquer Reivindicação Ambiental e Social surge exclusivamente da aplicação pela Fundação da Metodologia aplicável, validação da ação de economia circular, emissão do crédito ou token correspondente e sua venda efetiva a um Comprador de Tokens — um ciclo que pode ou não ser concluído. Nenhum Usuário individual detém propriedade sobre qualquer MassID, uma vez que o ganho ambiental representado por cada crédito resulta da contribuição coletiva de múltiplos Participantes da cadeia de suprimentos, cada um recebendo apenas sua parcela proporcional dos rendimentos de acordo com a Política de Distribuição de Recompensas mediante uma venda bem-sucedida. A natureza exclusiva e irrevogável da transferência serve unicamente para preservar a integridade do programa de créditos para a proteção de todos os Participantes, Compradores de Tokens e do ecossistema como um todo. Nenhuma responsabilidade recairá sobre a Fundação exclusivamente em razão desta transferência no caso de nenhum Token ser emitido ou vendido em conexão com a ação de economia circular relevante.
Para evitar dúvidas, os Usuários perdem todos os seus direitos de reportar Reivindicações Ambientais e Sociais em programas de resíduos (Responsabilidade Estendida do Produtor) ou carbono (voluntários ou obrigatórios) por meio das ações de dados de reciclagem ou reutilização submetidos à Rede. O reporte de Reivindicações Ambientais e Sociais para o mesmo produto, recurso, massa ou atividade com outra parte é estritamente proibido, pois isso constituiria dupla contagem e possivelmente duplo aproveitamento sobre as mesmas Reivindicações Ambientais e Sociais de economia circular. Os Usuários não poderão, por conta própria, fazer qualquer reivindicação que de qualquer forma comprometa a transferência das Reivindicações Ambientais e Sociais para a Fundação. Além disso, os Usuários não poderão ceder ou transferir as Reivindicações Ambientais e Sociais, no todo ou em parte, a qualquer parte que não seja a Fundação. Qualquer transferência proibida é nula e sem efeito e pode resultar em remoção temporária ou permanente da Rede, bem como em multas e ações legais contra o Participante.
A Carrot detém o direito exclusivo de emitir e vender créditos (tokens) para os dados fornecidos à rede, mediante validação e certificação de ações de economia circular — eventos logísticos, cadeia de custódia e registros oficiais de transporte (por exemplo, Manifestos de Transporte de Resíduos (MTR) no Brasil) registrados e rastreados usando as soluções MassID, RecycledID, ProductID e GasID da Rede. Os requisitos mínimos para emissão de créditos incluem a identificação das partes interessadas envolvidas na etapa final de transporte até um reciclador credenciado, sem a necessidade de cadastro completo dos participantes com exceção do reciclador, desde que as partes interessadas sejam individualmente identificadas nos registros oficiais de transporte (por exemplo, MTRs no caso do Brasil).
A Carrot Fndn, por sua vez, transferirá os direitos sobre as Reivindicações Ambientais e Sociais ao Comprador de Tokens (TRC ou TCC) em troca do importante investimento realizado pelo comprador no apoio às ações de economia circular. Somente após a aposentadoria do token, tornando-o intransferível, o Comprador de Tokens poderá reivindicar e utilizar as Reivindicações Ambientais e Sociais associadas. Tokens aposentados comprovam contribuições realizadas pelo detentor do token como investimento em evitação de resíduos e carbono orientada pelo ecossistema, servindo como prova de compensação de carbono e cumprimento de Responsabilidades Estendidas do Produtor de acordo com os Padrões Carrot. Tokens aposentados tornam-se elegíveis para serem listados no Registro Carrot e nos rankings. Tais provas podem ou não ser aceitas por outros registros, e a Carrot não é responsável por sua aceitação em outros locais, pois isso está além do controle da Carrot Fndn.
## 5. Metodologias [#5-metodologias]
A Rede Carrot utiliza metodologias criadas por contribuidores terceiros para uso na verificação de dados e medição de ganhos ambientais e sociais ("Metodologias"). As Metodologias são escritas por Autores de Metodologias e desenvolvidas por Desenvolvedores de Metodologias, e cada Participante recebe uma parcela das Recompensas geradas pelos TRCs e TCCs que resultam do uso da Metodologia. Os valores das Recompensas são predeterminados na Política de Distribuição de Recompensas para cada material e são publicados no website em [Política de Distribuição de Recompensas](/docs/standard/policies/rewards-distribution).
## 6. Homologação [#6-homologação]
Alguns Participantes são considerados como tendo papéis particularmente importantes dentro da Rede Carrot e precisarão ser homologados pela Fundação (ou por um de seus parceiros) para assegurar que as capacidades de desempenho, a situação legal e a qualidade dos dados estejam estabelecidas.
Os Integradores da Rede Carrot que submetem dados de ações de economia circular à Rede precisarão ser homologados para garantir qualidade e segurança suficientes dos dados fornecidos. Embora a qualidade dos dados seja responsabilidade do INT e dos Usuários envolvidos, a verificação dos dados do INT será continuamente conduzida pela Fundação e pelos Participantes da Rede.
As ONGs Beneficiárias precisarão ser homologadas para serem elegíveis ao recebimento de recompensas da Rede Carrot. A homologação envolverá a apresentação dos documentos constitutivos da organização; apresentação do CNPJ/Tax ID da organização; comprovação da regularidade da organização para exercer suas atividades; comprovação da regularidade da organização perante as autoridades fiscais; comprovação da missão ou propósito da organização em promover a transição para uma economia circular; e comprovação de que a organização é apartidária.
Processadores e Recicladores precisam ser homologados para cada Metodologia utilizada para certificar a reciclagem ou reutilização e emitir TRCs e TCCs. Processadores que recebem e realizam atividades de triagem, bem como Recicladores que realizam o importante trabalho de manipulação de massa para transformação em novos insumos, serão auditados por um Auditor independente considerado pela Fundação como especialista na área, para assegurar que são capazes de realizar o trabalho ambiental sendo conduzido e que estão em boa situação profissional e legal.
As renovações de homologação serão ditadas pelas regras estabelecidas por diferentes metodologias, sendo responsabilidade de cada Participante garantir que sua homologação esteja atualizada. A homologação e as renovações, incluindo auditorias, podem incorrer em custos para o candidato, e o custo será comunicado ao candidato antes do início de qualquer trabalho de homologação. O candidato terá, naturalmente, todo o direito de recusar o trabalho de homologação, o que resultará na desqualificação automática do candidato quando o período de homologação expirar. A Carrot sempre buscará estabelecer um valor justo para o trabalho de homologação, considerando os custos e o valor do trabalho empregado pelos Auditores e pela equipe de homologação. A equipe de homologação da Carrot pode ser contatada em [operations@carrot.eco](mailto:operations@carrot.eco).
## 7. Recompensas [#7-recompensas]
Sujeito à transferência de direitos, à aprovação na Verificação KYC, à verificação dos dados de ações de economia circular submetidos à Rede pelos INTs e à certificação sob uma metodologia ("Metodologia") selecionada pelo Reciclador homologado, os Usuários poderão ser recompensados com uma parcela dos rendimentos gerados pela venda de tokens (por exemplo, TRC e TCC) a Compradores de Tokens ("Recompensas").
As Recompensas, se houver, serão pagas em tokens, no valor determinado pela Fundação e seus apoiadores, e executadas por meio dos contratos inteligentes desenvolvidos ou aprovados pela Fundação, diretamente no endereço de carteira fornecido pelo Usuário. Cada Usuário é integralmente responsável por fornecer à Fundação um endereço de carteira funcional, mantido por ele, em sua própria conta, e por reivindicar os tokens que foram reservados ou distribuídos a ele pela Rede.
O acesso e o resgate de recompensas de créditos (USDC) reservados no Contrato Inteligente para cada participante com base na Política de Distribuição de Recompensas são estritamente condicionados à conclusão do cadastro (incluindo o processo KYC/KYB) e à aceitação integral dos Termos de Uso da Rede Carrot e de Vendas e Compras de TRCs e TCCs pelo respectivo Participante. O período de resgate de recompensas é de 90 dias corridos a partir da data de venda do crédito, concebido para incentivar a digitalização da cadeia de suprimentos, o cadastro de partes interessadas e a melhoria da triagem de resíduos. Após o vencimento deste período, as recompensas não resgatadas serão automaticamente transferidas para o [Community Pool](/docs/glossary#community-pool), cancelando a oportunidade do Usuário de sacar as referidas recompensas (incentivos) dos créditos em questão. O Usuário poderá assinar os termos a qualquer momento e começar a participar do recebimento de recompensas a qualquer momento para créditos vendidos há menos de 90 dias corridos e em futuras emissões de créditos.
As Recompensas e suas alocações de distribuição são predeterminadas na política de distribuição de recompensas da Fundação ("Política de Recompensas"), que está disponível no Website da Rede Carrot em Política de Distribuição de Recompensas. A Política de Recompensas poderá ser alterada pela Fundação a qualquer momento, a seu exclusivo critério, para beneficiar a comunidade como um todo. No entanto, as alterações serão comunicadas a todos os Participantes por meio do endereço de e-mail principal fornecido para cada conta, com prazo razoável para quaisquer ajustes, caso sejam considerados necessários.
Atenção especial deve ser dada aos descontos de distribuição de recompensas para prestadores de serviços, concebidos para incentivar a digitalização da cadeia de suprimentos (ou seja, o "Mecanismo de Incentivo") quando o Gerador de Resíduos não é identificado, bem como para Geradores de Resíduos que são empresas de "Grande Receita", concebidos para garantir que os compradores de créditos não sejam desencorajados de adquirir créditos que distribuam rendimentos para grandes organizações, mantendo ao mesmo tempo incentivo suficiente para assegurar a participação e a adoção da rede. O Gerador de Resíduos desempenha um papel fundamental na economia circular porque é ele quem determina se e como separar resíduos e produtos pós-consumo e pós-industriais e, em última instância, se estes serão de fato recuperados para reutilização e/ou reciclagem.
Os Participantes também podem ser temporária ou permanentemente excluídos do recebimento de recompensas se a Fundação ou um auditor terceirizado ("Auditor") identificar comportamento considerado antiético, ilegal, criminoso ou outro e/ou que aparente mostrar conluio com outros Participantes em relação a ações de economia circular reportadas, incluindo, mas não se limitando a, superestimar as atividades de reciclagem ou reutilização e as Reivindicações Ambientais e Sociais correspondentes alcançadas. A exclusão na distribuição de recompensas pode ser direcionada aos Participantes diretamente envolvidos, bem como a usuários relacionados aos Participantes, penalizando tais Participantes por associação. Tais penalidades são fundamentais para dissuadir agentes mal-intencionados e alinhar interesses no reporte de dados com a mais alta qualidade possível na Rede. Tal mecanismo para garantir o autopoliciamento da qualidade dos dados na Rede é frequentemente referido como Prova de Autoridade, ou ("PoA"). Para mais informações, consulte a seção abaixo sobre Penalidades e Suspensões.
Os Participantes que são penalizados por não receberem recompensas de vendas de créditos devido a créditos que foram impedidos de serem vendidos, seja por atividade suspeita ou identificados como contendo dados comprometidos, reconhecem que, mesmo que não tenham participação nas atividades do(s) Agente(s) Mal-Intencionado(s) (Bad Actor(s)), a penalidade serve como um componente fundamental do mecanismo de autopoliciamento da rede, necessário para assegurar dados de alta qualidade na Rede. O bom ator penalizado concorda em não contestar ou tomar qualquer ação contra a Carrot Fndn por Recompensas não distribuídas a ele. Os Participantes penalizados também não devem tomar ação contra quaisquer outros bons atores que também estejam envolvidos, sem culpa própria. Os bons atores são convidados a comunicar-se com o Agente Mal-Intencionado identificado para garantir que as ações sejam corrigidas e, se os assuntos não puderem ser resolvidos, a trocar de prestadores de serviços e/ou trabalhar com outros Participantes. Os Agentes Mal-Intencionados serão os únicos responsáveis por indenizar e isentar os Participantes de e contra quaisquer reivindicações, perdas e penalidades, sejam cíveis, criminais, tributárias, administrativas, ambientais ou de outra natureza, resultantes da ação ou omissão de tal Agente Mal-Intencionado.
Todos os Participantes, como membros de uma Rede, são considerados individualmente responsáveis por documentar suas ações de economia circular e reportar Reivindicações Ambientais com precisão e entendem que as recompensas servem apenas como um bônus quando todas as atividades podem ser razoavelmente verificadas e os Participantes estão conduzindo suas ações de economia circular corretamente.
## 7A. Programa de Reconhecimento de Impacto [#7a-programa-de-reconhecimento-de-impacto]
Ao aceitar estes Termos, o Participante concede à Fundação uma autorização não exclusiva e isenta de royalties para divulgar publicamente os resultados e impactos ambientais gerados por sua organização na Rede — incluindo volumes de resíduos recuperados e reciclados, emissões de carbono reduzidas, prevenidas ou removidas, certificados e créditos (de reciclagem, carbono e outros) emitidos e aposentados — no website da Carrot, canais de mídia social e materiais institucionais, com o propósito de reconhecer publicamente sua contribuição para a economia circular inclusiva e de baixo carbono e incentivar outros a participar.
Apenas dados de impacto ambiental e o nome, logotipo e website da organização serão utilizados, juntamente com quaisquer informações adicionais fornecidas voluntariamente pela organização. Nenhum dado pessoal de Usuários individuais será divulgado nos termos desta Seção.
Os Participantes que não desejarem ser apresentados poderão optar pela exclusão a qualquer momento mediante notificação por escrito para [legal@carrot.eco](mailto:legal@carrot.eco), sem afetar sua participação na Rede ou seu direito de receber Recompensas. As solicitações de exclusão serão processadas em até 15 dias úteis.
## 8. Taxas de Serviço [#8-taxas-de-serviço]
A Carrot Fndn, organizações que a representam ou utilizam a rede, poderão cobrar taxas associadas aos serviços prestados, incluindo, mas não se limitando a, uso de dados, armazenamento de dados, Monitoramento, Relato e Verificação digital (dMRV), auditoria e certificação de cadeias de suprimentos, reutilização, reciclagem, compostagem, produção de energia, medição de emissões de gases de efeito estufa (produção, evitação, prevenção, remoção e captura), prova de uso de conteúdo reciclado em produtos, certificação e emissão de créditos e quaisquer serviços adicionais que possam ser oferecidos para medir e monetizar impactos ambientais, financeiros e sociais.
Quaisquer taxas associadas aos serviços prestados serão comunicadas aos Participantes com antecedência e requerem aprovação prévia do Usuário antes de serem cobradas.
## 9. Direitos de Propriedade Intelectual [#9-direitos-de-propriedade-intelectual]
Os Usuários reconhecem e concordam que os Websites disponíveis em [www.carrot.eco](http://www.carrot.eco), docs.carrot.eco e registry.carrot.eco, incluindo sua "aparência e sensação" (por exemplo, gráficos, design, texto, imagens, logotipos, cabeçalhos de página, ícones de botões e scripts); conteúdo proprietário, informações e outros materiais; e todo o conteúdo e outros materiais neles contidos, incluindo, sem limitação, o logotipo da Fundação e da Rede Carrot e todos os designs, textos, gráficos, imagens, dados, software, arquivos de som, outros arquivos e a seleção e organização dos mesmos, são propriedade exclusiva da Fundação ou de suas afiliadas, licenciadores ou Usuários, conforme aplicável, e os Usuários concordam em não tomar qualquer(quaisquer) ação(ões) inconsistente(s) com tais interesses de propriedade. A Fundação e suas afiliadas e licenciadores, conforme aplicável, reservam todos os direitos em conexão com os Websites e seu conteúdo, incluindo, sem limitação, o direito exclusivo de criar obras derivadas. Exceto conforme expressamente estabelecido neste documento, o uso da Rede ou dos Websites pelos Usuários não concede aos Usuários a propriedade de quaisquer outros direitos com relação a qualquer conteúdo, código, dados ou outros materiais que os Usuários possam acessar na Rede ou nos Websites ou por meio deles.
## 10. Código de Conduta [#10-código-de-conduta]
A Fundação poderá emitir regras para o uso da Rede e dos Websites e alterá-las a seu exclusivo critério ("Código de Conduta"). Os Usuários são obrigados a se informar sobre a versão atual do Código de Conduta e a assegurar que eles e suas respectivas comunidades cumpram o Código de Conduta.
A Fundação poderá publicar ou comunicar o Código de Conduta atual por meio dos Websites ou de outros canais oficiais da Fundação.
## 11. Penalidades e Suspensões [#11-penalidades-e-suspensões]
No caso de quaisquer irregularidades nas atividades ou no reporte de dados relativos a um Participante, sinalizado como potencial "Agente Mal-Intencionado" (Bad Actor), a Carrot Fndn ou um Auditor independente terceirizado homologado poderá suspender o Participante imediatamente de qualquer envolvimento na Rede e participação na emissão de certificados e/ou TRCs e TCCs. Os Participantes associados a quaisquer Agentes Mal-Intencionados também poderão ser suspensos imediatamente. Informações adicionais poderão ser solicitadas a todos os Participantes envolvidos até que esclarecimento suficiente tenha sido fornecido para determinar a duração da penalidade ou se e quando o Participante poderá ser reintegrado. Se um crédito for identificado como contendo, ou potencialmente contendo, dados ruins e o crédito já tiver sido vendido, quaisquer rendimentos ainda não distribuídos serão direcionados ao Community Pool para uso conforme a comunidade considerar mais apropriado. A Carrot Fndn não tem obrigação de devolver o valor associado aos créditos que foram reservados para os Participantes enquanto estiveram penalizados. Novamente, o ônus recai sobre cada Participante de assegurar que os dados fornecidos sejam precisos e que estejam trabalhando com outros Participantes que levem a qualidade dos dados a sério.
Se qualquer participante não fornecer uma resposta à solicitação de informações dentro de 30 dias, o participante poderá ser permanentemente desqualificado de participar na Rede e na emissão de créditos.
Para o período em que as atividades em questão não atenderam aos requisitos de uma determinada metodologia, os participantes não receberão quaisquer recompensas da venda de TRCs ou TCCs.
Durante o período de não conformidade, TRCs ou TCCs emitidos antes deste período envolvendo o Agente Mal-Intencionado e ainda não vendidos serão impedidos de serem vendidos até que a situação seja resolvida.
No caso de fraude ser identificada para qualquer um dos requisitos de uma determinada metodologia, os Participantes homologados perderão permanentemente seus direitos de Homologação, e medidas legais apropriadas poderão ser tomadas.
Qualquer evidência de práticas intencionais que impactem negativamente o bem-estar das comunidades locais ou dos ecossistemas naturais servirá como justificativa sólida para exclusão permanente da participação na Rede.
Ações legais poderão ser tomadas pela Carrot Fndn contra a parte por quaisquer danos causados à Fundação ou à Rede, de acordo com o grau e o envolvimento de cada Parte em relação aos danos.
## 12. Comunicação [#12-comunicação]
Os Usuários concordam e entendem que a Fundação se comunicará com os Usuários por meios eletrônicos. Os Usuários concordam em manter seus endereços de e-mail atualizados e em notificar a Fundação sobre quaisquer alterações. Os Usuários concordam que quaisquer avisos, acordos, divulgações ou outras comunicações entregues em seus endereços de e-mail são considerados válidos.
## 13. Declarações e Garantias dos Usuários [#13-declarações-e-garantias-dos-usuários]
Os Usuários declaram e garantem à Fundação o seguinte e reconhecem que a Fundação está se baseando nestas declarações e garantias:
1. Se os Usuários forem pessoas jurídicas, estão devidamente organizados, validamente existentes e em situação regular perante as leis de seu domicílio;
2. Se os Usuários forem pessoas jurídicas, possuem pleno direito, poder e autoridade para utilizar os Websites, a Rede e os contratos inteligentes relacionados e aceitar estes Termos;
3. Se o Usuário for pessoa física, possui idade legal na jurisdição aplicável a ele e tem o direito, a autoridade e a capacidade para celebrar estes Termos;
4. Possuem ou obtiveram todos os direitos (incluindo direitos de propriedade intelectual), consentimentos, autorizações e aprovações necessários para poder conceder os direitos aqui outorgados;
5. Se o Usuário for um Reciclador homologado, reconhece que, sob o programa de créditos da Carrot e as metodologias correspondentes, assume o papel de parte interessada final e principal ao longo da cadeia de recuperação e reciclagem de resíduos que transforma resíduos em recursos, atuando também como o "Desenvolvedor do Projeto" para fins de emissão de créditos. O Reciclador compromete-se a informar os Participantes de sua cadeia de suprimentos (o Gerador de resíduos, Custodiantes de Ponto de Coleta, Transportadores e Processadores) associados à massa de resíduos que está reciclando sobre a oportunidade de participar na distribuição de recompensas que poderá resultar das vendas de créditos — convidando-os a se cadastrar na plataforma Carrot, notificando-os sobre o prazo de resgate de recompensas e explicando como seus dados são compartilhados e protegidos de acordo com os Termos e Condições e as [Políticas de Privacidade](/docs/terms/privacy-policy) da Carrot.
6. Não transferirão as Reivindicações Ambientais e Sociais, no todo ou em parte, a qualquer parte que não seja a Fundação, e não farão, por conta própria, quaisquer reivindicações que de qualquer forma comprometam a transferência das Reivindicações Ambientais e Sociais para a Fundação ou para a parte à qual a Fundação venha a transferir as reivindicações mediante a venda e aposentadoria de TRCs e TCCs;
7. Não há garantia quanto ao número de Recompensas que os Usuários receberão ou se receberão quaisquer Recompensas;
8. Estão autorizados a receber e manter Recompensas em tokens, se houver, de acordo com as leis e regulamentos a eles aplicáveis;
9. Não estão listados, ou associados a qualquer pessoa ou entidade listada, em qualquer uma das seguintes listas: Lista de Pessoas Negadas ou Lista de Entidades do Departamento de Comércio dos EUA, Listas de Nacionais Especialmente Designados ou Pessoas Bloqueadas do Departamento do Tesouro dos EUA, Lista de Partes Impedidas do Departamento de Estado dos EUA, Lista Consolidada de Pessoas, Grupos e Entidades Sujeitos a Sanções Financeiras da UE, ou Lista Geral de Indivíduos, Entidades e Organizações Sancionados da SECO Suíça, e nem eles nem quaisquer de suas afiliadas, diretores ou executivos são residentes de um país ou território que tenha sido designado como não cooperativo com princípios ou procedimentos internacionais de combate à lavagem de dinheiro por um grupo ou organização intergovernamental, como o Grupo de Ação Financeira contra a lavagem de dinheiro;
10. Confirmam não ser residentes, cidadãos ou estar localizados em uma área geográfica sujeita a sanções ou embargos da ONU, EUA, UE, Suíça, Brasil ou de qualquer outro país soberano (incluindo, mas não se limitando a: Belarus, Burundi, República Centro-Africana, Congo, RPDC (Coreia do Norte), Guiné, Guiné-Bissau, Irã, Iraque, Líbano, Líbia, Mali, Myanmar (Birmânia), República do Sudão do Sul, Rússia, Somália, Sudão, Síria, Ucrânia, Venezuela, Iêmen ou Zimbábue);
11. Não são domiciliados ou organizados sob as leis de qualquer país cuja legislação entre em conflito com a presente alocação de tokens e/ou com o propósito da Fundação em geral;
12. O Contribuidor entende e concorda que não tem direito de vender, doar, penhorar ou transferir de qualquer outra forma os tokens a pessoas conforme definido nos itens \[9–11] acima;
13. Possuem conhecimento e experiência em assuntos financeiros e empresariais suficientes para avaliar os méritos e riscos de concordar com estes Termos e utilizar a Rede e os Websites;
14. Possuem profundo entendimento sobre a funcionalidade, uso, armazenamento, mecanismos de transmissão e complexidades associadas a tokens criptográficos e sistemas de software baseados em blockchain;
15. Foram informados de que o uso do Website, da Rede e dos contratos inteligentes relacionados e os tokens a serem transferidos por/para/deles nos termos deste instrumento podem, em certas jurisdições, ser considerados valores mobiliários, e que tal emissão e/ou transferência pode estar sujeita às leis de valores mobiliários;
16. Todas as informações por eles fornecidas são verdadeiras, atuais, precisas e completas, e não atuam em nome de terceiros;
17. Estão utilizando os Websites, a Rede e/ou os contratos inteligentes relacionados em conformidade com o Código de Conduta, conforme determinado nestes Termos e Condições, e em nenhuma circunstância deverão ser utilizados para quaisquer fins ilegais;
18. Entendem e aceitam expressamente que não há qualquer garantia sobre o Website, a Rede e/ou os contratos inteligentes relacionados, expressa ou implícita, na medida permitida por lei, e que o uso dos Websites ou da Rede é por sua conta e risco exclusivo, em uma base "como está" e "em desenvolvimento" e sem, na medida permitida por lei, quaisquer garantias de qualquer tipo, incluindo, mas não se limitando a, garantias de título ou garantias implícitas, comerciabilidade ou adequação a um propósito específico. Estão cientes de que não receberão dinheiro ou qualquer outra compensação por quaisquer danos que possam incorrer em conexão com o uso da Rede ou dos Websites;
19. Não se basearam em quaisquer declarações ou garantias feitas pela Fundação ou por qualquer outra pessoa fora daquelas feitas nestes Termos, incluindo, mas não se limitando a, conversas de qualquer tipo, seja por comunicação oral ou eletrônica, ou qualquer apresentação, documento técnico, conteúdo de mídia social ou publicação em website;
20. Não concederam a qualquer outra parte quaisquer direitos que entrem em conflito com os direitos aqui concedidos;
21. RENUNCIAM, POR MEIO DESTE, AO DIREITO DE PARTICIPAR DE QUALQUER AÇÃO COLETIVA OU ARBITRAGEM COLETIVA CONTRA QUALQUER ENTIDADE OU INDIVÍDUO ENVOLVIDO NO DESENVOLVIMENTO OU PRESTAÇÃO DOS WEBSITES, DA REDE E/OU DOS CONTRATOS INTELIGENTES RELACIONADOS.
## 14. Declarações e Garantias da Fundação [#14-declarações-e-garantias-da-fundação]
A Fundação declara e garante aos Usuários o seguinte e reconhece que os Usuários estão se baseando nestas declarações e garantias:
1. A Fundação é uma fundação devidamente organizada, validamente existente e em situação regular perante as leis da Suíça e possui todo o poder corporativo e autoridade necessários para exercer seu propósito estatutário e suas operações conforme atualmente conduzidas e conforme se propõe a conduzi-las.
2. A Fundação possui todo o poder e autoridade necessários para cumprir e executar suas obrigações nos termos destes Termos. Estes Termos constituem uma obrigação legal, válida e vinculante da Fundação, exequível contra a Fundação de acordo com seus termos, exceto que tal exequibilidade pode ser limitada por leis aplicáveis de falência, insolvência, reorganização, moratória e leis gerais similares de aplicação geral relativas a ou que afetem direitos de credores em geral e por princípios de equidade (independentemente de a execução ser buscada em processo de equidade ou de direito).
3. A execução, entrega e cumprimento nos termos destes Termos não requerem aprovação ou outra ação de qualquer pessoa que não seja a Fundação.
4. Não há ações pendentes ou ameaçadas contra ou pela Fundação ou qualquer afiliada da Fundação que contestem ou busquem prevenir, impedir ou de outra forma atrasar as transações contempladas por estes Termos. Nenhum evento ocorreu, nem existem circunstâncias que possam dar origem a ou servir de base para qualquer tal ação.
## 15. Indenizações [#15-indenizações]
Os Usuários concordam, na máxima extensão permitida pela lei aplicável, em indenizar, defender e isentar a Fundação e seus respectivos empregados, diretores, executivos, contratados, consultores, detentores de participações, fornecedores, vendedores, prestadores de serviços, empresas controladoras, subsidiárias, afiliadas, agentes, representantes, predecessores, sucessores e cessionários, passados, presentes e futuros (individual e coletivamente, as "Partes da Fundação"), de e contra todas as reivindicações, danos, indenizações, julgamentos, perdas, responsabilidades, obrigações, penalidades, juros, taxas, despesas (incluindo, sem limitação, honorários e despesas advocatícias) e custos (incluindo, sem limitação, custas processuais, custos de acordo e custos de busca de indenização e seguro), reais ou alegados, de toda espécie e natureza, sejam conhecidos ou desconhecidos, previstos ou imprevistos, vencidos ou não vencidos, ou suspeitos ou insuspeitos, em direito ou equidade, seja em responsabilidade civil, contrato ou de outra forma (coletivamente, "Reivindicações"), incluindo, mas não se limitando a, danos à propriedade ou lesão pessoal, que sejam causados por, surjam de ou estejam relacionados a (a) uso indevido do Website, (b) qualquer Feedback fornecido pelos Usuários, (c) violação ou descumprimento destes Termos (em particular, mas não exaustivamente, Seção 5 destes Termos) ou da lei aplicável, (d) violação dos direitos de ou obrigações para com terceiros, incluindo outro Usuário, e (e) negligência ou conduta dolosa dos Usuários. Concordam em notificar prontamente a Fundação de quaisquer Reivindicações e cooperar com as Partes da Fundação na defesa de tais Reivindicações. Concordam ainda que as Partes da Fundação terão o controle da defesa ou acordo de quaisquer Reivindicações. Esta indenização é complementar e não substitutiva de quaisquer outras indenizações estabelecidas em acordo escrito entre os Usuários e a Fundação.
O Usuário aceita e reconhece os riscos relacionados ao uso da Rede, conforme estabelecido nestes Termos. O Usuário reconhece e concorda que, embora a Carrot aplique medidas de segurança de dados e gestão de software, incluindo criptografia, a Carrot não é responsável por qualquer risco relacionado ao uso da Rede, incluindo, mas não se limitando a, atividade, dados pessoais e obrigações de serviço do Usuário. Não obstante, a responsabilidade da Carrot por quaisquer perdas e danos decorrentes do descumprimento destes Termos será limitada ao valor total dos pagamentos realizados pelo Usuário à Carrot em conexão com quaisquer serviços da Rede nos doze (12) meses anteriores. Quaisquer danos indiretos são expressamente excluídos das responsabilidades da Carrot, incluindo, mas não se limitando a, perda de oportunidade, danos, danos consequenciais, danos reputacionais ou outros.
## 16. Isenções de Responsabilidade [#16-isenções-de-responsabilidade]
O acesso e o uso dos Websites, da Rede e dos contratos inteligentes relacionados pelos Usuários são por sua conta e risco. Eles entendem e concordam que o serviço é fornecido em uma base "como está" e "conforme disponível", e a Fundação expressamente se isenta de garantias ou condições de qualquer tipo, expressas ou implícitas. A Fundação e seus diretores, empregados, executivos, acionistas, controladoras, subsidiárias, afiliadas, agentes e licenciadores não fazem qualquer garantia ou declaração e se isentam de toda responsabilidade sobre se os serviços da Fundação: (a) atenderão aos requisitos dos Usuários; (b) estarão disponíveis de forma ininterrupta, tempestiva, segura ou livre de erros; ou (c) serão precisos, confiáveis, completos, legais ou seguros. A Fundação se isenta de todas as outras garantias ou condições, expressas ou implícitas, incluindo, sem limitação, garantias ou condições implícitas de comerciabilidade, adequação a um propósito específico, título e não violação.
A Fundação não será responsável por qualquer tipo de ação tomada ou tomada com base em material ou informação contidos nos Websites ou na Rede.
Embora a Fundação tente tornar o acesso e o uso dos Websites e da Rede seguros, ela não pode e não declara ou garante que a Rede ou os Websites estarão disponíveis em todos os momentos, livres de vírus ou outros componentes prejudiciais. Embora a Fundação leve a segurança de dados a sério e empregue soluções como criptografia, ela não pode garantir a segurança de quaisquer dados que os Usuários divulguem online. Nenhum conselho ou informação, seja oral ou obtido das Partes da Fundação ou por meio do serviço, criará qualquer garantia ou declaração não expressamente feita neste documento. Os Usuários aceitam os riscos de segurança inerentes ao fornecimento de informações e às transações online pela internet e não responsabilizarão a Fundação por qualquer violação de segurança.
A responsabilidade da Fundação por danos diretos e indiretos — independentemente do fundamento jurídico — é expressamente excluída na máxima extensão permitida por lei. Da mesma forma, a responsabilidade contratual por ações ou omissões de auxiliares, bem como a responsabilidade extracontratual da Fundação, é excluída na máxima extensão permitida por lei. A Fundação não será responsável perante os Usuários por quaisquer perdas e não assume responsabilidade por, e não será responsável perante os Usuários por, qualquer uso do Website, da Rede e dos contratos inteligentes relacionados, conteúdo e/ou conteúdo vinculado ou associado a quaisquer perdas, danos ou reivindicações decorrentes de: (a) erro do Usuário, transações incorretamente construídas ou endereços digitados incorretamente; (b) falha do servidor ou perda de dados; (c) acesso ou uso não autorizado; (d) quaisquer atividades de terceiros não autorizados, incluindo, sem limitação, o uso de vírus, phishing, força bruta ou outros meios de ataque contra o serviço. Não obstante o exposto, nada nesta Seção excluirá ou limitará a responsabilidade da Carrot por danos diretos decorrentes do próprio descumprimento destes Termos pela Carrot, que permanecerá sujeita ao limite de responsabilidade estabelecido na Seção 15.
A Fundação não é responsável por quaisquer perdas ou danos sustentados devido a vulnerabilidade ou qualquer tipo de falha, comportamento anormal ou software (por exemplo, carteira, contrato inteligente), o Website, a Rede e os contratos inteligentes relacionados. A Fundação não é responsável por perdas ou danos devidos a relatórios tardios por desenvolvedores ou representantes (ou nenhum relatório) de quaisquer problemas com o Website, a Rede e/ou os contratos inteligentes relacionados.
A Fundação não é responsável pelo registro correto de ações de economia circular na Rede. Toda e qualquer responsabilidade da Fundação em conexão com o registro errôneo, omitido ou falho de ações de economia circular na Rede é expressamente excluída. No entanto, a Fundação permanecerá responsável por danos diretos causados por erros no registro de ações de economia circular atribuíveis a seus próprios sistemas ou processos, sujeita ao limite de responsabilidade estabelecido na Seção 15.
O exposto acima não afeta quaisquer garantias que não possam ser excluídas ou limitadas pela lei aplicável. Na medida em que a Fundação não possa, por força da lei aplicável, isentar-se de qualquer garantia (implícita), o escopo e a duração de tal garantia serão os mínimos permitidos pela lei aplicável.
## 17. Riscos [#17-riscos]
Os Usuários aceitam e reconhecem os riscos associados ao uso dos Websites, da Rede e dos contratos inteligentes relacionados. Em particular, mas não de forma exaustiva, os Usuários compreendem os riscos inerentes listados a seguir. Ao usar o Website, a Rede e/ou os contratos inteligentes relacionados, os Usuários reconhecem e assumem estes riscos:
### 17.1 Risco de Falhas de Software [#171-risco-de-falhas-de-software]
Os Usuários entendem e aceitam que a Rede e os contratos inteligentes relacionados, outros softwares e tecnologias envolvidos, bem como conceitos e teorias técnicas, ainda não foram comprovados em um ambiente real (não teste), razão pela qual não há garantia de que o processo de configuração de comunidades e iniciativas, emissão, recebimento, uso e propriedade dos tokens será ininterrupto ou livre de erros, e há um risco inerente de que o software e as tecnologias e teorias relacionadas possam conter fraquezas, vulnerabilidades ou bugs que causem, entre outros, a perda total dos tokens.
Os Usuários particularmente entendem e aceitam que a Rede e os contratos inteligentes relacionados são (uma vez descentralizados) imutáveis e que, consequentemente, pode ser difícil ou impossível corrigir fraquezas de software.
### 17.2 Risco Regulatório [#172-risco-regulatório]
O regime regulatório que governa tecnologias blockchain, criptomoedas e tokens é incerto, e novas regulamentações ou políticas podem afetar material e adversamente o uso do Website, da Rede e/ou dos contratos inteligentes relacionados.
Os Usuários entendem e aceitam que a tecnologia blockchain permite novas formas de interação. Existe a possibilidade de que certas jurisdições apliquem regulamentações existentes ou introduzam novas regulamentações voltadas para aplicações baseadas em tecnologia blockchain, de uma forma que possa ser contrária à configuração atual e que possa, entre outros, resultar em modificações substanciais ao Website, à Rede e/ou aos contratos inteligentes relacionados, incluindo o encerramento do Projeto e a perda dos tokens ou de sua funcionalidade para os Usuários.
Os Usuários entendem e aceitam que certos reguladores podem, não obstante, qualificar tokens como valores mobiliários ou outros instrumentos financeiros sob sua lei aplicável. Permanece sob a responsabilidade dos Usuários cumprir quaisquer leis e regulamentos a eles aplicáveis ao deter ou transferir tokens.
Os Usuários explicitamente aceitam e reconhecem que a Fundação não assume qualquer responsabilidade por todos e quaisquer riscos relativos a tributação ou questões regulatórias em conexão com o uso do Website, da Rede e/ou dos contratos inteligentes relacionados. Permanece como responsabilidade exclusiva dos Usuários buscar assessoria jurídica, tributária e regulatória local.
### 17.3 Risco de Abandono / Falta de Sucesso [#173-risco-de-abandono--falta-de-sucesso]
A falta de uso ou interesse público na criação e desenvolvimento de ecossistemas distribuídos poderia impactar negativamente o desenvolvimento desses ecossistemas e aplicações relacionadas e poderia, portanto, também impactar negativamente a utilidade ou valor potencial do Website, da Rede e/ou dos contratos inteligentes relacionados.
### 17.4 Risco de Provedores Terceiros [#174-risco-de-provedores-terceiros]
Os serviços da Fundação podem depender de software de terceiros. Se a Fundação não conseguir manter um bom relacionamento com tais terceiros; se os termos e condições ou preços de tais terceiros mudarem; se a Fundação violar ou não puder cumprir os termos e condições de tais terceiros; ou se qualquer um de tais terceiros perder participação de mercado ou cair em desuso ou ficar indisponível por um período prolongado, o acesso e o uso do Website, da Rede e/ou dos contratos inteligentes relacionados podem ser prejudicados.
### 17.5 Risco de Perda de Chave Privada [#175-risco-de-perda-de-chave-privada]
Os tokens alocados a um endereço específico só podem ser acessados com a chave privada que corresponde a esse endereço. Os Usuários entendem e aceitam que, se o arquivo de chave privada ou a senha da carteira for perdido ou roubado, o acesso ao endereço dos Usuários, bem como aos tokens a eles alocados, seria irrecuperável e permanentemente perdido. A Fundação não possui controle sobre os endereços dos Usuários; portanto, os Usuários não terão recurso para buscar quaisquer reembolsos, recuperações ou substituições junto à Fundação no caso de não conseguirem mais acessar o endereço dos Usuários, bem como os tokens, e/ou quaisquer tokens forem perdidos ou roubados.
### 17.6 Risco de Roubo [#176-risco-de-roubo]
Os Usuários entendem e aceitam que, embora os melhores esforços sejam empregados para reduzir potenciais ataques de software ao Website, a Rede e os contratos inteligentes relacionados, outros softwares envolvidos e/ou outros componentes tecnológicos podem ser expostos a ataques de hackers ou outros indivíduos que poderiam resultar em roubo ou perda dos tokens.
### 17.7 Risco de Ataques à Rede e Forks [#177-risco-de-ataques-à-rede-e-forks]
O Usuário entende e aceita que, como em outras blockchains, a blockchain utilizada para a Rede pode ser suscetível a ataques relacionados ao consenso, incluindo, mas não se limitando a, ataques de gasto duplo, ataques de poder de validação majoritária, ataques de censura e comportamento bizantino no algoritmo de consenso, ou estar sujeita a forks. Qualquer ataque bem-sucedido ou fork apresenta um risco para a Rede e/ou os contratos inteligentes relacionados, a execução e sequenciamento esperados e adequados de transações de tokens, a execução e sequenciamento esperados e adequados de computações de contratos, bem como os saldos de tokens na carteira dos Usuários.
Existem riscos associados ao uso de produtos baseados na Internet e em blockchain, incluindo, mas não se limitando a, o risco associado a hardware, software e conexões de internet, o risco de introdução de software malicioso e o risco de que terceiros possam obter acesso não autorizado a informações armazenadas na Conta do Usuário. Os Usuários aceitam e reconhecem que a Fundação não será responsável por quaisquer falhas de comunicação, interrupções, erros, distorções ou atrasos que possam experimentar ao usar o Website, a Rede e/ou os contratos inteligentes relacionados para transações, independentemente da causa.
## 18. Proteção de Dados [#18-proteção-de-dados]
18.1 Em relação à execução de seus serviços, a Fundação poderá tratar dados de identificação da empresa e dados pessoais dos Usuários para assegurar que os Participantes sejam adequadamente identificados e que suas declarações de Usuário, Organização e Dados sejam precisas e estejam de acordo com a [Política de Privacidade](/docs/terms/privacy-policy) da Carrot Fndn.
18.2 Na medida em que os Integradores da Rede (INTs) coletam dados pessoais de outros Usuários ou terceiros e os divulgam à Fundação publicando-os na Rede, é o INT que é responsável pela legalidade de qualquer tal Uso e tratamento, nos termos das leis de privacidade locais (por exemplo, GDPR ou Artigo 39 da LGPD no Brasil) e isentará a Fundação de quaisquer danos que surjam ou sejam reclamados contra a Fundação no caso de tratamento ilícito realizado sob a responsabilidade do INT.
Se quaisquer ferramentas fornecidas pela Rede forem utilizadas pelo INT para auxiliar na proteção de dados pessoais, é responsabilidade do INT assegurar que as ferramentas sejam utilizadas corretamente e mantidas atualizadas.
18.3 Ao aceitar estes Termos, o Usuário concorda que seus dados de identificação serão utilizados para fins de validação da cadeia de custódia e realização de verificação multipartes. A Carrot, por meio de seus Integradores de Rede, Recicladores e Auditores, garante que os dados de identificação de Geradores e Transportadores serão tratados como privados e mascarados no Explorer e em qualquer interface pública e gerenciados em estrita conformidade com as leis de privacidade locais. A divulgação pública de tais dados está condicionada ao consentimento declarado do Usuário no momento do cadastro. Os dados de toda a cadeia de custódia permanecerão visíveis em todos os momentos para a Fundação e auditores credenciados para fins de verificação e certificação por terceiros independentes, conforme necessário para a emissão de créditos (tokens) de alta integridade e elegíveis do ponto de vista regulatório. O exposto não se aplica à divulgação pública de dados de impacto ambiental em nível organizacional nos termos da Seção 7A (Programa de Reconhecimento de Impacto), que é regida exclusivamente pelos termos daquela Seção.
18.4 Cada parte é responsável pela aderência às leis de privacidade locais relativas à gestão de dados pessoais sob seu controle e tratamento efetivos. A responsabilidade da Fundação limita-se aos dados pessoais tratados diretamente por ela ou sob sua instrução e não se estende a dados tratados por INTs, suboperadores contratados pelos próprios Usuários ou terceiros fora do escopo operacional da Fundação.
18.5 A Fundação implementa e mantém medidas técnicas e administrativas apropriadas para proteger dados pessoais contra acesso não autorizado, destruição, perda, alteração ou divulgação indevida, conforme detalhado na [Política de Privacidade](/docs/terms/privacy-policy). Não obstante, os Usuários reconhecem que nenhum sistema tecnológico oferece segurança absoluta e que a Fundação não será responsável por incidentes de segurança decorrentes exclusivamente de vulnerabilidades zero-day ainda não identificadas pela comunidade de segurança, ataques em nível estatal ou de infraestrutura crítica além do controle razoável da Fundação, ou falhas em sistemas, redes ou infraestruturas de terceiros sobre os quais a Fundação não possui controle operacional direto.
18.6 No caso de um incidente de segurança que possa acarretar risco ou dano relevante aos titulares de dados, a Fundação notificará a autoridade supervisora competente e os titulares de dados afetados dentro dos prazos legais aplicáveis: 72 (setenta e duas) horas para as autoridades supervisoras do GDPR (GDPR, Art. 33) e a ANPD (LGPD, Art. 48 e Resolução CD/ANPD Nº 15/2024); e tão rapidamente quanto possível para o FDPIC (revDSG, Art. 24). A notificação incluirá (i) a natureza dos dados afetados; (ii) informações sobre os titulares de dados envolvidos; (iii) medidas técnicas adotadas; e (iv) riscos relacionados ao incidente e ações tomadas para mitigar seus efeitos.
18.7 Os Usuários são responsáveis por proteger a privacidade de dados pessoais de outros Usuários e terceiros sob seu controle ou inseridos na Rede. No caso de negligência grave, vazamento intencional ou ataques promovidos ou facilitados pelo Usuário, a Fundação poderá adotar as medidas previstas na Seção 11 destes Termos, incluindo suspensão, penalidades e ação legal, sem prejuízo da responsabilidade civil e criminal aplicável.
18.8 Uma parte não será responsabilizada por atos, omissões ou violações da legislação de proteção de dados cometidos pela outra parte, seus agentes e/ou contratados.
18.9 O descumprimento das obrigações estabelecidas nas leis de proteção de dados mencionadas e neste contrato pelo usuário resultará em sua rescisão imediata.
Atenção deve ser dada a leis como o Regulamento Geral de Proteção de Dados da UE (GDPR)[^1], a Convenção do Conselho da Europa para a Proteção de Indivíduos com relação ao Tratamento Automático de Dados Pessoais[^2], a Lei de Privacidade do Consumidor da Califórnia (CCPA)[^3] e a Lei Geral de Proteção de Dados Pessoais do Brasil (LGPD)[^4], para citar algumas.
[^1]: UE: Regulamento Geral de Proteção de Dados — gdpr.eu
[^2]: ETS Nº 108, Convenção para a Proteção de Indivíduos com relação ao Tratamento Automático de Dados Pessoais, Conselho da Europa (CoE).
[^3]: Agência de Proteção à Privacidade da Califórnia: Lei de Direitos de Privacidade da Califórnia de 2020 — cppa.ca.gov/regulations/
[^4]: LEI Nº 13.709, DE 14 DE AGOSTO DE 2018. BRASIL, Lei Geral de Proteção de Dados Pessoais (LGPD) — planalto.gov.br/ccivil\_03/\_ato2015-2018/2018/lei/l13709.htm
## 19. Modificações ao Website [#19-modificações-ao-website]
A Fundação reserva-se o direito, a seu exclusivo critério, de modificar, suspender ou descontinuar, temporária ou permanentemente, a prestação de seus Websites ou Rede (ou quaisquer funcionalidades ou partes dos mesmos) a qualquer momento e sem responsabilidade como resultado. A Fundação compromete-se a comunicar tais ações aos Participantes com antecedência em todas as ocasiões, exceto quando a ação tomada for necessária para proteger a segurança de todos os Participantes.
## 20. Impostos [#20-impostos]
Os Usuários são os únicos responsáveis por determinar quais impostos, se houver, se aplicam ao uso do Website, da Rede e/ou dos contratos inteligentes relacionados, bem como à transferência de Reivindicações Ambientais e Sociais. A Fundação não é responsável por determinar ou pagar os impostos que se aplicam a tal uso.
## 21. Disposições Gerais [#21-disposições-gerais]
### 21.1 Relação entre as Partes [#211-relação-entre-as-partes]
A Fundação e os Usuários são contratantes independentes. Estes Termos não criam, nem pretendem criar, uma parceria, franquia, joint venture, relação de agência, fiduciária ou empregatícia entre as Partes.
### 21.2 Divisibilidade [#212-divisibilidade]
Se qualquer disposição destes Termos for inválida, ilegal ou inexequível em qualquer jurisdição, tal invalidade, ilegalidade ou inexequibilidade não afetará qualquer outra disposição dos Termos ou invalidará ou tornará inexequível tal disposição em qualquer outra jurisdição. Mediante tal determinação de que qualquer disposição é inválida, ilegal ou inexequível, os Termos serão modificados para efetivar a intenção original da disposição original da forma mais próxima possível.
### 21.3 Cessão [#213-cessão]
Não obstante a possibilidade de conceder acesso à Conta do Usuário a outros Usuários, os Usuários não poderão ceder ou transferir quaisquer direitos e licenças concedidos sob estes Termos sem o consentimento prévio por escrito (bastando a forma de texto) da Fundação. A Fundação poderá livremente ceder ou transferir quaisquer direitos e licenças concedidos sob estes Termos sem restrição, mediante comunicação aos Usuários e Participantes informando-os de tais cessões.
### 21.4 Lei Aplicável e Jurisdição [#214-lei-aplicável-e-jurisdição]
Estes Termos, bem como o uso do Website, da Rede e dos contratos inteligentes relacionados, serão regidos e interpretados de acordo com as leis materiais da Suíça. A aplicação da Convenção das Nações Unidas sobre Contratos de Compra e Venda Internacional de Mercadorias será excluída.
Qualquer disputa decorrente de ou em conexão com estes Termos será submetida à jurisdição exclusiva dos tribunais da cidade de Zug, Suíça.
Não obstante a escolha de lei suíça e jurisdição estabelecidas acima, quando leis obrigatórias de proteção ao consumidor, regulamentações de proteção de dados ou outras disposições estatutárias não renunciáveis da jurisdição de residência do Usuário concedam direitos ou proteções que não possam ser excluídos ou limitados por contrato, tais disposições obrigatórias se aplicarão na medida exigida pela lei aplicável. Esta ressalva não afeta a validade ou exequibilidade de qualquer outra disposição destes Termos, nem constitui uma renúncia à lei suíça como lei aplicável para todas as matérias que as partes possam livremente contratar.
Para evitar dúvidas: (i) esta disposição se aplica quando a lei local é obrigatória e não pode ser afastada por contrato, como estatutos de proteção ao consumidor, leis de proteção de dados e regulamentações trabalhistas; (ii) não se aplica a questões comerciais ou operacionais livremente regidas por estes Termos; e (iii) a renúncia à ação coletiva estabelecida na Seção 13(21) se aplica na máxima extensão permitida pela lei obrigatória aplicável da jurisdição do Usuário.
# Retratação de Compra de Créditos
{/* Deliberately absent from terms/meta.json so it stays out of the sidebar — this page is reached from Clause 7.1 of the sale terms, not one of the four instruments a reader browses. Adding it to `pages` would undo that. It still routes, is indexed, and appears in the sitemap. */}
**Complemento aos [Termos e Condições de Venda de Créditos Ambientais](/docs/terms/credit-sales-terms), cláusula 7.**
## Seu direito de arrependimento [#seu-direito-de-arrependimento]
Se você comprou Créditos Ambientais como **consumidor**, pode desistir da compra dentro do prazo legal do seu país de domicílio, conforme a cláusula 7 dos [Termos e Condições de Venda de Créditos Ambientais](/docs/terms/credit-sales-terms):
* **Brasil:** 7 dias corridos contados da confirmação da compra (art. 49 do Código de Defesa do Consumidor). Esse direito é preservado mesmo que você tenha escolhido a Aposentadoria imediata.
* **Espaço Econômico Europeu e Reino Unido:** 14 dias contados da confirmação da compra — salvo se você consentiu expressamente com a Aposentadoria imediata e reconheceu a perda do direito de retratação no checkout; nesse caso, o direito se extingue com a Aposentadoria.
* **Outros países:** conforme a lei do seu domicílio. Se não houver direito de arrependimento, a compra é definitiva após concluída; nossa política de atendimento continua aplicável.
Os efeitos do arrependimento dependem do estado dos seus Créditos (em Conta, aposentados a seu pedido expresso, ou transferidos) e estão descritos na cláusula 7.2 dos Termos. Os reembolsos são feitos pelo mesmo meio de pagamento utilizado, corrigidos monetariamente quando a lei o exigir.
## Como exercer [#como-exercer]
Entre em contato dentro do prazo legal pelo e-mail **[support@carrot.eco](mailto:support@carrot.eco)** e declare de forma clara que deseja desistir da compra. **Não é exigida nenhuma fórmula específica** — basta qualquer declaração clara. Confirmaremos o recebimento do seu pedido imediatamente.
Para que possamos identificar a operação, informe:
* o número do pedido ou a descrição dos Créditos comprados;
* a data da compra;
* o nome do consumidor ou dos consumidores que realizaram a compra;
* o e-mail utilizado na compra.
# Anexos
Anexos utilizam um modelo de URL presigned. Os Integradores primeiro solicitam uma URL temporária à Carrot API, e então
fazem upload ou download dos dados do arquivo diretamente com a URL retornada.
## Criar URL de upload [#criar-url-de-upload]
Utilize `PUT /documents/{documentId}/attachments/{fileName}` para solicitar uma URL de upload.
Envie:
* `contentLength` (bytes)
* `contentType` (tipo MIME)
Após receber a URL:
1. Envie `PUT` para a URL presigned com o arquivo em formato binário.
2. Inclua o mesmo `Content-Type` declarado na solicitação da URL.
3. Envie `Content-Length` igual ao `contentLength` que você declarou. O `Content-Length` faz parte da
assinatura — a URL carrega `X-Amz-SignedHeaders=content-length;host` — então um comprimento
divergente falha com erro de assinatura. O `Content-Type` não é assinado, então uma divergência
ali falha de outra forma ou nem falha; envie-o corretamente mesmo assim.
4. Nenhum cabeçalho `Authorization` é necessário para a chamada de upload presigned.
## Obter URL de download [#obter-url-de-download]
Utilize `GET /documents/{documentId}/attachments/{fileName}` para solicitar uma URL temporária de download.
Em seguida, realize um `GET` padrão na URL retornada para obter o arquivo.
## Limites e comportamento [#limites-e-comportamento]
* Tamanho máximo de arquivo por upload: 10 MB.
* URLs de upload são válidas por 7 dias; URLs de download, por 2 minutos — solicite a URL de download
imediatamente antes de buscar o arquivo.
* Após o upload, você precisa referenciar o nome do arquivo no array `attachments` de um evento. Um
arquivo que nenhum evento referencia não pode ser baixado.
* Nomes de arquivo são únicos por documento: uma vez que um arquivo foi enviado com um determinado
nome, solicitar uma nova URL de upload para esse mesmo nome no mesmo documento é rejeitado com
`Attachment already exists` em vez de sobrescrever. A rejeição acontece na chamada de
criação da URL de upload, então solicitar uma URL para um nome cujos bytes nunca foram enviados
ainda funciona.
Consulte [Upload de Arquivos](/docs/integrations/guides/file-uploads) para padrões práticos de integração.
# Autenticação
A Carrot API utiliza OAuth 2.0 com credenciais de cliente e tokens bearer.
Não há etapa de login de usuário. As integrações se autenticam com um `clientId` e `clientSecret`.
## Fluxo de autenticação [#fluxo-de-autenticação]
1. Receba o `clientId` e `clientSecret` da equipe da Carrot API.
2. Solicite um token de acesso no endpoint de autenticação utilizando Basic Authentication.
3. Utilize o token bearer retornado no cabeçalho `Authorization` nas requisições à API.
```bash
curl --request POST \
--url https://auth.api.carrot.eco/oauth2/token \
--header 'Authorization: Basic ' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'scope=api.carrot.eco/main-scope'
```
## Ciclo de vida do token [#ciclo-de-vida-do-token]
* A duração máxima do `access_token` é atualmente de 1 hora.
* `expires_in` é retornado na resposta do endpoint de token e deve ser tratado como dado de runtime fornecido pela API (não codificado fixo na sua integração).
* Tokens de atualização (refresh tokens) não são utilizados neste fluxo.
* Solicite um novo token antes da expiração para evitar falhas nas requisições.
## Formato da resposta do token [#formato-da-resposta-do-token]
Resposta típica de sucesso:
```json
{
"access_token": "",
"token_type": "Bearer",
"expires_in": 3600,
"scope": "api.carrot.eco/main-scope"
}
```
## Utilizando tokens bearer [#utilizando-tokens-bearer]
Envie seu token em cada requisição:
```http
Authorization: Bearer
```
## Comportamento por ambiente [#comportamento-por-ambiente]
O ambiente é controlado pelas credenciais, não pela URL.
* Credenciais de teste operam apenas em dados de teste.
* Credenciais de produção operam apenas em dados de produção.
* Um token de teste não pode modificar documentos de produção, e o inverso também é verdadeiro.
Consulte [Ambientes](/docs/integrations/getting-started/environments) para orientações operacionais.
## Erros comuns de autenticação [#erros-comuns-de-autenticação]
* **`401`** — o token não pôde ser decodificado: sem header `Authorization`, ou um valor bearer que
não é um JWT decodificável. O corpo é `{"message":"Unauthorized"}`, sem campo `code`.
* **`403` (autorizador de borda)** — o token foi decodificado mas rejeitado: expirado, assinatura
inválida, esquema diferente de `Bearer`, escopo não permitido ou issuer divergente. O corpo é
`{"message":""}`, por exemplo `{"message":"Authorization token expired"}`. Não há envelope
`errors[]`.
* **`403` (`RESTRICTED_RESOURCE_ERROR`)** — token válido sem permissão para o recurso alvo, incluindo
uma credencial de teste acessando dados de produção ou o inverso. O corpo é o envelope `errors[]`
padrão descrito em [Erros](/docs/integrations/api/errors).
Um token expirado nunca produz `401` — ele é rejeitado na borda como `403`, então uma lógica de
renovação baseada em `401` nunca será acionada. Renove apenas quando o corpo vindo do gateway
identificar expiração (`{"message":"Authorization token expired"}`). As outras causas de `403` —
assinatura inválida, escopo ou issuer errado, `RESTRICTED_RESOURCE_ERROR` — não são resolvidas por
um token novo, e retentar depois de renovar apenas cria um laço.
***
[Ambientes](/docs/integrations/getting-started/environments) · [Início Rápido](/docs/integrations/getting-started/quick-start) · [Tratamento de Erros](/docs/integrations/guides/error-handling)
# Documentos
Documentos são o recurso principal na Carrot API. Um documento (comumente um [MassID](/docs/protocol/mass-ids)) se torna o
contêiner imutável para dados de rastreabilidade, e todas as alterações acontecem através de eventos adicionados.
## Criar documento [#criar-documento]
Utilize `POST /documents` para criar um documento com os campos obrigatórios:
* `category`
* `externalCreatedAt`
* `isPublic`
* `isPubliclySearchable`
* `type`
* exatamente um entre `participantId` — um participante resolvido via a
[API de Participantes](/docs/integrations/api/participants) — ou um objeto `participant` inline
* exatamente um entre `addressId` — um endereço resolvido via a
[API de Participantes](/docs/integrations/api/participants) — ou um objeto `address` inline
Enviar `participantId` e `participant` juntos, ou nenhum dos dois, falha na validação com
`400 VALIDATION_ERROR`. A mesma regra vale para `addressId` e `address`.
Prefira resolver participantes e endereços primeiro e referenciá-los por ID. A forma inline continua
suportada e faz find-or-create do registro, sendo a única maneira de criar um documento junto com um
novo participante ou endereço em uma única chamada.
Campos opcionais:
* `deduplicationId` — uma chave de criação única. Um valor repetido é rejeitado com
`409 CONFLICT_ERROR` (`Document deduplicationId: (…) already exists`), nunca reexecutado; veja
[Tratamento de Erros](/docs/integrations/guides/error-handling) para como tratar esse conflito.
* `tags`, `title`, `shortTitle` e campos de classificação.
## Recuperar documento por id [#recuperar-documento-por-id]
Utilize `GET /documents/{id}` para obter o payload completo do documento, incluindo:
* status e valor atuais
* referências de participante e endereço
* linha do tempo completa de eventos
* flags de visibilidade pública
## Nota de design: imutabilidade [#nota-de-design-imutabilidade]
Os dados do documento são apenas por adição (append-only) na prática. Não há endpoint `PATCH`/`PUT` para mutação de documento e
nem endpoint `DELETE`. Alterações operacionais são representadas como eventos.
Para um fluxo orientado à produção, consulte
[Enviando um MassID](/docs/integrations/guides/submitting-a-mass-id).
# Erros
Esta página resume os formatos padrão de erro e os modos de falha comuns para integrações com a Carrot API.
## Formato da resposta de erro [#formato-da-resposta-de-erro]
Payload típico de erro:
```json
{
"statusCode": 400,
"errors": [
{
"code": "BAD_REQUEST_ERROR",
"message": "Invalid type on $input.name, expected to be (string)",
"id": "3f6b0f2c-6d5f-4a3a-9f9a-1c2d3e4f5a6b",
"timestamp": 1684766595000
}
]
}
```
* `code` é um membro de enum em SCREAMING\_SNAKE — veja a tabela abaixo.
* `id` é um identificador aleatório de 36 caracteres no formato hexadecimal `8-4-4-4-12`.
* `timestamp` é epoch em **milissegundos**, enviado como número JSON, não como string.
* `errors` sempre contém exatamente uma entrada atualmente.
## Códigos de erro [#códigos-de-erro]
| HTTP | Código | Significado |
| ---- | -------------------------------- | ----------------------------------------------------------------------------------------- |
| 400 | `BAD_REQUEST_ERROR` | O payload da requisição falhou na validação de schema. |
| 400 | `VALIDATION_ERROR` | O payload está bem formado mas viola uma regra de negócio. |
| 401 | *(gateway)* | Sem header `Authorization`, ou um valor bearer que não é um JWT decodificável. |
| 403 | *(gateway)* | Token decodificado mas rejeitado: expirado, assinatura inválida, escopo ou issuer errado. |
| 403 | `RESTRICTED_RESOURCE_ERROR` | Token válido sem permissão para este recurso ou ambiente. |
| 404 | `NOT_FOUND_ERROR` | O recurso não existe ou não é compartilhado com o proprietário do token. |
| 405 | `METHOD_NOT_ALLOWED_ERROR` | Método HTTP não suportado neste caminho. |
| 409 | `CONFLICT_ERROR` | A operação conflita com dados existentes — incluindo um `deduplicationId` repetido. |
| 409 | `PENDING_PROCESS_CONFLICT_ERROR` | O documento solicitado ainda está sendo processado. Tente novamente mais tarde. |
| 429 | *(gateway)* | A taxa de requisições excedeu o limite permitido para o cliente. |
| 500 | `INTERNAL_SERVER_ERROR` | Falha inesperada no servidor. |
| 503 | `SERVICE_UNAVAILABLE_ERROR` | Serviço temporariamente indisponível ou requisição excedeu a janela de processamento. |
| 504 | `GATEWAY_TIMEOUT_ERROR` | Timeout upstream/expiração de sessão ao completar a requisição. |
As linhas marcadas com *(gateway)* são produzidas pela borda da API, não pelo serviço. Elas carregam
um corpo simples `{"message": "..."}` — sem o envelope `errors[]` e sem campo `code` — então
diferencie um `403` pelo formato do corpo, não apenas pelo status.
Para limites de taxa e cotas, consulte
[Limites de Taxa](/docs/integrations/reference/rate-limits).
Para padrões de recuperação de erros e estratégias de retentativa, consulte
[Tratamento de Erros](/docs/integrations/guides/error-handling).
# Eventos
Eventos são o mecanismo principal para evoluir o estado dos documentos. Após a criação de um documento, todas as
alterações relevantes são registradas como novos eventos.
## Criar evento [#criar-evento]
Utilize `POST /documents/{documentId}/events` para adicionar um evento à linha do tempo de um documento.
Prefira referenciar o participante e o endereço do evento por `participantId`/`addressId`; a forma
inline `participant`/`address` continua suportada e faz find-or-create do registro. Veja
[Participantes](/docs/integrations/api/participants).
## Eventos em lote [#eventos-em-lote]
Utilize `POST /documents/events` para criar múltiplos eventos para um documento em uma única
requisição. O corpo aceita exatamente um entre:
* `documentId` — adiciona os eventos a um documento existente; ou
* `document` — um payload completo de documento, criando o documento e seus eventos na mesma requisição.
Enviar os dois, ou nenhum, retorna `400` (`Exactly one of documentId or document must be provided`).
Cada evento no lote segue o mesmo schema do endpoint de evento individual acima, com uma
verificação extra que o endpoint individual não tem: as identidades de participante e endereço são
checadas contra conflitos entre os eventos do lote, então a mesma identidade carregando dados
diferentes falha.
A regra de identidade em si é a mesma nos dois endpoints — todo evento precisa carregar exatamente um
entre `participantId`/`participant` e exatamente um entre `addressId`/`address`. O endpoint individual
delega para este depois de rodar essa verificação por conta própria.
## Tipos lógicos de evento [#tipos-lógicos-de-evento]
| Tipo | Finalidade |
| --------- | ----------------------------------------------------------------------------------------------------------------------------- |
| `ACTOR` | Adiciona um papel de participante no documento e pode atualizar permissões. |
| `CLOSE` | Fecha o documento para atualizações futuras (exceto fluxos de relação específicos). |
| `CANCEL` | Cancela o documento e bloqueia ações futuras. Exige um atributo de metadados `reason` — veja abaixo. |
| `RELATED` | Vincula este documento a outro documento. |
| `UPDATE` | Atualiza campos específicos de visibilidade do documento. |
| `OUTPUT` | Nome convencional para um evento que cria um documento downstream. Sem schema dedicado — o payload `target` cria o documento. |
| `CUSTOM` | Nomes de eventos específicos de metodologia não cobertos pelos tipos nativos. |
O schema atual define seis schemas de eventos discriminados (`CloseEvent`, `ActorEvent`, `CancelEvent`,
`RelatedEvent`, `UpdateEvent`, `CustomEvent`). Qualquer nome de evento que a API não reserva é tratado
como evento `CUSTOM`, `OUTPUT` incluído.
A criação de um documento downstream é acionada pela presença do objeto `target` em **qualquer**
evento, não pelo nome do evento. Os dois endpoints informam o documento criado como
`targetDocumentId` — na entrada do evento na resposta do lote, e ao lado de `documentId` e `eventId`
na resposta do endpoint individual. Note que o schema da resposta individual não declara o campo,
então um cliente gerado pode descartá-lo; leia-o do corpo bruto se precisar dele.
Eventos `CANCEL` exigem que `metadata.attributes` inclua uma entrada chamada `reason` com valor não
vazio; omiti-la retorna `400` (`The reason metadata is required for CANCEL events`). O nome é
`reason` em minúsculas — a única exceção à convenção Title Case para nomes de atributos de metadados,
e o validador compara exatamente, então `Reason` não é reconhecido.
## Ordenação e consistência [#ordenação-e-consistência]
* `externalCreatedAt` deve ser anterior ao horário atual.
* `externalCreatedAt` deve ser igual ou posterior ao último evento registrado.
* Utilize `deduplicationId` ao reenviar submissões de eventos. Um valor repetido no mesmo documento é
rejeitado com `409 CONFLICT_ERROR`, nunca reexecutado — veja
[Tratamento de Erros](/docs/integrations/guides/error-handling).
## Documentos relacionados [#documentos-relacionados]
Em um evento `RELATED`, `relatedDocument.bidirectional` tem padrão `true`, o que grava o evento
espelhado no documento relacionado. Quando `bidirectional` é `true`, `isPublic` é obrigatório no
documento relacionado. Quando é `false` não há evento espelhado a descrever, então `eventName`,
`eventLabel` e `preserveSensitiveData` são todos rejeitados.
Para definições completas de eventos e alinhamento com metodologias, consulte
[Especificação de Eventos](/docs/integrations/reference/event-specification).
# Visão Geral da API
A Carrot API é uma API centrada em documentos utilizada por [Integradores](/docs/protocol/network-integrators) para enviar e recuperar dados de rastreabilidade.
A superfície pública é intencionalmente pequena: 11 endpoints em 5 recursos (`documents`, `events`, `attachments`, `participants`, `addresses`).
## URL base [#url-base]
* API: `https://api.carrot.eco`
* Auth: `https://auth.api.carrot.eco/oauth2/token`
* Registry: `https://registry.carrot.eco`
## Convenções principais [#convenções-principais]
* O tipo de conteúdo é JSON para requisições e respostas da API.
* Valores de data e hora seguem ISO 8601 (por exemplo, `2020-01-01T00:00:00.000Z`).
* Campos de metadados são estruturas flexíveis de chave-valor.
* O histórico de documentos é apenas por adição (append-only) através de eventos.
## Ambientes [#ambientes]
A Carrot utiliza a mesma URL base para tráfego de teste e produção. A seleção do ambiente é baseada no
`clientId` utilizado para solicitar um token de acesso.
* Credenciais de teste só podem operar em documentos de teste.
* Credenciais de produção só podem operar em documentos de produção.
* Relações entre documentos de ambientes diferentes não são permitidas.
## Mapa de recursos [#mapa-de-recursos]
* [Autenticação](/docs/integrations/api/authentication): fluxo de credenciais de cliente OAuth 2.0 e ciclo de vida do token.
* [Documentos](/docs/integrations/api/documents): criar e recuperar documentos.
* [Eventos](/docs/integrations/api/events): adicionar eventos imutáveis às linhas do tempo dos documentos, individualmente ou em lote.
* [Anexos](/docs/integrations/api/attachments): gerar URLs presigned para upload/download.
* [Participantes](/docs/integrations/api/participants): cadastrar participantes e seus endereços.
* [Erros](/docs/integrations/api/errors): códigos de erro, limites de taxa e solução de problemas.
## Início rápido da integração [#início-rápido-da-integração]
Para uma sequência completa de onboarding, consulte
[Início Rápido de Integrações](/docs/integrations/getting-started/quick-start).
# Participantes
Participantes são as organizações e pessoas que são donas de [documentos](/docs/integrations/api/documents)
e aparecem em eventos. Cadastre-os aqui para obter os valores de `participantId` e `addressId` usados ao
criar um documento.
Todas as operações de leitura são restritas à credencial do chamador: registros criados pela sua credencial
retornam todos os campos, enquanto registros de outros participantes retornam apenas os campos de
identificação e localização, com a rua mascarada.
## Participantes [#participantes]
### Criar participante [#criar-participante]
Use `POST /participants` para cadastrar um participante no conjunto de dados da sua credencial. A resposta
retorna o `id` gerado — envie-o como `participantId` ao criar documentos e eventos.
### Obter participante por chave [#obter-participante-por-chave]
Use `GET /participants` para buscar um participante pela chave natural — código do país, tipo de documento e
número do documento. O número do documento (`taxId`) trafega na query string.
### Obter participante por id [#obter-participante-por-id]
Use `GET /participants/{id}` para obter um participante pelo identificador da Carrot.
## Endereços [#endereços]
Endereços pertencem a um participante, então toda operação de endereço é restrita a um `participantId`.
### Criar endereço [#criar-endereço]
Use `POST /participants/{participantId}/addresses` para adicionar um endereço a um participante. A resposta
retorna o `id` gerado, que é referenciado como `addressId` ao criar um documento.
### Listar endereços do participante [#listar-endereços-do-participante]
Use `GET /participants/{participantId}/addresses` para listar os endereços de um participante. Endereços que
sua credencial não criou são retornados apenas com os campos de identificação e localização e com a rua
mascarada.
Para a sequência completa de onboarding, veja o
[Guia rápido de integrações](/docs/integrations/getting-started/quick-start).
# Conecte Seu Agente de IA
O servidor Carrot Docs [Model Context Protocol (MCP)](https://modelcontextprotocol.io/) oferece ao seu agente de IA acesso somente leitura à documentação publicada da Carrot. Ele é público, sem autenticação e exclusivo para documentação. Pode pesquisar e ler páginas publicadas e termos do glossário, mas não pode chamar a [Carrot API](/docs/integrations/api), gravar dados, acessar dados privados de projetos nem agir em seu nome.
Clientes de IA não instalam este servidor automaticamente quando um usuário menciona `docs.carrot.eco`. Adicione o servidor no seu cliente primeiro; depois, peça ao agente para usar o MCP da Carrot Docs ao responder com base na documentação. Se o MCP não estiver disponível, use [/llms.txt](/llms.txt) ou [/llms-full.txt](/llms-full.txt) como alternativas legíveis por máquina.
## Endpoint [#endpoint]
| Campo | Valor |
| ------------ | -------------------------------------------- |
| URL | `https://docs.carrot.eco/mcp` |
| Transporte | Streamable HTTP |
| Autenticação | Nenhuma |
| Método | `POST` |
| Conteúdo | Documentação publicada e termos do glossário |
| Locales | `en`, `pt-BR` |
## Claude [#claude]
Use o Claude.ai ou o Claude Desktop para adicionar o Carrot Docs como um conector remoto MCP e, em seguida, conecte o Claude Code com a mesma URL do servidor.
Este é um servidor MCP remoto via Streamable HTTP. Não o configure como um servidor stdio local no `claude_desktop_config.json`.
### Claude.ai e Claude Desktop [#claudeai-e-claude-desktop]
1. Abra `Customize > Connectors`.
2. Selecione `Add custom connector`.
3. Defina o nome do conector como `Carrot Docs`.
4. Defina a URL do servidor como `https://docs.carrot.eco/mcp`.
5. Ative o conector nas conversas.
6. Salve o conector e recarregue o Claude, se necessário.
### Claude Code [#claude-code]
Use estes comandos para adicionar e verificar o servidor:
```bash
claude mcp add --transport http carrotDocs https://docs.carrot.eco/mcp
claude mcp list
```
## Cursor [#cursor]
Adicione o servidor manualmente no Cursor com um arquivo `mcp.json`.
```json
{
"mcpServers": {
"carrotDocs": {
"url": "https://docs.carrot.eco/mcp"
}
}
}
```
Reinicie o Cursor após salvar o arquivo para que o novo servidor apareça na lista MCP.
## Codex [#codex]
Use os comandos MCP do Codex para adicionar o servidor e confirmar que ele está registrado.
```bash
codex mcp add carrotDocs --url https://docs.carrot.eco/mcp
codex mcp list
```
Se preferir configurar o Codex diretamente, adicione o mesmo servidor em `~/.codex/config.toml`:
```toml
[mcp_servers.carrotDocs]
url = "https://docs.carrot.eco/mcp"
```
## Cliente genérico Streamable HTTP [#cliente-genérico-streamable-http]
Qualquer cliente MCP que suporte Streamable HTTP pode se conectar ao servidor Carrot Docs.
```bash
curl --request POST \
--url https://docs.carrot.eco/mcp \
--header 'Content-Type: application/json' \
--header 'Accept: application/json, text/event-stream' \
--data '{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "",
"capabilities": {},
"clientInfo": {
"name": "example-client",
"version": "0.1.0"
}
}
}'
```
Após a negociação, o servidor retorna:
```text
MCP-Protocol-Version:
```
O endpoint também responde a uma solicitação GET simples com `405 Method Not Allowed`:
```bash
curl --request GET https://docs.carrot.eco/mcp
```
Exemplo de configuração do cliente:
```json
{
"name": "carrotDocs",
"transport": "streamable-http",
"url": "https://docs.carrot.eco/mcp"
}
```
A Carrot não exige que você fixe uma versão de protocolo. Deixe que o cliente anuncie `` e permita que a negociação chegue a ``.
## Resumo das ferramentas [#resumo-das-ferramentas]
O servidor expõe cinco ferramentas somente leitura:
| Ferramenta | Finalidade |
| ------------------- | ----------------------------------------------------------------------- |
| `search_docs` | Pesquisar a documentação publicada por palavra-chave, tema ou conceito. |
| `get_doc` | Ler o conteúdo completo de uma única página de documentação. |
| `get_glossary_term` | Obter uma definição do glossário e o contexto relacionado. |
| `browse_docs` | Explorar a documentação por seção e navegar pela árvore de conteúdo. |
| `get_related_docs` | Exibir páginas próximas, referências e leitura complementar. |
Observações:
* Os resultados de pesquisa são limitados a 25 itens.
* Os limites padrão do serviço são 60 requisições por minuto e 10 requisições concorrentes por IP de cliente.
* As respostas são retornadas como envelopes estruturados de sucesso ou erro dentro do conteúdo de texto do MCP.
## Instrução para o agente [#instrução-para-o-agente]
Use o servidor Carrot Docs MCP ao responder perguntas sobre a documentação da Carrot, incluindo conceitos da [Rede Carrot](/docs/network), termos do glossário, [créditos ambientais](/docs/protocol/credits), [frameworks de metodologia](/docs/standard/concepts/mvf), orientação para compradores, processo de integração de [Integradores](/docs/protocol/network-integrators) e a documentação da Carrot API.
## Exemplos de prompts [#exemplos-de-prompts]
* Explique como os MassIDs apoiam a rastreabilidade na Rede Carrot.
* Resuma como os créditos ambientais rastreáveis são criados.
* Encontre o fluxo de autenticação da Carrot API.
* Mostre a orientação de privacidade e mascaramento para cargas de dados de integração.
* Encontre páginas relacionadas à governança e à Carrot Foundation.
* Consulte a orientação atual da metodologia BOLD Recycling.
## Solução de problemas [#solução-de-problemas]
* Se o seu cliente não suportar servidores MCP remotos via Streamable HTTP, ele não poderá se conectar ao Carrot Docs.
* Se o alternador do conector ou da ferramenta estiver desligado no chat atual, ative-o antes de pedir ao agente para usar o servidor.
* Se você alterar um arquivo de configuração manual, reinicie ou recarregue o cliente antes de testar novamente.
* Se a seleção de ferramentas não for automática, peça explicitamente ao agente para usar o servidor Carrot Docs MCP.
* Se aparecerem respostas `429`, aguarde e tente novamente depois que a janela de limite de taxa expirar.
* Se a pesquisa não retornar nada, tente o nome exato do termo publicado na documentação ou no glossário.
* Se um tópico deveria existir, mas não for encontrado, use primeiro `browse_docs` e depois `get_related_docs` para expandir o caminho.
* Se você precisar de dados privados ou acesso de escrita, este servidor não pode fornecer isso. Use a Carrot API.
# Conceitos Fundamentais
Esses conceitos formam a base do modelo de integração da [Carrot API](/docs/integrations/api). Entenda-os
antes de escrever suas primeiras chamadas à API.
## O que é um documento? [#o-que-é-um-documento]
Um documento é a estrutura de dados raiz para um registro de rastreabilidade. Ele registra e representa
o histórico completo de um processo logístico ou fluxo de uma massa — da origem ao destino final — de
forma transparente e auditável. Cada documento recebe um identificador único e é classificado por
[categoria, tipo e subtipo](/docs/integrations/reference/waste-classification).
Documentos podem se relacionar com outros documentos por meio de eventos, permitindo que a plataforma
construa uma visão integrada de processos conectados. Por exemplo, um
[MassID](/docs/protocol/mass-ids) rastreando um lote de resíduos pela
[cadeia de suprimentos](/docs/protocol/supply-chain) é um documento que armazena campos de identidade
e classificação, enquanto todas as mudanças de estado são representadas por eventos anexados à sua
linha do tempo.
Referência: [Documents API](/docs/integrations/api/documents).
## Que história um MassID precisa contar? [#que-história-um-massid-precisa-contar]
Todo MassID deve contar uma história completa — com início, meio e fim claros. Ao enviar dados para a
Carrot API, garanta que o registro seja coeso, rastreável e detalhado o suficiente para compreender a
origem da massa, sua jornada e seu destino final.
Um MassID bem documentado inclui informações como:
* **Ponto de origem** — onde o resíduo foi gerado ou coletado
* **Etapas logísticas** — coleta, pesagem (peso bruto e líquido), identificação do veículo
* **Pontos de transbordo** — transferências intermediárias ou áreas de preparação
* **Participantes envolvidos** — cada ator na cadeia de custódia
* **Destino final** — a unidade de reciclagem ou [tratamento biológico](/docs/glossary#biological-treatment)
Cada informação fortalece a rastreabilidade, a integridade dos dados e o valor percebido do
[crédito ambiental](/docs/protocol/credits) resultante. Quanto mais contexto você fornecer, maior
a confiança para compradores de créditos e auditores.
Veja [Enviando um MassID](/docs/integrations/guides/submitting-a-mass-id) para o fluxo de
implementação passo a passo.
## Imutabilidade por eventos [#imutabilidade-por-eventos]
Não há endpoint de atualização ou exclusão. Em vez disso, você adiciona eventos para representar
mudanças operacionais ao longo do tempo. A plataforma utiliza um modelo **event-sourced**: cada
submissão é anexada à linha do tempo do documento, e o estado atual é derivado do log de eventos.
Essa imutabilidade é fundamental para o mercado de créditos ambientais. Uma vez que os dados são
registrados e os créditos são emitidos e negociados, os compradores precisam da garantia de que os
registros subjacentes são permanentes e não podem ser alterados após o fato. Dados imutáveis
fortalecem a credibilidade do sistema para compradores, reguladores e auditores.
Se você precisar corrigir um erro, não tente editar o documento. Em vez disso, cancele-o usando um
evento `CANCEL` e crie um novo documento com os dados corrigidos, preservando o fluxo completo de
rastreabilidade.
Referência: [Events API](/docs/integrations/api/events) · [Error Handling](/docs/integrations/guides/error-handling).
## Eventos e metadados [#eventos-e-metadados]
Eventos representam ações operacionais concretas realizadas em um documento — por exemplo, coleta de
resíduos, pesagem, transporte ou entrega em uma unidade de reciclagem. Juntos, os eventos formam a
**linha do tempo** do documento: um registro cronologicamente ordenado de tudo que aconteceu com a
massa.
Cada evento pode carregar **metadados** (também chamados de **atributos**) — pares chave-valor que
fornecem contexto adicional sobre o que aconteceu. Exemplos incluem data, localização, placa do
veículo, identificador do operador ou medição de peso. Os metadados enriquecem a linha do tempo e
tornam o registro de rastreabilidade mais robusto para auditorias e verificação.
Alguns campos de metadados são exigidos por [regras da metodologia](/docs/protocol/methodology-execution)
específicas, enquanto outros são recomendados como boas práticas. Quanto mais detalhes você fornecer,
mais forte será o resultado da validação.
Referência: [Event Specification](/docs/integrations/reference/event-specification) ·
[Data Formats](/docs/integrations/reference/data-formats).
## Ordenação de eventos [#ordenação-de-eventos]
A cronologia dos eventos importa. O campo `externalCreatedAt` deve ser válido em relação às entradas
existentes na linha do tempo, portanto sua integração deve preservar a ordem do sistema de origem e as
retentativas. A plataforma não permite eventos com data futura — os timestamps devem refletir quando a
ação ocorreu no sistema de origem.
## Visibilidade e privacidade [#visibilidade-e-privacidade]
A visibilidade pública (`isPublic`) e a visibilidade pesquisável (`isPubliclySearchable`) fazem parte
do modelo base e podem ser ajustadas por meio de fluxos de eventos.
Guia: [Privacy & Masking](/docs/integrations/guides/privacy-and-masking).
## Idempotência e resiliência [#idempotência-e-resiliência]
Use `deduplicationId` para retentativas de criação/eventos e trate erros transitórios de forma
diferente dos erros de validação.
Guia: [Error Handling](/docs/integrations/guides/error-handling).
# Ambientes
A [Carrot API](/docs/integrations/api) utiliza separação de ambientes baseada em credenciais, com a mesma URL base.
## Modelo de ambientes [#modelo-de-ambientes]
* URL base da API: `https://api.carrot.eco`
* URL de autenticação: `https://auth.api.carrot.eco/oauth2/token`
* O ambiente é selecionado pelo par de credenciais (`clientId` / `clientSecret`), não pelo host.
## Comportamento: teste vs. produção [#comportamento-teste-vs-produção]
* Credenciais de teste operam apenas em dados de teste.
* Credenciais de produção operam apenas em dados de produção.
* Relacionamentos entre ambientes não são permitidos.
## Recomendações para o ciclo de vida das credenciais [#recomendações-para-o-ciclo-de-vida-das-credenciais]
* Armazene as credenciais em seu gerenciador de segredos.
* Faça a rotação das credenciais por meio de rollout controlado.
* Solicite novos bearer tokens antes da expiração.
## Checklist de go-live [#checklist-de-go-live]
1. Valide o fluxo completo em teste (criação, adição de evento, upload de anexo, recuperação).
2. Confirme o comportamento de retentativas/idempotência com [`deduplicationId`](/docs/integrations/guides/error-handling).
3. Confirme o comportamento de rate limit sob a vazão esperada.
4. Promova para credenciais de produção.
Referências relacionadas:
* [Autenticação](/docs/integrations/api/authentication)
* [Rate Limits](/docs/integrations/reference/rate-limits)
# Início Rápido
> **Começando agora?** Comece explorando um MassID de referência completo no
> [Carrot Registry](https://registry.carrot.eco/document/0659ba41-e391-4d03-b5ba-537a9129326c) —
> depois volte para aprender como construir um.
Este guia apresenta o fluxo base da [Carrot API](/docs/integrations/api) — da autenticação à
recuperação de documentos — para que você possa verificar sua integração de ponta a ponta.
## Trilha de aprendizado do integrador [#trilha-de-aprendizado-do-integrador]
## 1) Solicitar um token de acesso [#1-solicitar-um-token-de-acesso]
Use OAuth 2.0 client credentials:
```bash
curl --request POST \
--url https://auth.api.carrot.eco/oauth2/token \
--header 'Authorization: Basic ' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'scope=api.carrot.eco/main-scope'
```
Detalhes do endpoint: [Autenticação](/docs/integrations/api/authentication).
## 2) Resolver participantes e endereços [#2-resolver-participantes-e-endereços]
Documentos e eventos referenciam um participante e um endereço **por ID**. Recupere-os por chave, ou crie-os, antes de criar o documento:
```http
GET /participants?countryCode=BR&taxIdType=CNPJ&taxId=11111111111111
GET /participants/{participantId}/addresses
POST /participants
POST /participants/{participantId}/addresses
Authorization: Bearer
```
Detalhes do endpoint: [Participantes](/docs/integrations/api/participants).
## 3) Criar um documento [#3-criar-um-documento]
Crie o registro base de rastreabilidade, referenciando o `participantId` e o `addressId` da etapa anterior:
```http
POST /documents
Authorization: Bearer
```
Objetos `participant`/`address` inline continuam suportados e fazem find-or-create do registro — prefira passar `participantId`/`addressId`, e envie exatamente uma das formas de cada.
Detalhes do endpoint: [Documentos](/docs/integrations/api/documents).
## 4) Adicionar um evento [#4-adicionar-um-evento]
Adicione um evento na linha do tempo para representar uma ação de negócio:
```http
POST /documents/{documentId}/events
Authorization: Bearer
```
Detalhes do endpoint: [Eventos](/docs/integrations/api/events).
Para operações em volume, use o endpoint de lote (`POST /documents/events`) para enviar múltiplos eventos em uma única requisição. Veja [Eventos — Eventos em lote](/docs/integrations/api/events#eventos-em-lote).
## 5) Recuperar e validar o estado [#5-recuperar-e-validar-o-estado]
Busque o documento completo e verifique a consistência da linha do tempo:
```http
GET /documents/{id}
Authorization: Bearer
```
Detalhes do endpoint: [Documentos](/docs/integrations/api/documents).
## 6) Adicionar proteções para produção [#6-adicionar-proteções-para-produção]
* Use `deduplicationId` em requisições de criação/evento que podem ser retentadas.
* Aplique ordenação de timestamps nos eventos.
* Adicione rate limiting no cliente e estratégias de retentativas com backoff.
Continue com:
* [Conceitos Fundamentais](/docs/integrations/getting-started/core-concepts) — o modelo de documento e a arquitetura orientada a eventos.
* [Ambientes](/docs/integrations/getting-started/environments) — credenciais de teste vs. produção e checklist de go-live.
* [Submeter um MassID](/docs/integrations/guides/submitting-a-mass-id) — passo a passo completo do ciclo de vida.
### Diagram: integrator-roadmap
Este roteiro do integrador organiza o caminho de integração desde explorar um MassID até Início Rápido, Conceitos Fundamentais, envio de MassID, trilhas BOLD Recycling e BOLD Carbon por metodologia, referências de eventos, privacidade e mascaramento, e ambientes de go-live. A divisão e a convergência mostram que o integrador aprende o fluxo comum, ramifica por metodologia e volta a convergir antes do lançamento.
# Tratamento de Erros
Este guia cobre padrões de recuperação operacional para integração com a [Carrot API](/docs/integrations/api).
Para códigos de erro dos endpoints e formato do payload, consulte [Erros da API](/docs/integrations/api/errors).
## Classifique as falhas primeiro [#classifique-as-falhas-primeiro]
* `4xx`: problemas na requisição, dados ou integração. Corrija o payload ou o fluxo.
* `5xx`: problemas transitórios na plataforma ou upstream. Retente com backoff.
## Tabela de decisão de retentativas [#tabela-de-decisão-de-retentativas]
| Código de Status | Erro | Ação |
| --------------------- | ----------------------------------------- | ------------------------------------------------------------------------------- |
| `400` | Erro de validação | **Abortar** — corrija o payload e reenvie |
| `403` | Token expirado (corpo do gateway) | **Renove** o token e retente uma vez |
| `401` / `403` | Outras falhas de autenticação/autorização | **Abortar** — verifique as credenciais ou permissões |
| `404` | Recurso não encontrado | **Abortar** — verifique os IDs no caminho da requisição |
| `409` | `PENDING_PROCESS_CONFLICT_ERROR` | **Retentar** após 2-5 segundos — um processo em segundo plano está em andamento |
| `409` | `deduplicationId` duplicado | **Pare** — sua tentativa anterior teve sucesso; não retente nem reenvie |
| `409` | Outros erros de conflito | **Abortar** — corrija o conflito de dados, não retente como está |
| `422` | Entidade não processável | **Abortar** — corrija a estrutura do payload |
| `429` | Limite de taxa excedido | **Retentar** com backoff exponencial |
| `500` | Erro interno do servidor | **Retentar** com backoff exponencial + `deduplicationId` |
| `502` / `503` / `504` | Gateway/serviço indisponível | **Retentar** com backoff exponencial + `deduplicationId` |
## Estratégia de retentativas [#estratégia-de-retentativas]
* Use backoff exponencial limitado para falhas transitórias (início em 1s, máximo 30s, máximo 5 retentativas).
* Reutilize o `deduplicationId` em chamadas retentáveis de criação/evento — veja abaixo.
* Pare de retentar em falhas de validação determinísticas — todo `4xx` exceto `409 PENDING_PROCESS_CONFLICT_ERROR`, `429` e o `403` de token expirado, que se resolve renovando o token em vez de retentar a mesma requisição.
## Mecânica do deduplicationId [#mecânica-do-deduplicationid]
O `deduplicationId` é uma chave de **criação única** para operações de escrita:
1. **Gere** um ID único **antes** da primeira tentativa
2. **Armazene-o** junto com a operação no seu sistema
3. **Reutilize** o mesmo ID em cada retentativa dessa operação
O ID tem escopo por [Integrador](/docs/protocol/network-integrators). Isso é crítico para
`POST /documents` e `POST /documents/{id}/events`.
Se o servidor já processou sua requisição, a retentativa é rejeitada com `409 CONFLICT_ERROR`
(`Document deduplicationId: (…) already exists`). Esse conflito é a confirmação de que a escrita
original teve sucesso e nenhuma duplicata foi criada — **não** é um erro a corrigir e **não** é
sinal para retentar como está. A resposta não carrega o id original do documento ou do evento.
Uma resposta perdida de `POST /documents` não é, portanto, recuperável sozinho pela API. A única
leitura de documento é `GET /documents/{id}`: não existe consulta por `externalId` nem por
`deduplicationId`, e o `409` da retentativa não devolve o id. Envie `externalId` mesmo assim — é o
que o suporte da Carrot precisa para localizar o documento — mas trate a recuperação do id como um
pedido de suporte, não como uma chamada self-service. Não há forma segura de repetir a escrita por conta própria:
reutilizar o `deduplicationId` devolve o `409` sem o id, e usar um novo cria um segundo documento.
Registre o id da primeira resposta bem-sucedida antes de qualquer outra coisa, e mantenha o timeout
da requisição generoso o bastante para que um commit lento não pareça uma resposta perdida.
## Padrão de recuperação por imutabilidade [#padrão-de-recuperação-por-imutabilidade]
Como os documentos seguem um modelo imutável baseado em eventos (veja [Conceitos Fundamentais](/docs/integrations/getting-started/core-concepts)), um passo incorreto na linha do tempo não pode ser corrigido no local.
### CANCEL e recriação [#cancel-e-recriação]
Quando um documento possui dados incorretos (ex: participante errado), cancele-o e crie um substituto corrigido:
```text
1. POST /documents/{wrongDocumentId}/events
{
"name": "CANCEL",
"metadata": {
"attributes": [
{ "name": "reason", "value": "Participante errado no documento original", "isPublic": true }
]
},
...
}
2. POST /documents
{ ...dados corrigidos do documento... }
3. POST /documents/{newDocumentId}/events
{
"name": "RELATED",
"relatedDocument": {
"documentId": "{wrongDocumentId}",
"bidirectional": true,
"isPublic": true
},
...
}
```
Um evento `CANCEL` precisa carregar um atributo de metadados `reason` não vazio; omiti-lo retorna
`400` com `The reason metadata is required for CANCEL events`. Todo atributo de metadados também
exige o próprio `isPublic`, então o objeto do atributo precisa estar completo.
O evento `RELATED` cria um vínculo de rastreabilidade entre o documento cancelado e seu substituto, mantendo um histórico auditável.
## Limites de taxa [#limites-de-taxa]
A [Carrot API](/docs/integrations/api) aplica limites de taxa **por cliente de API** (consulte [Limites de Taxa](/docs/integrations/reference/rate-limits) para a referência completa):
| Limite | Valor |
| ---------- | -------------------------- |
| Sustentado | 20 requisições por segundo |
| Burst | 30 requisições |
O limite é idêntico em teste e produção: o ambiente é selecionado pela sua credencial, não por uma
faixa de throttling separada.
Implemente um token bucket ou leaky bucket no lado do cliente para respeitar os limites. Ao receber um `429`, aplique backoff exponencial antes de retentar.
## Observabilidade [#observabilidade]
Registre estes campos de cada resposta da API para depuração e suporte:
* **Request ID** — retornado nos headers da resposta
* **Seu `externalId`** — seu ID de correlação interno
* **Campos do envelope de erro** — `errors[].code`, `errors[].id`, `errors[].timestamp`
* **Contagem de retentativas** — quantas tentativas foram feitas
* **Motivo da falha terminal** — por que as retentativas pararam
# Upload de Arquivos
Os anexos do Carrot utilizam um fluxo de URL presigned em dois passos.
## Passo 1: Solicitar URL de upload [#passo-1-solicitar-url-de-upload]
Chamada:
`PUT /documents/{documentId}/attachments/{fileName}`
Com:
* `contentLength` (bytes)
* `contentType` (tipo MIME)
Referência: [API de Attachments](/docs/integrations/api/attachments).
## Passo 2: Fazer upload diretamente no storage [#passo-2-fazer-upload-diretamente-no-storage]
Use a URL retornada e envie os bytes do arquivo com o mesmo tipo MIME.
* Nenhum bearer token é necessário na chamada de upload presigned.
* Mantenha os headers da requisição de upload consistentes com o payload do passo 1.
## Práticas recomendadas [#práticas-recomendadas]
* Aplique o limite de 10 MB no lado do cliente antes do upload — veja [Limites de Requisição](/docs/integrations/reference/rate-limits).
* Use nomes de arquivo determinísticos quando possível.
* Persista os nomes dos arquivos enviados para referenciá-los depois nos metadados de eventos.
## Fluxo de download [#fluxo-de-download]
Solicite uma URL temporária de download via:
`GET /documents/{documentId}/attachments/{fileName}`
Em seguida, faça o fetch da URL retornada.
Guias relacionados:
* [Submissão de um MassID](/docs/integrations/guides/submitting-a-mass-id) — upload de arquivos no contexto do ciclo de vida completo de um documento.
# Integração com Metodologias
Cada [metodologia](/docs/methodologies) adiciona seus próprios eventos obrigatórios, papéis de participantes e regras
de validação além do [fluxo base de integração](/docs/integrations/guides/submitting-a-mass-id). Toda
metodologia possui um guia de integração dedicado, versionado junto com a
[Methodology Verification Application (MvA)](/docs/standard/concepts/mva) que ele referencia.
## Guias disponíveis [#guias-disponíveis]
| Metodologia | Guia |
| ----------------- | ------------------------------------------------------------------------------ |
| BOLD Recycling | [v1.0.0](/docs/methodologies/bold-recycling/framework/application/integration) |
| BOLD Carbon (CH₄) | [v1.0.0](/docs/methodologies/ams-iii-f/bold-carbon/application/integration) |
## Antes de começar [#antes-de-começar]
Certifique-se de estar familiarizado com:
* [Enviando um MassID](/docs/integrations/guides/submitting-a-mass-id) — o fluxo base da API compartilhado por todas as metodologias.
* [Conceitos principais](/docs/integrations/getting-started/core-concepts) — modelo de documentos, ordenação de eventos e idempotência.
# Permissões
O acesso a documentos é controlado por eventos `ACTOR` — um modelo de permissão orientado a eventos.
Consulte a [Especificação de Eventos](/docs/integrations/reference/event-specification) para a referência
completa de categorias de eventos.
## Regras básicas [#regras-básicas]
* A [integração](/docs/protocol/network-integrators) criadora começa com permissões de escrita nos documentos criados.
* Todo documento inclui automaticamente um ACTOR de nível de sistema para que os serviços da plataforma
possam ler e criar eventos quando necessário.
* Participantes e papéis adicionais podem ser concedidos por meio de eventos ACTOR.
* As permissões ACTOR mais recentes para um participante são as permissões efetivas ("última escrita prevalece").
## Estrutura de permissões [#estrutura-de-permissões]
Cada política é indexada por `participantId` e define um efeito (`ALLOW` / `DENY`), as ações
que abrange e uma condição opcional.
Política de permissão típica:
```json
{
"f56ed1cf-bfef-4299-8088-449a5d405130": [
{
"effect": "ALLOW",
"actions": ["WRITE", "READ"],
"condition": {
"$in": {
"eventNames": ["RELATED"]
}
}
}
]
}
```
Política de negação típica:
```json
{
"f56ed1cf-bfef-4299-8088-449a5d405130": [
{
"effect": "DENY",
"actions": ["WRITE"]
}
]
}
```
Se `condition` for omitido, a política se aplica a todo o contexto do documento.
## Padrão de implementação recomendado [#padrão-de-implementação-recomendado]
1. Criar o documento.
2. Adicionar eventos de papel dos participantes em ordem explícita.
3. Validar o comportamento de acesso resultante nos testes de integração.
4. Enviar um array `permissions` vazio no ACTOR para remover o acesso do participante quando necessário.
## Cenários entre integradores [#cenários-entre-integradores]
Para relacionar um documento ou adicionar eventos em um documento de outra integração, um participante
existente com acesso deve adicionar seu participante como ACTOR com permissão `WRITE` naquele documento.
## Armadilhas comuns [#armadilhas-comuns]
* Enviar atualizações ACTOR duplicadas/conflitantes sem ordenação determinística.
* Assumir acesso implícito para participantes não modelados explicitamente.
* Misturar credenciais de teste/produção em fluxos de permissão entre integradores.
Referência: [API de Eventos](/docs/integrations/api/events).
# Privacidade e Mascaramento
A plataforma Carrot foi projetada para tornar a logística da cadeia de suprimentos transparente e
publicamente verificável. No entanto, alguns dados são sensíveis por razões comerciais ou de
privacidade. Este guia cobre os controles de privacidade disponíveis nos níveis de documento e
metadados de eventos.
As flags de visibilidade são definidas ao criar um documento (veja [API de Documents](/docs/integrations/api/documents)) e podem
ser ajustadas por meio de eventos `UPDATE` (veja
[Especificação de Eventos](/docs/integrations/reference/event-specification)).
## Controles de visibilidade [#controles-de-visibilidade]
* `isPublic`: controla se os dados são visíveis em superfícies públicas como o [Carrot Registry](/docs/protocol/registry).
* `isPubliclySearchable`: controla se os registros podem ser encontrados por meio de busca pública.
O flag `isPublic` aparece em quatro níveis no caminho de escrita, e é obrigatório em cada um deles:
* **Nível do documento** — `isPublic` na criação do documento, controlando o próprio documento.
* **Nível do evento** — `isPublic` em cada evento, controlando a visibilidade do evento inteiro.
* **Nível do anexo** — `isPublic` em cada entrada do array `attachments` do evento, que é o que
governa as linhas de anexo na tabela abaixo.
* **Nível do atributo de metadados** — `isPublic` em cada entrada de `metadata.attributes`, que
sobrepõe a visibilidade do evento para aquele atributo.
Níveis mais baixos podem sobrepor níveis mais altos — por exemplo, um atributo pode ser
marcado como privado dentro de um evento público. A precedência é aplicada pela plataforma
Carrot.
Os objetos `target` e `updates` carregam o próprio `isPublic` para o documento que criam ou
modificam. O `relatedDocument.isPublic` é diferente: ele controla se o evento espelhado gravado no
documento relacionado é público, não a visibilidade daquele documento. É obrigatório quando
`bidirectional` é `true`.
Quando um documento ou evento é marcado como público (`isPublic: true`), qualquer pessoa com o ID do
documento pode visualizá-lo no Carrot Registry (registry.carrot.eco). Quando privado (`isPublic: false`),
os dados ficam ocultos da visualização pública, mas permanecem acessíveis a auditores para verificação
de conformidade.
## Identidade do participante [#identidade-do-participante]
As flags de visibilidade governam o evento e seus metadados. A identidade do participante por trás do
evento é governada separadamente por `preserveSensitiveData`, um campo `true`/`false` aceito em todo evento.
Quando o participante é uma empresa, definir `preserveSensitiveData: true` no evento força a
identidade dele a privada — `name`, `taxId`, `taxIdType` e as coordenadas do endereço são
suprimidos — enquanto o evento em si permanece publicamente visível.
**Omitir o campo não é o mesmo que enviar `false`.** A superfície pública de MassID da Carrot publica
o nome de um participante apenas quando o evento `ACTOR` carrega `isPublic: true` **e**
`preserveSensitiveData: false` explicitamente. A verificação é `!== false`, então um campo ausente
equivale a `true` e o nome é retido sem gerar erro. Envie a flag explicitamente em todo evento
`ACTOR`, qualquer que seja a decisão.
Mesmo com as duas flags definidas, alguns papéis nunca são nomeados nessa superfície — Waste
Generator, Hauler e Bin Custodian são retidos independentemente disso — então defini-las não garante
a publicação.
`preserveSensitiveData` não é o mesmo que `isPublic: false`, que remove o evento inteiro da linha do
tempo pública e, portanto, da rastreabilidade pública. Use `preserveSensitiveData` quando a etapa
operacional precisa continuar visível mas o participante por trás dela não.
O campo também é aceito em `relatedDocument`, onde é rejeitado quando `bidirectional` é `false` — assim como `eventName` e `eventLabel`, já que não há evento espelhado a descrever.
## Política de visibilidade por papel [#política-de-visibilidade-por-papel]
Os seguintes padrões se aplicam a todas as metodologias:
* Dados do processador e do reciclador **devem ser públicos**.
* Dados do gerador e do transportador — informações da empresa, endereços, PII, placas de veículos — **devem ser privados**.
* Campos de texto livre **nunca devem conter dados sensíveis**, independentemente da visibilidade do evento.
Para recomendações específicas por metodologia, siga os flags `isPublic` nos exemplos canônicos:
* [BOLD Recycling — Referência de Eventos do MassID](/docs/methodologies/bold-recycling/framework/application/event-reference)
* [BOLD Carbon — Referência de Eventos do MassID](/docs/methodologies/ams-iii-f/bold-carbon/application/event-reference)
## Tratamento de dados sensíveis [#tratamento-de-dados-sensíveis]
Para atributos de metadados que contêm dados sensíveis ou pessoais (ex.: placas de veículos,
identificadores de motoristas), você tem duas opções:
* **Privacidade total** — Defina `isPublic: false` para ocultar os dados completamente das superfícies públicas.
* **Mascaramento parcial** — Envie o **valor completo**, defina `isPublic: true` e defina
`sensitive: true` nos metadados. A plataforma aplica mascaramento nas superfícies públicas — uma
placa enviada como `ABC-1234` aparece como `AB****34` — enquanto preserva o valor completo para
auditores.
O mascaramento sempre cobre um único trecho contíguo no meio do valor: no mínimo 4 caracteres e no
mínimo metade do valor, deixando no máximo 8 caracteres visíveis, divididos entre o início e o fim.
Apenas valores string são mascarados. Um atributo não-string marcado como `sensitive` é tratado como
privado, e seu valor é omitido inteiramente das superfícies públicas.
Não pré-mascare ou redija valores no seu payload. Envie os dados completos e deixe a plataforma
realizar o mascaramento.
O `sensitive` é um sinal que você envia, não o mecanismo que mantém um valor fora das superfícies
públicas da própria Carrot. A API pública de MassID e o documento de metadados do registry publicam
um conjunto fixo de atributos mantido no código da Carrot, então um atributo que você acrescenta não
é publicado lá, com ou sem a flag. Defina a flag corretamente mesmo assim — é ela que governa o
mascaramento na página pública do documento — mas não a trate como a garantia.
Veja [Formatos de Dados](/docs/integrations/reference/data-formats#dados-sensíveis) para o atributo
`sensitive` e as convenções de formato de mascaramento.
## Padrões comuns de dados privados [#padrões-comuns-de-dados-privados]
A tabela a seguir lista campos de dados que parceiros comumente configuram como privados, junto com
a justificativa para cada um:
| Dado | Categoria | Justificativa |
| ------------------------------------- | --------------------- | --------------------------------------------------------------------------------------------------- |
| Nome do Gerador de Resíduos | Dados de participante | Confidencialidade comercial — use `preserveSensitiveData: true` quando o evento precisa ser público |
| Manifesto de transporte (MTR) | Anexo | Defina `isPublic: false` na entrada do anexo; o evento em si permanece publicamente visível |
| Certificado de destinação final (CDF) | Anexo | Defina `isPublic: false` na entrada do anexo; o evento em si permanece publicamente visível |
| Placa do veículo | Metadados de evento | Dados pessoais — use `sensitive: true` com `isPublic: true` para mascaramento parcial |
| Identificador do motorista | Metadados de evento | Dados pessoais — use `sensitive: true` com `isPublic: true` para mascaramento parcial |
Se você não tem certeza se um campo deve ser privado ou usar mascaramento parcial, consulte o time
Carrot para orientação específica ao seu caso de uso.
## Estratégia prática de mascaramento [#estratégia-prática-de-mascaramento]
1. Mantenha valores sensíveis privados por padrão.
2. Exponha apenas os campos mínimos exigidos pelo seu negócio e fluxos públicos.
3. Use `sensitive: true` para campos que precisam ser publicamente visíveis de forma mascarada.
4. Audite payloads públicos regularmente para garantir que não haja exposição não intencional de dados.
Referências relacionadas:
* [Conceitos Fundamentais — Visibilidade e privacidade](/docs/integrations/getting-started/core-concepts#visibilidade-e-privacidade)
* [API de Events](/docs/integrations/api/events)
* [Formatos de Dados](/docs/integrations/reference/data-formats)
# Enviando um MassID
Use esta sequência como padrão base de implementação para enviar o ciclo de vida completo de um
[MassID](/docs/protocol/mass-ids) através da [Carrot API](/docs/integrations/api).
## Pré-requisitos [#pré-requisitos]
Antes de começar, certifique-se de ter:
* Uma conta de [Integrador](/docs/protocol/network-integrators) registrada com credenciais de API válidas
* Dados de participante e endereço prontos — resolva cada um primeiro (recupere por chave ou crie) para poder
referenciá-lo por `participantId` e `addressId`, como mostrado na Etapa 1
* Familiaridade com os [conceitos fundamentais](/docs/integrations/getting-started/core-concepts) — especialmente o modelo imutável baseado em eventos
Envie os dados das massas conforme a operação acontece. O último ciclo que pode analisar uma massa
é o do ano seguinte ao evento Recycled dela, e os dados precisam chegar à rede até **30 de
novembro** desse ano — uma massa reciclada em 2025 tem até 30 de novembro de 2026. A regra do
[framework de metodologia](/docs/standard/concepts/mvf) por trás desse limite, o horário do corte
e o que acontece depois dele estão descritos em [Janela de
envio](/docs/protocol/mass-ids#janela-de-envio).
## Etapa 1: Resolver participantes e endereços [#etapa-1-resolver-participantes-e-endereços]
Todo documento e todo evento precisa de um participante **e** de um endereço. Referencie-os **por ID** — a forma usada neste guia — ou envie os objetos inline, o que faz find-or-create deles. Antes de enviar, resolva cada
um — busque por chave ou crie — e guarde o `participantId` e o `addressId` retornados.
**Recuperar por chave.** Busque um participante existente pela chave natural — código do país, tipo de documento e número do documento:
```http
GET /participants?countryCode=BR&taxIdType=CNPJ&taxId=11111111111111
```
Se existir, reutilize o `participantId` retornado e liste seus endereços para encontrar o `addressId`:
```http
GET /participants/{participantId}/addresses
```
**Criar quando não existir.** Se o participante ainda não existir, crie-o e depois adicione um endereço a ele:
```json
POST /participants
{
"countryCode": "BR",
"name": "Empresa Exemplo",
"taxId": "11111111111111",
"taxIdType": "CNPJ",
"type": "COMPANY"
}
```
```json
POST /participants/{participantId}/addresses
{
"name": "Unidade Principal",
"street": "Rua das Colinas",
"number": "500",
"neighborhood": "Centro",
"city": "São Paulo",
"countryState": "São Paulo",
"countryCode": "BR",
"zipCode": "08575720",
"latitude": -23.5489,
"longitude": -46.6388
}
```
Cada chamada de criação retorna o `id` gerado — use-o como `participantId` / `addressId` nas próximas etapas.
Campos obrigatórios: participante — `countryCode`, `name`, `taxId`, `taxIdType`, `type`; endereço — `city`,
`countryCode`, `countryState`, `name`, `number`, `street`. Consulte a
[API de Participantes](/docs/integrations/api/participants) para o schema completo de requisição e resposta.
Criar um participante ou endereço que já existe só é seguro se você enviar dados **idênticos** — a
plataforma casa pela chave natural e rejeita valores conflitantes. Prefira recuperar por chave e
reutilizar o ID retornado.
## Etapa 2: Criar o documento [#etapa-2-criar-o-documento]
Crie o registro raiz com classificação e campos de visibilidade base, referenciando o participante e o
endereço que você resolveu na Etapa 1:
```json
POST /documents
{
"category": "MassID",
"type": "SEU_TIPO_DE_RESÍDUO",
"measurementUnit": "kg",
"externalCreatedAt": "2026-03-01T10:00:00.000Z",
"isPublic": true,
"isPubliclySearchable": true,
"participantId": "id-do-participante-da-etapa-1",
"addressId": "id-do-endereço-da-etapa-1",
"externalId": "seu-id-interno-de-rastreamento",
"deduplicationId": "id-único-gerado-antes-da-primeira-tentativa"
}
```
| Campo | Obrigatório | Descrição |
| ---------------------- | ----------- | -------------------------------------------------------------------------------------------------- |
| `category` | Sim | Sempre `MassID` para documentos de rastreamento de massa |
| `type` | Sim | Tipo de resíduo — definido por metodologia (veja a nota abaixo) |
| `measurementUnit` | Não | Padrão `kg` quando omitido — envie explicitamente. `kg` é o valor exigido pelas duas metodologias |
| `externalCreatedAt` | Sim | Timestamp ISO 8601 da criação real do documento |
| `isPublic` | Sim | Se o documento é publicamente visível |
| `isPubliclySearchable` | Sim | Se o documento aparece em buscas públicas |
| `participantId` | Um dos dois | ID do participante resolvido na Etapa 1 — envie este **ou** um `participant` inline, nunca os dois |
| `addressId` | Um dos dois | ID do endereço resolvido na Etapa 1 — envie este **ou** um `address` inline, nunca os dois |
| `externalId` | Não | Seu ID interno para reconciliação — útil para mapear de volta ao seu sistema |
| `deduplicationId` | Não | Chave de idempotência — veja a dica abaixo |
Você pode enviar objetos completos `participant` e `address` inline em vez de
`participantId`/`addressId`; a plataforma faz find-or-create deles. Envie **exatamente um** de
cada par — os dois, ou nenhum, falha na validação com `400 VALIDATION_ERROR`. Prefira resolver na
Etapa 1 e referenciar por ID; a forma inline é a única maneira de criar um documento junto com um
novo participante ou endereço em uma única chamada.
O campo `type` (tipo de resíduo) e `measurementUnit` são definidos pela sua metodologia alvo.
Consulte os [guias de integração por metodologia](/docs/integrations/guides/methodology-guides)
para os valores específicos necessários. Um MassID é medido em `kg` tanto na BOLD Recycling quanto
na BOLD Carbon — o conjunto de regras rejeita qualquer outro valor. `kg CO₂e` é a unidade das
reduções de emissões que a metodologia calcula a partir dessa massa, não a unidade do MassID.
Referência: [API de Documentos](/docs/integrations/api/documents).
## Etapa 3: Adicionar eventos à linha do tempo [#etapa-3-adicionar-eventos-à-linha-do-tempo]
Adicione eventos em ordem cronológica para representar as etapas operacionais. Cada evento é
imutável após criado.
### Eventos ACTOR [#eventos-actor]
Eventos ACTOR registram papéis de participantes na linha do tempo do documento. Cada um requer um `label` identificando o papel, além do participante e endereço a que se aplica, referenciados por ID:
```json
POST /documents/{documentId}/events
{
"name": "ACTOR",
"label": "SEU_LABEL_DE_PAPEL",
"externalCreatedAt": "2026-03-01T10:05:00.000Z",
"isPublic": true,
"participantId": "id-do-participante-ator",
"addressId": "id-do-endereço-ator"
}
```
O valor de `label` (ex. `"Waste Generator"`, `"Hauler"`, `"Processor"`) é definido por cada metodologia. Consulte o guia da sua metodologia para os papéis obrigatórios e seus labels.
Resolva o participante e o endereço de cada ator da mesma forma que na Etapa 1, e então referencie-os por `participantId` e `addressId`.
### Eventos CUSTOM [#eventos-custom]
Eventos CUSTOM representam etapas operacionais específicas da metodologia. O nome do evento, atributos de metadados obrigatórios e a sequência são todos definidos pela metodologia:
```json
POST /documents/{documentId}/events
{
"name": "NOME_DO_SEU_EVENTO",
"externalCreatedAt": "2026-03-01T11:00:00.000Z",
"isPublic": true,
"participantId": "id-do-participante-da-etapa-1",
"addressId": "id-do-endereço-da-etapa-1",
"metadata": {
"attributes": [
{ "name": "NOME_DO_SEU_ATRIBUTO", "value": "valor-do-atributo", "isPublic": true }
]
},
"value": 150.5
}
```
O campo `value` nos eventos contribui para o `currentValue` do documento. Por exemplo, um evento de pesagem com `value: 150.5` define o peso rastreado.
Eventos aceitam os mesmos objetos `participant` e `address` inline que os documentos, com o mesmo
comportamento de find-or-create. Prefira referenciar `participantId` e `addressId`.
Cada metodologia define a sequência específica de eventos, nomes de eventos e atributos de
metadados obrigatórios. Consulte os [guias de integração por
metodologia](/docs/integrations/guides/methodology-guides) para os valores necessários por cada
metodologia.
### Ciclo de vida do status do documento [#ciclo-de-vida-do-status-do-documento]
Documentos seguem um ciclo de vida de status estrito:
* **`OPEN`** — Status padrão após a criação. Eventos podem ser adicionados livremente.
* **Evento `CLOSE`** — Transiciona o documento para `CLOSED`. Após o fechamento, apenas eventos `RELATED` e `CANCEL` são aceitos — `CANCEL` sobrevive ao `CLOSE` justamente para manter o [padrão de CANCEL e recriação](/docs/integrations/guides/error-handling#cancel-e-recriação) disponível em um documento fechado.
* **Evento `CANCEL`** — Transiciona o documento para `CANCELLED`. Nenhum evento adicional é aceito.
Envie um evento `CLOSE` quando o ciclo de vida da [cadeia de suprimentos](/docs/protocol/supply-chain) estiver completo:
```json
POST /documents/{documentId}/events
{
"name": "CLOSE",
"externalCreatedAt": "2026-03-02T16:00:00.000Z",
"isPublic": true,
"participantId": "id-do-participante-integrador",
"addressId": "id-do-endereço-integrador"
}
```
Consulte a [Especificação de Eventos](/docs/integrations/reference/event-specification) para a lista completa de categorias de eventos.
Referência: [API de Eventos](/docs/integrations/api/events).
Para integrações de alto volume, considere o [endpoint de eventos em lote](/docs/integrations/api/events#eventos-em-lote) para enviar múltiplos eventos por requisição.
## Etapa 4: Anexar arquivos de evidência (opcional) [#etapa-4-anexar-arquivos-de-evidência-opcional]
Algumas regras de metodologia exigem anexos de evidência (ex. tickets de balança, manifestos de transporte).
O padrão é:
1. **Solicitar uma URL de upload pré-assinada** via a API de Anexos
2. **Fazer upload do arquivo** diretamente para a URL pré-assinada
3. **Referenciar o anexo** no array `attachments` do evento relevante
Anexos são vinculados a eventos específicos, não ao documento como um todo. Isso garante que cada evidência esteja vinculada à etapa operacional que ela documenta.
Referência: [API de Anexos](/docs/integrations/api/attachments).
## Etapa 5: Recuperar e validar o estado final [#etapa-5-recuperar-e-validar-o-estado-final]
Consulte o documento e verifique antes de considerar o envio completo:
* **Contagem e ordenação de eventos** — todos os eventos esperados estão presentes em ordem cronológica
* **Status é `CLOSED`** — o documento foi devidamente fechado
* **`currentValue` > 0** — o documento tem um valor rastreado positivo
* **Pelo menos um evento `ACTOR`** — os papéis de participante obrigatórios estão registrados
* **Links de participante e endereço** — todas as referências resolvem corretamente
* **Completude dos metadados** — atributos obrigatórios estão presentes em cada evento conforme a metodologia
Referência: [GET documento por ID](/docs/integrations/api/documents).
## Dicas operacionais [#dicas-operacionais]
Sempre envie `deduplicationId` em chamadas de escrita com retentativa (criação de documento e
criação de evento). Gere um ID único **antes** da primeira tentativa, armazene-o e **reutilize o
mesmo ID** em cada retentativa. O ID tem escopo por integrador — dois integradores diferentes
podem usar o mesmo ID sem conflito. Um ID repetido é **rejeitado** com `409 CONFLICT_ERROR`, nunca
reexecutado: trate esse conflito como confirmação de que a primeira tentativa teve sucesso e
nenhuma duplicata foi criada. A resposta não retorna o id original do documento, e nenhum endpoint
busca documento por `externalId` ou `deduplicationId` — então registre o id da primeira resposta
bem-sucedida, e trate uma resposta perdida de `POST /documents` como um pedido de suporte.
* Use `externalId` em documentos e eventos para reconciliação com seus sistemas internos.
* Trate `4xx` como problemas de dados/integração e `5xx` como falhas transitórias — veja [Tratamento de Erros](/docs/integrations/guides/error-handling).
* Planeje backfills para caírem antes do corte de 30 de novembro — veja [Janela de envio](/docs/protocol/mass-ids#janela-de-envio).
* Mantenha sua estratégia de timestamps determinística — veja [Formatos de Dados](/docs/integrations/reference/data-formats).
# Formatos de Dados
Use estas convenções para reduzir erros de validação e manter a interoperabilidade dos dados.
## Nomes de atributos de metadados [#nomes-de-atributos-de-metadados]
Use **Title Case** para nomes de atributos de metadados (ex: `Vehicle License Plate`, `Gross Weight`, `Issue Date`). Não use kebab-case ou nomes concatenados em minúsculas nos metadados de eventos. A única exceção é o `reason` de um evento `CANCEL`, que a plataforma compara em minúsculas.
## Data e hora [#data-e-hora]
* Use timestamps UTC no formato ISO 8601 (`YYYY-MM-DDTHH:mm:ss.sssZ`) para campos de data e hora.
* Para campos apenas de data, use o formato de data ISO 8601 e, quando exigido pela API, inclua um atributo `format` (ex: `DATE`).
* Preserve a cronologia da origem nas submissões de eventos.
## Identificadores [#identificadores]
* Mantenha os IDs estáveis e determinísticos entre retentativas.
* Use `deduplicationId` como chave de idempotência de criação única em escritas passíveis de
retentativa; uma repetição é rejeitada, não reexecutada — veja
[Tratamento de Erros](/docs/integrations/guides/error-handling).
* `externalId` é armazenado para a sua própria correlação e **não** é usado para deduplicação.
## Convenções de nomenclatura [#convenções-de-nomenclatura]
* Use nomes de atributos consistentes e evite duplicatas sinônimas.
* Prefira metadados estruturados em vez de strings de texto livre.
## Valores numéricos e unidades [#valores-numéricos-e-unidades]
* Envie campos numéricos como números, não como strings localizadas.
* Quando a API exigir uma unidade ou escala, use o atributo `format` com o valor apropriado (ex: `KILOGRAM`, `LITER`, `CUBIC_METER` para massa/volume).
* Mantenha a escolha de unidade consistente durante o ciclo de vida do documento.
## Dados sensíveis [#dados-sensíveis]
Para atributos que contêm dados sensíveis ou pessoais (ex: placas de veículos, identificadores de motoristas):
* Envie o **valor completo** no payload — não mascare ou redija previamente.
* Defina `sensitive: true` nos metadados. Ele governa o mascaramento na página pública do documento;
é um sinal que você envia, não o mecanismo que mantém um atributo fora das superfícies públicas de
MassID da própria Carrot, que publicam um conjunto fixo de atributos mantido no código da Carrot.
* Consulte [Privacidade e Mascaramento](/docs/integrations/guides/privacy-and-masking) para controles de visibilidade.
## Identidade do participante em eventos ACTOR [#identidade-do-participante-em-eventos-actor]
A superfície pública de MassID da Carrot nomeia participantes apenas a partir de eventos `ACTOR` — um
participante ligado a um evento `CUSTOM` ou outro nunca é nomeado ali, independentemente das flags.
Em um evento `ACTOR`, publicar o nome exige duas flags independentes:
* `isPublic: true` no evento. Esse campo é obrigatório, então omiti-lo falha na validação em vez de
mudar o que é publicado.
* `preserveSensitiveData: false` — definido **explicitamente**. Esse é opcional, e aí está a
armadilha: a verificação é `!== false`, então deixá-lo de fora equivale a `true` e a identidade é
retida sem gerar erro.
Mesmo com as duas flags definidas, alguns papéis nunca são nomeados na superfície pública de MassID
da Carrot — Waste Generator, Hauler e Bin Custodian são retidos independentemente disso. Não presuma
que definir as duas flags publica o nome de qualquer participante.
Referências relacionadas:
* [Conceitos Fundamentais](/docs/integrations/getting-started/core-concepts)
* [Tratamento de Erros](/docs/integrations/guides/error-handling)
* [Especificação de Eventos](/docs/integrations/reference/event-specification)
* [Privacidade e Mascaramento](/docs/integrations/guides/privacy-and-masking)
# Especificação de Eventos
Esta página é a referência canônica para a modelagem de eventos no nível macro/base.
## Categorias lógicas de eventos integradas [#categorias-lógicas-de-eventos-integradas]
| Tipo | Propósito |
| --------- | -------------------------------------------------------------------------------------- |
| `ACTOR` | Concede ou atualiza papéis/permissões de participantes na linha do tempo do documento. |
| `CLOSE` | Encerra o documento para atualizações futuras (exceto fluxos de relação específicos). |
| `CANCEL` | Cancela o documento e bloqueia ações futuras. Exige um `reason`. |
| `RELATED` | Cria vínculos de relação entre documentos. |
| `UPDATE` | Atualiza campos selecionados relacionados à visibilidade do documento. |
| `OUTPUT` | Nome convencional para um evento que cria um documento downstream. |
| `CUSTOM` | Nomes de eventos específicos da metodologia/aplicação. |
Um documento downstream é criado pela presença do objeto `target` em **qualquer** evento, não pelo
nome do evento — `OUTPUT` é o nome convencional para esse padrão, e é tratado como evento `CUSTOM`.
Um evento `CANCEL` precisa carregar uma entrada `metadata.attributes` chamada `reason` com valor não
vazio; omiti-la retorna `400` com `The reason metadata is required for CANCEL events`.
Para padrões de implementação usando categorias de eventos específicas, consulte:
* `ACTOR`: [Guia de Permissões](/docs/integrations/guides/permissions)
* `CANCEL` / `CLOSE`: [Guia de Tratamento de Erros](/docs/integrations/guides/error-handling)
* `RELATED` / `OUTPUT`: [Submetendo um MassID](/docs/integrations/guides/submitting-a-mass-id)
* `UPDATE`: [Guia de Privacidade e Mascaramento](/docs/integrations/guides/privacy-and-masking)
* `CUSTOM`: Definidos por [metodologia](/docs/methodologies) — consulte os [guias de integração por metodologia](/docs/integrations/guides/methodology-guides) para os eventos e regras de validação específicos.
## Campos comuns de eventos [#campos-comuns-de-eventos]
A maioria dos payloads de eventos compartilha estes campos principais:
* `name`
* `externalCreatedAt`
* `isPublic`
* `metadata`
* `participantId` (ou um objeto `participant` inline, que faz find-or-create do registro)
* `addressId` (ou um objeto `address` inline, que faz find-or-create do registro)
Todo evento precisa carregar exatamente um entre `participantId`/`participant` e exatamente um entre
`addressId`/`address`. Enviar as duas formas, ou nenhuma, falha com `400 VALIDATION_ERROR`
(`You must pass participantId or participant field, not both, not neither`). A regra é idêntica nos
endpoints de evento individual e de lote.
* `attachments` (opcional)
* `deduplicationId` (opcional)
Dê a todo evento `ACTOR` um **label** — o label *é* o papel do participante. O schema não impõe isso, então é uma exigência da plataforma, não da validação da requisição. Cada [guia de integração por metodologia](/docs/integrations/guides/methodology-guides) define os labels permitidos e a ordem obrigatória. Não utilize campos de papel descontinuados como `actor-type`.
Um label ausente ou não reconhecido não gera erro. O evento é aceito, mas o participante não recebe
nenhuma parcela de recompensa e seu nome é retido do registro público — uma falha que você só percebe
mais adiante. Os labels de documentos MassID são `Bin Custodian`, `Hauler`, `Integrator`, `Processor`,
`Recycler` e `Waste Generator` (`Integrator` normaliza para o papel `Network Integrator`).
## Eventos CUSTOM [#eventos-custom]
Eventos `CUSTOM` aceitam qualquer `name` — [Integradores](/docs/protocol/network-integrators) podem definir e enviar quaisquer eventos operacionais adequados ao seu fluxo de trabalho. A plataforma não restringe nomes de eventos CUSTOM no nível da API.
Metodologias definem seus próprios vocabulários de eventos CUSTOM esperados e os validam por meio de [regras de aplicação](/docs/standard/concepts/mva#regras-do-framework-vs-regras-da-aplicação). Consulte o [guia de integração por metodologia](/docs/integrations/guides/methodology-guides) relevante para os eventos específicos e regras de validação aplicáveis.
## Restrições de ordenação e propagação [#restrições-de-ordenação-e-propagação]
* Os timestamps dos eventos devem permanecer cronologicamente consistentes.
* O comportamento de propagação é restrito e deve ser explicitamente validado em testes de integração.
* Utilize padrões de retentativas determinísticos para evitar entradas duplicadas na linha do tempo.
Referência de endpoint: [API de Eventos](/docs/integrations/api/events).
# Limites de Taxa
A Carrot API aplica os seguintes limites por cliente de API.
## Limites [#limites]
| Limite | Valor |
| ------------------------------------ | -------------- |
| Requisições por segundo (sustentado) | 20 |
| Burst permitido | 30 requisições |
| Eventos por documento | 100 |
| Tamanho máximo de upload | 10 MB |
O throttling é aplicado por cliente de API e é idêntico em teste e produção — o ambiente é
selecionado pela sua credencial, não por uma faixa de throttling separada. Dimensione o token bucket
do seu cliente pelo burst permitido, não apenas pela taxa sustentada.
## Tratamento de throttling [#tratamento-de-throttling]
* Exceder a taxa de requisições retorna uma resposta `429` com `{"message": "Too Many Requests"}`.
* Aplique rate limiting no lado do cliente com token bucket ou leaky bucket.
* Suavize rajadas; não dependa apenas de médias por minuto.
Referências relacionadas:
* [Erros da API](/docs/integrations/api/errors)
* [Guia de Tratamento de Erros](/docs/integrations/guides/error-handling)
# Classificação de Resíduos
Todo documento enviado à [Carrot API](/docs/integrations/api) é classificado usando uma hierarquia de três
níveis: **Categoria**, **Tipo** e **Subtipo**. Os dois primeiros níveis são obrigatórios; o terceiro é
opcional na API, embora uma metodologia possa exigi-lo. Essa estrutura organiza os documentos para
agrupamento, rastreabilidade e validação de metodologia.
## Hierarquia de classificação [#hierarquia-de-classificação]
Um subtipo sempre pertence a um tipo, e um tipo sempre pertence a uma categoria. Isso garante que
cada documento esteja posicionado corretamente dentro do contexto de classificação da plataforma.
### Categoria [#categoria]
O nível mais amplo de classificação. Indica o contexto geral do documento. Para integrações de cadeia
de suprimentos, a categoria é tipicamente [`MassID`](/docs/protocol/mass-ids), que se refere a
documentos que rastreiam o histórico de uma massa de resíduos.
Outras categorias (como `Methodology`) existem para fluxos internos da plataforma e não são usadas em
integrações padrão.
### Tipo [#tipo]
O tipo identifica a classe primária de material ou processo dentro de uma categoria. Sob a categoria
`MassID`, o tipo é um entre:
* `Glass`
* `Metal`
* `Organic`
* `Paper`
* `Plastic`
Esse é o vocabulário que a plataforma reconhece adiante — a emissão de certificados e a API pública
de MassID analisam `type` contra exatamente esses cinco valores e descartam registros fora deles. O
`POST /documents` em si aceita `type` como string livre, então um valor fora dessa lista é aceito no
envio e descartado depois.
### Subtipo [#subtipo]
O subtipo fornece a classificação mais específica, refinando o tipo com informações detalhadas sobre o
material. Por exemplo:
* Para o tipo `Plastic`: `PET` — o único subtipo de plástico aceito
* Para o tipo `Organic`: `Domestic Sludge`, `EFB similar to Garden, Yard and Park Waste`,
`Food, Food Waste and Beverages`, `Garden, Yard and Park Waste`, `Industrial Sludge`,
`Others (if organic)`, `Tobacco`, `Wood and Wood Products`
Os subtipos devem ser enviados em inglês. Os subtipos aceitos dependem da
[metodologia](/docs/methodologies) sob a qual a massa será auditada — consulte o guia de integração
específico da metodologia para a lista completa.
## Subtipos específicos por metodologia [#subtipos-específicos-por-metodologia]
Cada metodologia define os subtipos aceitos para validação. Uma massa submetida a uma metodologia deve
usar um de seus subtipos aceitos para passar nas regras de validação.
* [BOLD Recycling — Guia de Integração](/docs/methodologies/bold-recycling/framework/application/integration)
* [BOLD Carbon (CH₄) — Guia de Integração](/docs/methodologies/ams-iii-f/bold-carbon/application/integration)
## Expectativas de validação [#expectativas-de-validação]
* `category` e `type` são obrigatórios em todo documento. `subtype` é opcional na API, mas uma metodologia pode exigi-lo — um MassID sem subtipo não passa na verificação de uma metodologia que define subtipos aceitos, então nenhum certificado é emitido a partir dele.
* As combinações de categoria/tipo devem seguir a taxonomia de negócio aprovada.
* Mantenha os mapeamentos determinísticos entre ambientes (teste e produção).
* Valide combinações não suportadas antes do envio à API para evitar rejeição.
## Sistemas de códigos externos [#sistemas-de-códigos-externos]
Algumas metodologias exigem códigos externos de classificação de resíduos junto ao subtipo Carrot.
Esses códigos conectam a classificação Carrot a padrões nacionais ou internacionais.
### Códigos Ibama (Brasil) [#códigos-ibama-brasil]
O [Ibama](/docs/glossary#ibama) (Instituto Brasileiro do Meio Ambiente e dos Recursos Naturais
Renováveis) publica a
[Lista Brasileira de Resíduos Sólidos](https://www.gov.br/ibama/pt-br/assuntos/emissoes-e-residuos/residuos/arquivos/ibama-lista-brasileira-de-residuos-solidos.doc)
(conforme IN nº 13/2012). Cada material de resíduo recebe um código de 6 dígitos (por exemplo,
`02 01 01`). Inclua o código e a descrição do Ibama nos atributos de metadados
`Local Waste Classification ID` e `Local Waste Classification Description`.
### Categorias de resíduos CDM [#categorias-de-resíduos-cdm]
O [CDM](/docs/glossary#cdm) (Clean Development Mechanism) Tool 04 v08.1 define categorias de
resíduos usadas para atribuição de fatores de emissão. Cada código Ibama mapeia para uma categoria CDM
(por exemplo, `8.3` para resíduos alimentares). A metodologia usa esse mapeamento para selecionar os
fatores de emissão corretos.
### Listas de códigos específicas por metodologia [#listas-de-códigos-específicas-por-metodologia]
O BOLD Carbon exige tanto códigos Ibama quanto CDM, validados pela regra
`regional-waste-classification`. Consulte os
[Códigos de resíduos aceitos — BOLD Carbon Framework](/docs/methodologies/ams-iii-f/bold-carbon#códigos-de-resíduos-suportados)
para a lista completa de códigos Ibama aceitos e seus mapeamentos CDM.
Referências relacionadas:
* [Conceitos Fundamentais](/docs/integrations/getting-started/core-concepts)
* [API de Documentos](/docs/integrations/api/documents)
* [Formatos de Dados](/docs/integrations/reference/data-formats)
# Visão Geral AMS-III.F
## Visão geral [#visão-geral]
**AMS-III.F** é uma metodologia do [Mecanismo de Desenvolvimento Limpo (MDL) da UNFCCC](https://unfccc.int/process-and-meetings/the-kyoto-protocol/mechanisms-under-the-kyoto-protocol/the-clean-development-mechanism) cujo título oficial é "Avoidance of methane emissions through composting" (v12.0). Ela fornece a base científica e regulatória para quantificar as reduções de emissões de gases de efeito estufa alcançadas ao desviar resíduos orgânicos de aterros sanitários para instalações de compostagem aeróbica.
A metodologia quantifica as reduções de emissões de CO₂-equivalente alcançadas ao compostar resíduos em vez de enviá-los a um aterro sanitário, onde se decomporiam anaerobicamente e gerariam metano (CH₄).
* **Referência oficial**: [AMS-III.F na UNFCCC CDM](https://cdm.unfccc.int/methodologies/DB/NZ83KB7YHBIA7HL2U1PCNAOCHPUQYX)
* **Versão**: 12.0
* **Tipo de crédito**: Crédito de Carbono — Tokenized Carbon Credits ([TCC](/docs/protocol/credits#tokenized-carbon-credits-tcc))
* **Token on-chain**: `C-CARB.CH4` (reduções de metano)
## Implementação digital da AMS-III.F [#implementação-digital-da-ams-iiif]
A AMS-III.F é importante porque resíduos orgânicos em aterros sanitários são uma das maiores fontes de metano antropogênico, representando aproximadamente 11% das emissões globais de CH₄. A compostagem é uma solução comprovada e escalável — mas historicamente, medir e verificar as reduções de emissões resultantes tem sido caro e manual, limitando a participação a projetos de grande escala.
A Carrot implementa a AMS-III.F através do framework [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) (MvF), que traduz a metodologia em lógica de verificação automatizada e transparente. Isso possibilita:
* **Participação de instalações de pequena escala** — O Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)) reduz os custos de verificação, tornando viável a emissão de créditos de carbono para instalações que nunca poderiam arcar com auditorias tradicionais.
* **Verificação contínua** — Em vez de auditorias periódicas, cada lote de resíduos compostados é verificado individualmente por meio do rastreamento de cadeia de custódia [MassID](/docs/protocol/mass-ids).
* **Regras de código aberto** — Toda lógica de verificação é publicamente auditável sob LGPL-3.0, para que qualquer pessoa possa inspecionar como os créditos são calculados.
* **Recompensas da cadeia de suprimentos** — Os recursos das compras de créditos são distribuídos a todos os participantes da cadeia de suprimentos, não apenas ao operador da instalação.
Cada crédito `C-CARB.CH4` representa 1 tonelada métrica de reduções de emissões de CO₂-equivalente. Compostar 1 tonelada de resíduos alimentares misturada a 1 tonelada de resíduos verdes previne mais de 2 toneladas de CO₂e em comparação com a disposição em aterro sanitário sem captura de metano.
## Base científica [#base-científica]
A AMS-III.F baseia-se em ciência ambiental consolidada do CDM da UNFCCC:
* **Emissões de linha de base**: Calculadas usando a [Ferramenta 04 do CDM da UNFCCC](https://cdm.unfccc.int/methodologies/PAmethodologies/tools/am-tool-04-v8.0.pdf) — emissões de locais de disposição de resíduos sólidos (aterros sanitários e lixões)
* **Emissões reais da compostagem**: Calculadas usando a [Ferramenta 13 do CDM da UNFCCC](https://cdm.unfccc.int/methodologies/PAmethodologies/tools/am-tool-13-v2.pdf) — emissões de projeto e de fuga da compostagem
* **Metodologia de origem**: [AMS-III.F da UNFCCC](https://cdm.unfccc.int/methodologies/DB/NZ83KB7YHBIA7HL2U1PCNAOCHPUQYX) v12.0 — "Avoidance of methane emissions through composting" (título oficial do CDM na íntegra; a Carrot usa vocabulário de tier-redução em sua própria prosa)
O cálculo central: **Reduções de Emissões = Emissões de Linha de Base - Emissões Reais**
## Escopo [#escopo]
* **Tipo de instalação**: Instalações profissionais de compostagem aeróbica de pequena escala, externas ao local de geração (SSC)
* **Tipos de resíduo**: Resíduos alimentares e resíduos verdes (podas de jardim)
* **Cenários de linha de base**: Aterro sanitário sem captura de metano, aterro sanitário com queima de metano, lixão
* **Verificação**: dMRV com rastreamento de cadeia de custódia [MassID](/docs/protocol/mass-ids)
* **Emissão de créditos**: [Certificados GasID](/docs/protocol/certificates#gasid) → tokens de crédito `C-CARB.CH4`
## Como funciona [#como-funciona]
1. Os resíduos orgânicos são verificados como compostados por meio do [BOLD Recycling](/docs/methodologies/bold-recycling), gerando certificados RecycledID.
2. A proporção de mistura da instalação de compostagem (resíduos alimentares para resíduos verdes) é verificada.
3. As emissões de linha de base são calculadas com base no cenário local de disposição de resíduos.
4. As emissões reais da compostagem são calculadas usando dados verificados da instalação.
5. A diferença (reduções de emissões) gera [certificados GasID](/docs/protocol/certificates#gasid).
6. Os certificados GasID são criados e os créditos `C-CARB.CH4` correspondentes são mintados.
7. Os recursos das compras de créditos são distribuídos conforme a [Política de Distribuição de Recompensas](/docs/standard/policies/rewards-distribution).
Use a [Calculadora de Créditos](/docs/standard/guides/credit-calculator) para estimar o potencial
de TCC a partir da compostagem de resíduos orgânicos.
## Framework da Carrot [#framework-da-carrot]
A AMS-III.F é implementada na Rede Carrot através do framework **[BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon)** (MvF). O BOLD Carbon traduz a metodologia do CDM em regras de verificação, fórmulas e requisitos de dados concretos que podem ser executados como dMRV automatizado.
## Recursos [#recursos]
* [Ver no Carrot Registry](https://registry.carrot.eco/document/9498dd79-97ca-4efb-b47d-a8b61cf1f995)
* [Framework de Metodologia BOLD Carbon (CH₄) (PDF)](https://drive.google.com/file/d/1TwEGKA_YAhgsb_1pFmbVxZxNN5uVEVY6/view)
* [AMS-III.F na UNFCCC CDM](https://cdm.unfccc.int/methodologies/DB/NZ83KB7YHBIA7HL2U1PCNAOCHPUQYX)
Feedback: [method@carrot.eco](mailto:method@carrot.eco)
[Conheça o BOLD Recycling](/docs/methodologies/bold-recycling) · [Ver o framework BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) · [Conheça a distribuição de recompensas](/docs/standard/policies/rewards-distribution)
# Visão Geral do BOLD Recycling Credit
## Visão geral [#visão-geral]
O **BOLD (Breakthrough in Organics Landfill Diversion) Recycling Credit** é uma metodologia de Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)) para verificar o desvio de resíduos orgânicos de aterros sanitários para instalações de compostagem aeróbia, contribuindo para reduções de metano ao impedir a decomposição anaeróbica em aterros. As regras da metodologia BOLD Recycling verificam que os resíduos orgânicos foram devidamente separados, coletados, transportados e compostados em uma instalação profissional. As [recompensas](/docs/protocol/rewards-distribution) para cada participante da cadeia de suprimentos são calculadas e comprometidas on-chain quando um crédito do [certificado](/docs/protocol/certificates) resultante é vendido, e pagas depois.
O BOLD Recycling gera [Tokenized Recycling Credits (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc), representados on-chain como tokens `C-BIOW`. Cada crédito representa 1 tonelada métrica de material orgânico compostado verificado. (Outras metodologias de reciclagem podem emitir TRCs com símbolos on-chain diferentes.)
## Por que resíduos orgânicos? [#por-que-resíduos-orgânicos]
Os resíduos orgânicos representam aproximadamente 50% dos resíduos globais e são 100% recicláveis, mas a maior parte acaba em aterros sanitários. Isso importa por duas razões interconectadas:
1. **Emissões de metano** — Resíduos orgânicos em decomposição anaeróbia em aterros sanitários geram aproximadamente 11% das emissões globais de metano. Desviar resíduos orgânicos para compostagem reduz drasticamente essas emissões.
2. **Contaminação da reciclagem** — Quando resíduos orgânicos são misturados com materiais recicláveis (metais, vidro, papel, plástico), eles contaminam esses fluxos e reduzem as taxas de recuperação. Remover resíduos orgânicos pode melhorar o desempenho das instalações de triagem em 2–5x.
A transição para uma economia circular começa com a separação dos resíduos orgânicos dos demais fluxos recicláveis — esse é o desafio que o BOLD Recycling aborda.
## Escopo [#escopo]
O BOLD Recycling cobre toda a cadeia de suprimentos, da geração de resíduos à compostagem:
* **Tipos de resíduos**: Resíduos alimentares, resíduos verdes (podas de jardim), lodo de estações de tratamento de resíduos, resíduos da indústria do tabaco
* **Tratamento**: Compostagem aeróbia em instalações profissionais
* **Verificação**: dMRV utilizando [MassIDs](/docs/protocol/mass-ids) para rastreabilidade da cadeia de custódia
* **Emissão de créditos**: [Certificados RecycledID](/docs/protocol/certificates#recycledid) → tokens de crédito `C-BIOW`
## Como funciona [#como-funciona]
1. Os resíduos orgânicos são separados na origem pelos [Geradores de Resíduos](/docs/protocol/supply-chain).
2. [MassIDs](/docs/protocol/mass-ids) rastreiam os resíduos durante a coleta, transporte e processamento.
3. Os resíduos chegam a uma instalação de compostagem credenciada, onde a reciclagem é verificada por meio de dMRV.
4. [Certificados](/docs/protocol/certificates) são emitidos e créditos são mintados.
5. Os recursos das compras de créditos são distribuídos conforme a [Política de Distribuição de Recompensas](/docs/standard/policies/rewards-distribution).
Use a [Calculadora de Créditos](/docs/standard/guides/credit-calculator) para estimar o potencial
de TRC a partir da compostagem de resíduos orgânicos.
## Recursos [#recursos]
* [Ver no Carrot Registry](https://registry.carrot.eco/document/31f1ff32-fdc5-469a-9d30-caf0be89b50a)
* [Metodologia BOLD Recycling (PDF)](https://drive.google.com/file/d/1Qdod8Qy3zT4lBkUp1TIyuxguHIYTevJJ/view)
Feedback: [method@carrot.eco](mailto:method@carrot.eco)
[Conheça o BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) · [Conheça a distribuição de recompensas](/docs/standard/policies/rewards-distribution) · [Ver catálogo de regras](/docs/methodologies/bold-recycling/framework/application/application-rules) · [Ver framework](/docs/methodologies/bold-recycling/framework) · [Ver aplicação](/docs/methodologies/bold-recycling/framework/application)
# Infraestrutura Pública Digital
{/* cspell:words Aadhaar X-Road UNDP */}
## Um mercado que precisa ser formado [#um-mercado-que-precisa-ser-formado]
Resolver os problemas mais difíceis do mundo — mudanças climáticas, gestão de recursos naturais, desenvolvimento humano — depende de economias que valorizem **bens públicos**, não apenas bens privados. A dificuldade é que os mercados exigidos por essa economia quase não existem: os resultados mais importantes — clima estável, ar e água limpos, materiais recuperados, comunidades saudáveis e produtivas — beneficiam todos, mas quase ninguém paga por eles. E formar esses mercados é um **problema de coordenação** que nem empresas nem governos, agindo sozinhos, conseguem resolver.
Formá-los exige três coisas ao mesmo tempo: um **sistema de financiamento** que direcione capital a resultados verificados, não a promessas; uma **camada de tecnologia** que torne esses resultados confiáveis — medidos, verificados de forma independente, registrados de forma única e liquidados com transparência; e uma **organização** vinculada a um propósito público que não possa abandonar silenciosamente, para zelar por essa camada. Infraestrutura pública digital é onde esses três elementos se encontram — e a Rede Carrot é a contribuição operacional da Carrot para isso.
## O que significa "infraestrutura pública digital" [#o-que-significa-infraestrutura-pública-digital]
Infraestrutura Pública Digital (DPI) é o termo usado pelo UCL Institute for Innovation and Public Purpose, pelo Programa das Nações Unidas para o Desenvolvimento, pelo Banco Mundial e pelo G20 para sistemas digitais que funcionam como trilhos compartilhados para a sociedade, e não como plataformas proprietárias: **fundacionais**, **interoperáveis**, **inclusivos** e **publicamente responsáveis**. Os casos de referência são camadas fundacionais de identidade, pagamentos e troca de dados — Aadhaar e UPI na Índia, Pix no Brasil, X-Road na Estônia. A Rede Carrot aplica o mesmo padrão a um domínio que esses casos ainda não alcançaram: **financiamento baseado em resultados para avanço ambiental e social**, começando por redução de resíduos, reciclagem e metano — e construída para se estender a outros domínios ambientais.
Seus componentes centrais são **bens públicos digitais** — as partes abertas que compõem os trilhos: [frameworks de metodologia](/docs/methodologies) abertos, um [registry público de créditos](/docs/registry) e [código de verificação open source](https://github.com/carrot-foundation/methodology-rules) que qualquer operador, verificador, autor de metodologia ou desenvolvedor de aplicação pode usar como base. Juntos, eles funcionam como **um registry público para a economia circular** — infraestrutura aberta de Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)) para créditos ambientais, incluindo créditos de carbono, sobre a qual standards estabelecidos, registries e coalizões de compradores podem construir.
## O que torna a infraestrutura "pública" [#o-que-torna-a-infraestrutura-pública]
Na literatura de DPI, o que torna uma infraestrutura pública não é quem a constrói ou possui, mas **como ela é governada** — se foi criada e governada para o bem comum. A Rede Carrot foi construída para atender a esse teste por meio de mecanismos, não de garantias abstratas:
* **Propósito travado.** A rede é zelada pela [Carrot Foundation](/docs/network/the-foundation), uma fundação suíça cujo propósito é fixado em sua escritura, supervisionado externamente e não pode ser redirecionado para ganho privado.
* **Regras abertas.** O código de verificação que executa cada metodologia é open source e publicamente inspecionável; os frameworks de metodologia são versionados e documentados.
* **Verificação independente.** A verificação é executada por software determinístico e revisada por organismos independentes de validação e verificação — não pela própria Carrot.
* **Registros públicos.** Emissão, transferência e aposentadoria de créditos são registradas em um registry público que qualquer pessoa pode auditar.
* **Compartilhamento de recompensas.** Com taxas transparentes e publicadas, 100% dos recursos financiam o ecossistema e a rede que o serve: os recursos de cada venda de crédito fluem para as pessoas que realizam o trabalho ambiental, conforme a [Política de Distribuição de Recompensas](/docs/standard/policies/rewards-distribution) publicada — [governados](/docs/network/governance), não discricionários.
## O que os trilhos permitem [#o-que-os-trilhos-permitem]
Como os trilhos tornam os resultados **mensuráveis, verificáveis e financiáveis**, eles abrem um caminho que mercados têm dificuldade de construir: compradores e coalizões podem se comprometer com resultados verificados antes de esses resultados existirem — compromissos antecipados e baseados em resultados que reduzem o risco para os produtores que os entregam. A Rede Carrot fornece a verificação, o registro único e a liquidação que esses compromissos exigem; ela não opera compromissos de mercado nem atua como compradora. E, longe de competir com o governo, a infraestrutura foi construída para trabalhar com o setor público e aliviar sua carga — o Estado mantém seu mandato, sua autoridade regulatória e seu papel de garantia de última instância. O que a rede garante, um regulador pode optar por endossar ou rejeitar a qualquer momento.
## Aprofunde [#aprofunde]
O argumento completo — o caso de formação de mercado, o teste de governança pública, como a rede é financiada, as salvaguardas incorporadas ao desenho e o que o modelo significa para financiadores, participantes, compradores e governos — está no White Paper:
**→ [White Paper: Infraestrutura Pública Digital para o Financiamento Climático Global](/docs/network/white-paper)** *(leia online ou baixe o PDF)*
**Páginas relacionadas:** [A Rede](/docs/network) · [Governança](/docs/network/governance) · [A Carrot Foundation](/docs/network/the-foundation) · [Política de Distribuição de Recompensas](/docs/standard/policies/rewards-distribution)
# White Paper: Infraestrutura Pública Digital para o Financiamento Climático Global
{/* cspell:words Mazzucato Vasconcellos Aadhaar X-Road MOSIP UNDP Ransohoff Symbiosis IHLEG Baku Belem Belém LGPD GDPR UCL IIPP ODET Lemos Mckee Doria LTDA Eloverde Gavi Nilekani Omidyar permissioned não-rivais não-excludentes minimização */}
*Ian McKee · Marcelo Doria — Carrot Foundation*
**v1.6 · Julho de 2026** · [Baixar PDF (em inglês)](/downloads/dpi/Carrot-DPI-White-Paper-Circular-Economy-2026-v1.6.pdf)
Para a versão curta, consulte [Infraestrutura Pública Digital](/docs/network/digital-public-infrastructure).
## Moldando a economia de que precisamos [#moldando-a-economia-de-que-precisamos]
Resolver os problemas mais difíceis do mundo — entre eles as mudanças climáticas, a gestão dos recursos naturais e o desenvolvimento humano — dependerá da construção de sistemas econômicos mais sustentáveis e de novos tipos de tecnologia para viabilizá-los. Uma economia sustentável valoriza **bens públicos**, não apenas bens privados. A dificuldade é que os mercados necessários para essa economia quase não existem: os resultados mais importantes — clima estável, ar e água limpos, materiais recuperados, terras restauradas, comunidades saudáveis e produtivas — beneficiam todos, mas quase ninguém paga por eles. Regras públicas e mercados privados assumem parte dessa responsabilidade, mas nenhum dos dois, isoladamente, direciona capital de forma confiável aos resultados de que a sociedade precisa coletivamente.
A escala do capital que deixa de fluir torna isso concreto. No âmbito do processo climático da ONU, o roteiro de Baku a Belém estima em cerca de **US$ 1,3 trilhão por ano até 2035** o financiamento externo de que o Sul Global precisará para a ação climática. Em 2023, o total vindo do exterior foi de aproximadamente **US$ 196 bilhões** — cerca de **15%** do necessário. E a lacuna é maior justamente onde deveria haver um mercado: espera-se que o capital privado forneça aproximadamente metade da meta, mas o financiamento climático privado transfronteiriço chegou a apenas cerca de **US$ 42 bilhões** — precisaria crescer aproximadamente **quinze vezes** (Climate Policy Initiative, 2025).
Uma insuficiência dessa dimensão não é um mercado funcionando mal nas margens e aguardando correção; é um mercado que **nunca foi formado**. E ela persiste porque formar mercados é, acima de tudo, um **problema de coordenação** — que nem empresas nem governos, agindo sozinhos, estão em posição de resolver. Nenhuma empresa pode construir sozinha um mercado cujo valor beneficia a todos; todo concorrente que se beneficiasse sem contribuir pegaria carona no investimento. Tampouco um único governo pode construí-lo: os problemas atravessam fronteiras, e o consenso entre muitos governos demora a se formar. A formação de mercados exige uma forma de aqueles que estão prontos para agir — compradores, desenvolvedores, financiadores e órgãos públicos — coordenarem-se no nível do sistema, sem esperar unanimidade no âmbito individual ou intergovernamental.
Formar mercados é um trabalho diferente de corrigi-los, e uma coordenação nesse nível exige três elementos ao mesmo tempo. Exige um **novo tipo de sistema de financiamento** — que oriente o desenvolvimento a resultados claros e verificáveis, ambientais e sociais, direcionando capital a resultados, não a promessas, para que o valor alcance as pessoas que os produzem. Exige uma **nova camada de tecnologia** que torne esses resultados confiáveis — medidos, verificados de forma independente, registrados de forma única e liquidados com transparência — e transforme as ferramentas que constrói em bens públicos compartilhados, não em gargalos privados. E exige um **novo tipo de organização** para administrar essa camada — vinculada a um propósito claramente declarado que não possa abandonar silenciosamente, governada com transparência e aberta à participação das pessoas que atende.
Essa camada é a [**infraestrutura pública digital (DPI)**](/docs/network/digital-public-infrastructure). Na forma descrita neste documento, ela está fora do governo, mas trabalha em parceria com ele — e com o setor privado, a filantropia, as finanças, a tecnologia e a ciência — para estabelecer confiança entre partes que, de outro modo, não cooperariam, permitindo que o capital flua para resultados. Sua administração é coordenada por uma **fundação cujo propósito é fixado em sua escritura e não pode ser redirecionado para ganho privado**. Seu desenvolvimento é progressivamente aberto às pessoas que a utilizam: contribuidores, desenvolvedores e participantes.
**A Rede Carrot é infraestrutura pública digital para a economia circular de baixo carbono e eficiente no uso de recursos — os trilhos compartilhados para uma economia de baixa poluição, regenerativa e inclusiva.** Seu propósito é ambiental *e* social ao mesmo tempo: usar capital com mais eficiência para melhorar a circularidade, reduzir a extração de recursos naturais, diminuir a poluição e enfrentar as mudanças climáticas, enquanto cria **empregos verdes**, renda e oportunidades locais para as pessoas que realizam o trabalho. As metodologias, o registry público e o código de verificação que compõem esses trilhos são [**bens públicos digitais**](/docs/glossary#digital-public-goods) — abertos, auditáveis e disponíveis para qualquer pessoa que construa sobre eles. Hoje, a Carrot demonstra o modelo em resíduos, reciclagem e metano. Como o padrão é geral e a necessidade vai muito além dos resíduos, os mesmos trilhos foram construídos para se estender a outros domínios ambientais — entre eles água, natureza e biodiversidade. A economia circular de baixo carbono é, portanto, o caso que este documento desenvolve por completo — e o padrão que ele demonstra é o de que o financiamento climático necessita onde quer que um resultado tenha de ser verificado antes de poder ser pago.
E, como essas ferramentas abertas tornam os resultados **mensuráveis, verificáveis e financiáveis**, elas abrem um caminho que os mercados têm dificuldade de construir: compradores podem se comprometer com resultados antes de eles existirem e reduzir o risco do investimento necessário para produzi-los. Coordenada, essa demanda se transforma em um novo tipo de financiamento climático e de desenvolvimento — que paga por resultados, não por promessas.
## O que significa "infraestrutura pública digital" [#o-que-significa-infraestrutura-pública-digital]
Infraestrutura Pública Digital (DPI) é o termo usado pelo University College London (UCL) Institute for Innovation and Public Purpose, pelo Programa das Nações Unidas para o Desenvolvimento, pelo Banco Mundial e pelo G20 para sistemas digitais que funcionam como trilhos compartilhados para toda a sociedade, e não como plataformas proprietárias. Essas instituições compartilham uma *família* de definições, não um único texto canônico, mas convergem em algumas características: a DPI é **fundacional** (outros serviços são construídos sobre ela), **interoperável** (funciona por meio de padrões abertos, não da infraestrutura de um único fornecedor), **inclusiva** (projetada para amplo acesso) e **publicamente responsável** (governada de forma aberta). Os casos de referência são as camadas fundacionais de identidade, pagamentos e troca de dados — Aadhaar e UPI na Índia, Pix no Brasil, X-Road na Estônia e o MOSIP open source. O Banco Mundial descreve o padrão como uma pilha de três funções de confiança — **identidade confiável, troca de dados confiável e liquidação confiável** — sobre a qual outros serviços podem ser construídos depois que ela se torna pública.
Uma ideia estreitamente relacionada é a de **bens públicos digitais** — termo usado pela ONU e pela Digital Public Goods Alliance para software open source, padrões abertos, dados abertos e conteúdo aberto que podem ser reutilizados e adaptados livremente. A relação é simples: a infraestrutura é o trilho, e os bens públicos digitais são as partes abertas que a compõem. A DPI é *mais* poderosa quando seus componentes centrais também são bens públicos digitais: não rivais (o uso por um participante não reduz o uso por outro) e não excludentes (licenças e padrões abertos permitem que outros construam sobre os trilhos sem pedir permissão — e, se necessário, deem continuidade a eles de forma independente). A Rede Carrot é construída segundo esse padrão: seus componentes centrais são **bens públicos digitais** — recursos compartilhados e inspecionáveis sobre os quais qualquer operador, verificador, autor de metodologia ou desenvolvedor de aplicação pode construir.
Nenhuma dessas definições exige um *proprietário* específico. Como afirmam o UNDP e o UCL IIPP, a DPI é um empreendimento multissetorial que pode ser construído por governos, pelo setor privado, por organizações filantrópicas ou por vários deles em conjunto. A Rede Carrot aplica essa ideia a um domínio que os casos fundacionais ainda não alcançaram: **financiamento baseado em resultados para o avanço ambiental e social**. Ela constrói sua camada de identidade, regras de metodologia, pipeline de evidências, registry público e distribuição de recompensas como trilhos de mercado compartilhados — utilizáveis por muitos participantes independentes e governados para a missão, não para ganho privado. Começa pela redução de resíduos por meio de recuperação, reuso e reciclagem — primeiro domínio escolhido por seu potencial de alavancagem. Desviar resíduos orgânicos de aterros sanitários reduz o **metano**, a forma mais rápida e eficaz de frear o aquecimento no curto prazo, e o setor de resíduos pode fazer isso reduzindo custos no nível do sistema (UNEP, *Global Methane Status Report*, 2025). Isso também abre caminho para a **economia circular** mais ampla: estima-se que dois terços das emissões globais estejam ligados à forma como os recursos são extraídos, usados e descartados, e que intervenções de economia circular sejam capazes de entregar cerca de 85% das reduções adicionais de emissões necessárias, além dos compromissos nacionais atuais, para manter o aquecimento abaixo de 2 °C (*Circularity Gap Report*, 2021). Estima-se que a transição que elas viabilizam possa evitar até 76 GtCO₂e em emissões até 2050 (WBCSD, *Global Circularity Protocol*).
## O que torna a infraestrutura "pública" [#o-que-torna-a-infraestrutura-pública]
Se a propriedade não determina o que é público, o que determina? Uma resposta recente e rigorosa vem de Mazzucato, Eaves e Vasconcellos (UCL IIPP, *Digital Public Infrastructure and Public Value: What is "public" about DPI?*, 2024). A conclusão central é aquela sobre a qual a Rede Carrot foi construída:
> **O caráter público da infraestrutura digital não é determinado por quem a constrói ou possui, mas por como ela é governada: se é criada e governada para o bem comum.**
Os autores mostram que definir DPI por seus *atributos técnicos* (padrões abertos, componentes reutilizáveis) ou por suas *funções* (as capacidades essenciais que oferece) é necessário, mas, em suas palavras, deixa a governança "em grande medida sem resposta". A infraestrutura só merece o rótulo de "pública" quando valores públicos explícitos são protegidos e aplicados. Eles estabelecem cinco princípios de governança — derivados do framework de "bem comum" de Mazzucato — pelos quais qualquer possível DPI pode ser avaliada:
* **Propósito e direcionalidade** — a infraestrutura tem uma missão explícita, e essa missão orienta o que ela faz.
* **Cocriação e participação** — as pessoas que a utilizam ajudam a moldá-la.
* **Aprendizado coletivo e compartilhamento de conhecimento** — métodos e evidências são abertos o suficiente para que outros aprendam com eles.
* **Acesso para todos e compartilhamento de recompensas** — o valor alcança amplamente os participantes, não apenas o operador.
* **Transparência e responsabilização** — regras, decisões e finanças podem ser inspecionadas.
Esses princípios descrevem governança e resultados, não origens. Os mesmos autores aceitam que a infraestrutura compartilhada "pode ser fornecida tanto por organizações públicas quanto privadas, ou até mesmo desenvolvida em conjunto" — *desde que*, independentemente de como seja construída, um mecanismo publicamente responsável garanta acesso e compartilhamento de recompensas ao longo do tempo. Essa condição explica por que os componentes centrais da rede são disponibilizados como bens públicos digitais: metodologias abertas, um registry aberto e código de verificação aberto transformam "acesso para todos" e "aprendizado coletivo" de promessas em propriedades que qualquer pessoa pode verificar. **Esse também é o standard que a Rede Carrot foi construída para atender — e a próxima seção o enfrenta diretamente.**
## Como a Rede Carrot atende ao teste de governança pública [#como-a-rede-carrot-atende-ao-teste-de-governança-pública]
A Rede Carrot é administrada pela **Carrot Foundation** (registrada como "Carrot Fndn"), uma fundação suíça constituída nos termos do Artigo 80 *e seguintes* do Código Civil Suíço, registrada em Zug (UID CHE-152.448.302), criada em outubro de 2023 e supervisionada pela Autoridade Federal de Supervisão de Fundações da Suíça (ESA). O propósito estatutário (*Zweck*) de uma fundação suíça não pode ser alterado por seu próprio conselho; ela é supervisionada e auditada externamente. Essa forma jurídica permite que a Fundação atue como **administradora, não proprietária** — ela pode evoluir a forma como a rede opera, mas não pode desviar a rede do propósito que justifica sua existência. Esse é o novo tipo de organização mencionado na abertura deste documento: propósito declarado e protegido, governança transparente e supervisão externa. Ele também responde ao problema de coordenação em sua origem: um mercado cujo valor beneficia a todos só pode ser formado por um ator que não precise capturar esse valor — e uma administradora sem fins lucrativos, vinculada a um propósito imutável, é esse ator por definição.
Em relação aos cinco princípios de governança:
* **Propósito e direcionalidade.** O propósito da Fundação — construir uma economia circular inclusiva e de baixo carbono — está registrado em sua Escritura e no registro comercial suíço e é vinculante segundo a legislação suíça. É uma obrigação, não apenas uma aspiração.
* **Cocriação e participação.** Participantes dos ecossistemas de trabalho ambiental e desenvolvimento social são contrapartes diretas da rede e ajudam a moldar sua evolução. Ao longo do tempo, a responsabilidade por diferentes aspectos da rede foi projetada para ser **gerenciada de forma distribuída e descentralizada**, em vez de se concentrar em um único operador; hoje, a rede é centralizada para garantir qualidade fundacional e uma liderança inicial sólida — escolha abordada com transparência em *Construindo DPI com responsabilidade*, abaixo —, e a participação se amplia à medida que ela amadurece. *(Este é um desenho de benefícios e gestão distribuídos, não uma concessão de direitos de controle a participantes individuais.)*
* **Aprendizado coletivo e compartilhamento de conhecimento.** O código de verificação que executa cada metodologia é **open source sob a LGPL-3.0** e [publicamente inspecionável](https://github.com/carrot-foundation/methodology-rules); os frameworks de metodologia são [versionados e documentados](/docs/methodologies); o pipeline de evidências de Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)) para créditos de carbono permite que verificadores homologados, autores de metodologia e desenvolvedores de aplicações trabalhem sobre regras compartilhadas e documentadas, não sobre planilhas privadas.
* **Acesso para todos e compartilhamento de recompensas.** A rede é aberta aos participantes de todo o ecossistema de criação de valor, e o valor flui para as pessoas que realizam o trabalho ambiental, na proporção de sua contribuição verificada — em vez de se concentrar no operador. Com taxas transparentes e publicadas, 100% dos recursos financiam o ecossistema e a rede que o atende — pelo menos 80% de cada venda de crédito são distribuídos aos participantes do ecossistema, e o restante sustenta os trilhos públicos (consulte *Como a rede é financiada*, abaixo) —, e as parcelas de recompensa são ajustadas por tipo de impacto — para resultados de economia circular, por material, território e papel — a fim de direcionar esforços para onde a recuperação é mais difícil. O ajuste orienta os esforços; ele depende da emissão e da venda de um crédito. *(O comprador detém o crédito e passa a tê-lo integralmente na aposentadoria; os participantes são recompensados por sua contribuição, mas nunca são proprietários do próprio crédito.)*
* **Transparência e responsabilização.** Além da supervisão federal descrita acima, o registro subjacente é imutável: há um histórico duradouro de todas as transações e atualizações de cada dado, e os **principais resultados — emissão, transferência e aposentadoria de créditos — são registrados em um [registry público](/docs/registry) que qualquer pessoa pode auditar**. Nem toda parte da plataforma é registrada publicamente, e alguns dados operacionais têm **acesso restrito a auditores e verificadores**, em vez de serem abertos a todos — um equilíbrio deliberado entre auditabilidade pública e privacidade das pessoas e empresas cujo trabalho é registrado, com dados pessoais e operacionais criptografados e tratados segundo a legislação de proteção de dados aplicável e práticas alinhadas ao GDPR (consulte *Construindo DPI com responsabilidade*, abaixo).
## Como a rede é financiada — e como reduz o risco da participação [#como-a-rede-é-financiada--e-como-reduz-o-risco-da-participação]
Os resultados ambientais e sociais buscados pela rede são bens públicos que se tornam financiáveis na forma de créditos. A rede opera com sistemas de créditos e é sustentada pela venda de créditos — resultados ambientais verificados pelos quais um comprador paga, descritos em detalhes em *A extensão ambiental*, abaixo. A integridade dos créditos depende de quem define as regras, quem emite os créditos e quem lucra — e de manter esses papéis separados e íntegros. A Carrot foi construída para mantê-los distintos. Ela é uma **administradora sem fins lucrativos, vinculada a um propósito imutável**. Não tem acionistas, e suas taxas não funcionam como um dividendo que cresce com a emissão. As regras que determinam o que se qualifica são **open source e auditáveis**; a verificação é executada por software determinístico e revisada por **organismos independentes de validação e verificação ([VVBs](/docs/glossary#vvb))**, não pela própria Carrot; e o registro de cada crédito é público. A Carrot foi construída como infraestrutura aberta sobre a qual standards e registries estabelecidos podem construir e com a qual podem interoperar, conquistando credibilidade por meio de resultados demonstrados e reconhecimento independente, não por autodeclaração. O objetivo não é acrescentar mais um standard a um campo já saturado, mas fornecer a camada que tem faltado — trilhos compartilhados e abertos para identidade, verificação, registro e liquidação.
Os recursos de cada venda de crédito são distribuídos aos participantes registrados ao longo da cadeia de criação de valor, na proporção de sua contribuição verificada, conforme a [Política de Distribuição de Recompensas](/docs/standard/policies/rewards-distribution) publicada. A distribuição utiliza uma moeda digital rastreável (USDC), escolhida porque permite liquidação transfronteiriça a baixo custo, alcança os participantes diretamente e deixa uma trilha auditável de ponta a ponta, da venda ao destinatário. O que não é distribuído aos participantes é organizado em **fundos com propósito definido**, para que esteja sempre visível *para que* serve cada unidade de valor — a economia da rede é governada, não discricionária por padrão:
* **Treasury — operações da Fundação.** Financia gestão, administração, área jurídica, conformidade, governança e conselho da Fundação. É abastecida por taxas publicadas sobre o trabalho realizado pela Fundação — uma **taxa de registry (1%, quando a Carrot é o registry oficial)**, uma **taxa de distribuição de recompensas/liquidação (2,5%)** e **encargos de dMRV/integridade (atualmente 16,5%, variando conforme o cenário)**. Juntos, eles formam a parcela da rede — 20% quando a Carrot é o registry oficial —, de modo que 100% de cada venda de crédito financia a missão: pelo menos 80% chegam diretamente ao ecossistema, e o restante sustenta os trilhos públicos. Essa divisão pode ser verificada na Política de Distribuição de Recompensas, em vez de ser apenas anunciada como uma taxa principal. Como a Treasury é financiada por taxas publicadas cobradas por uma administradora sem fins lucrativos — não por um dividendo que cresce com a emissão —, financiar a rede nunca compete com a proteção de sua integridade.
* **Community Pool — crescimento do ecossistema.** Financia onboarding, expansão e uso da rede em todo o mundo. É abastecido por três mecanismos de incentivo da rede: o desconto aplicado enquanto um participante importante — nas cadeias de reciclagem, o [Gerador de Resíduos](/docs/protocol/supply-chain) — ainda não está identificado, o que incentiva a digitalização completa até a origem; o mecanismo de self-policing, que retém recompensas de agentes mal-intencionados; e as recompensas não resgatadas. O valor que, de outra forma, ficaria ocioso é reciclado para o crescimento da rede aberta — e esse fundo foi projetado para avançar em direção à governança aberta, para que outros atores do ecossistema possam ajudar a orientá-lo.
* **Impact Pool — desenvolvimento local.** Quando o Gerador de Resíduos é uma grande empresa, parte das recompensas que receberia é direcionada a esse fundo, que financia projetos socioambientais e de economia circular **no âmbito nacional**. Isso mantém um incentivo à participação e um fluxo básico de recompensas para prestadores de serviços em todo o ecossistema, enquanto garante que compradores de créditos não financiem recompensas para grandes corporações — direcionando esse valor ao engajamento e ao desenvolvimento locais.
Dois desses fundos transformam os próprios mecanismos de integridade da rede em combustível para o bem público. O **incentivo à rastreabilidade até a origem** — um desconto ao longo da cadeia de prestadores de serviço quando o gerador não é identificado — torna a digitalização completa até a origem economicamente vantajosa, e o valor que ele libera flui para o crescimento do ecossistema, não para uma parte privada. O **mecanismo de self-policing** vincula as recompensas a dados íntegros: como elas fluem ao longo da cadeia de custódia de cada unidade subjacente, um registro sinalizado por dados ruins ou fraudulentos é desqualificado, retendo as recompensas de *todos* naquela cadeia. Assim, por exemplo, se um transportador e um reciclador enviassem dados falsos para inflar as recompensas, os Geradores de Resíduos ligados a eles também deixariam de ser recompensados — colocando em risco a continuidade do próprio serviço contratado. O mesmo ocorreria em qualquer projeto que não cumprisse os marcos acordados, garantindo que todos na cadeia colaborem e trabalhem em direção ao objetivo comum. Dados íntegros são condição para receber qualquer recompensa, e o valor retido financia o ecossistema. A Fundação também pode suspender ou remover agentes mal-intencionados.
Do ponto de vista da oferta, esses mesmos mecanismos **reduzem o risco da participação**. Um reciclador, uma cooperativa ou um município decidindo se deve investir em coleta, triagem ou mensuração encontra um conjunto previsível de regras, não um sistema discricionário: as recompensas estão vinculadas a resultados verificados, não a um preço volátil definido pelo operador; a tabela de taxas é publicada na Política de Distribuição de Recompensas, e suas alterações passam pela governança, não pela discricionariedade do operador; e o valor alcança todos os papéis verificados da cadeia na mesma transação, em vez de se concentrar em um único comprador ou intermediário. Recompensas distribuídas conforme regras previsíveis e publicadas, em contrapartida a resultados verificados, permitem que um pequeno operador trate o trabalho ambiental como investimento, não como aposta. Esse é o sistema de financiamento mencionado no início, visto pelo lado da oferta — e a condição para os compromissos do lado da demanda descritos em *Formando mercados*, abaixo.
## Trabalhando com o Estado — e o que a Fundação garante [#trabalhando-com-o-estado--e-o-que-a-fundação-garante]
A literatura sobre DPI geralmente pressupõe que um *Estado* sustente a infraestrutura, garantindo acesso e compartilhamento de recompensas. A Rede Carrot não tem um Estado por trás dela — por isso, precisa deixar claro o que oferece essas garantias e como trabalha ao lado do setor público, não contra ele.
Algumas coisas só um governo pode fazer: tornar a participação obrigatória em todo um mercado, exercer um mandato eleitoral e atuar como garantia de última instância. **A Carrot Foundation não reivindica nenhuma delas**, pois é uma camada de mercado *opcional e adicional*, não uma controladora de acesso a qualquer serviço essencial. O que uma fundação vinculada a um propósito imutável *pode* garantir são justamente os elementos de que um mercado voluntário precisa para ser confiável — ou que um regulador pode decidir endossar ou rejeitar a qualquer momento:
* **Nenhuma captura privada, por definição.** O propósito é fixado na Escritura e não pode ser redirecionado ao ganho privado por uma decisão ordinária — apenas por meio do processo de supervisão externa previsto pela legislação suíça para alterar o propósito de uma fundação.
* **Responsabilização externa.** A supervisão e a auditoria federais estão acima da própria gestão da Fundação.
* **Continuidade que não depende da administradora.** Como o código de verificação é open source e o registry público de créditos e as metodologias abertas não estão presos à Carrot, os trilhos podem sobreviver à instituição que os administra hoje. Se a Fundação fracassasse ou se desviasse de seu propósito, os ativos públicos da rede continuariam auditáveis — e poderiam ser assumidos e mantidos por outros.
Longe de competir com o governo, a infraestrutura foi construída para *aliviar sua carga*. Ela pode reduzir custos públicos — tratamento de resíduos e fiscalização, impactos da poluição não controlada sobre a saúde pública, remediação de terras e águas contaminadas — liberando orçamentos municipais enquanto apoia a produtividade local e empregos verdes. Também reúne tecnologia, financiamento e dados verificados no nível do sistema, entre jurisdições, cadeias de valor e fronteiras — além do alcance de qualquer governo isolado. Nesse sentido, é uma **facilitadora** para o setor público e uma **salvaguarda** para o mercado que sustenta: o sistema de dMRV executa a verificação, [Integradores](/docs/protocol/network-integrators) fornecem os dados de rastreabilidade e a infraestrutura oferece a liquidação de que esse mercado precisa para ser confiável, enquanto o Estado preserva seu mandato, sua autoridade regulatória e seu papel de garantia de última instância. O resultado é uma divisão de responsabilidades clara — **propósito público ancorado em uma fundação vinculada a um propósito imutável e em infraestrutura aberta; autoridade pública preservada e exercida pelo Estado.**
## Um novo caminho: capital privado, destino público [#um-novo-caminho-capital-privado-destino-público]
Resta uma pergunta da seção anterior: uma infraestrutura sem um Estado por trás pode inspirar o mesmo grau de confiança? A maior parte das DPIs até hoje foi iniciada pelo Estado — a UPI sob o mandato de um banco central, a X-Road pelo Estado estoniano, o MOSIP como colaboração multilateral open source. A liderança estatal construiu os casos de referência e oferece forças que nenhuma fundação consegue reproduzir: escala, mandato e legitimidade democrática. Mas também traz riscos já conhecidos pela experiência com DPI. Prioridades e financiamento podem mudar com governos e ciclos orçamentários, expondo a infraestrutura a retrocessos políticos ou subinvestimento; compromissos com a abertura podem ser difíceis de sustentar durante transições políticas; um sistema financiado como uma linha do orçamento nacional compete com todas as demais necessidades desse orçamento; e uma infraestrutura vinculada a um único Estado não atende com facilidade pessoas e mercados além de suas fronteiras.
Nada disso é um argumento contra a liderança pública — é um argumento de que a confiabilidade da infraestrutura não depende de quem a possui, mas de sua capacidade de manter propósito, financiamento e governança ao longo do tempo político. A literatura sobre DPI chega à mesma conclusão pela direção oposta: ela não exige uma *origem* estatal — apenas *governança* pública. A Co-Develop trata quem constrói a DPI como uma escolha de desenho em aberto, desde que a responsabilização pública seja preservada; o artigo do UCL IIPP aceita DPI gerida pelo setor privado desde que acesso e compartilhamento de recompensas sejam garantidos. A lição é que **a operação pode ser não governamental, desde que algo garanta o destino público.**
A Rede Carrot aplica esse padrão a um domínio em que a coordenação transfronteiriça tem sido lenta — os mercados ambientais —, usando **capital privado como gatilho** e uma fundação vinculada a um propósito imutável como garantidora do **destino público**:
* **O gatilho é privado.** A Solidos Brasil LTDA, empresa de desenvolvimento (o "Lab"), captou capital inicial por meio de instrumentos convencionais para desenvolver os trilhos abertos, o standard de metodologias e o pipeline de dMRV.
* **A transferência é estrutural.** Por meio de um acordo de cessão de propriedade intelectual assinado em 22 de dezembro de 2023, a Solidos Brasil LTDA cedeu a propriedade intelectual da Rede Carrot — código, metodologias, registries, domínios e conteúdos relacionados — à Carrot Foundation, que agora a mantém sob sua administração conforme a legislação suíça sobre fundações. A Solidos Brasil foi a primeira empresa a construir a tecnologia da rede; hoje, continua esse trabalho para a Fundação ao lado de um conjunto crescente de desenvolvedores independentes — entre eles **EcoCircle**, **Eloverde** e a **Mare Foundation** — como infraestrutura aberta projetada para muitos desenvolvedores.
* **O destino é público.** Governada nos termos do Art. 80 do ZGB, a Fundação é a administradora dos trilhos, vinculada ao propósito.
O modelo de fundação suíça como administradora está bem estabelecido para ativos de interesse público — é a estrutura usada há muito tempo pela filantropia em instituições vinculadas a uma missão, incluindo as parcerias para desenvolvimento de produtos sediadas em Genebra e criadas para a saúde global: a **Medicines for Malaria Venture**, fundação suíça desde 1999, e a **Drugs for Neglected Diseases initiative**, constituída, assim como a Carrot Foundation, nos termos do Artigo 80 *e seguintes* do Código Civil Suíço — ativos administrados para uma missão, não para proprietários. A Rede Carrot aplica esse padrão de administração a mercados ambientais — com os próprios trilhos disponibilizados como bens públicos digitais.
## A extensão ambiental [#a-extensão-ambiental]
Mercados ambientais precisam de um elemento de desenho que a infraestrutura de identidade e pagamentos não exigiu: um **instrumento de geração de créditos** para internalizar externalidades.
O uso de infraestrutura de identidade ou pagamentos gera valor imediato para o usuário, portanto a adoção se motiva por si só. O trabalho ambiental — reuso, reciclagem, compostagem, digestão anaeróbica, redução de superpoluentes (por exemplo, metano, óxido nitroso, ozônio ao nível do solo, carbono negro e gases fluorados), remoção de dióxido de carbono, reflorestamento, restauração de água e natureza, produção de energia renovável, entre outros — é diferente: produz valor (o bem público) para terceiros (a cidade, a atmosfera, as gerações futuras), e as pessoas que realizam o trabalho não são recompensadas automaticamente por quem se beneficia. Sem um mecanismo que canalize a disposição de compradores e partes obrigadas a pagar de volta às pessoas que produzem o resultado, os trilhos ficam sem combustível.
Os créditos da Carrot — o Crédito de Reciclagem e o Crédito de Carbono, registrados em um registry público e auditável — são esse mecanismo. Ambos já estão ativos: créditos foram emitidos, vendidos e aposentados, e os recursos foram distribuídos aos participantes registrados ao longo da cadeia de custódia de cada unidade subjacente. Eles são, na prática, um **instrumento de financiamento baseado em resultados**: o pagamento de um comprador é liberado mediante um resultado ambiental verificado, não uma promessa ou estimativa, e o valor que ele libera é distribuído às pessoas que produziram esse resultado. Esse é o modelo de financiamento que as próprias instituições de financiamento ao desenvolvimento formalizaram. O documento *Carbon Crediting: A Results-Based Approach to Mobilizing Additional Climate Financing* (2025), do Banco Mundial, enquadra os créditos como financiamento baseado em resultados — recursos liberados somente depois que os resultados são alcançados, medidos e certificados de forma independente —, com o fundo fiduciário **SCALE** como plataforma do Banco para financiamento climático baseado em resultados; o documento *Unlocking Social and Environmental Impact: Outcome-Based Finance* (2025), da IFC, defende instrumentos baseados em resultados como caminho para o capital de impacto em mercados emergentes. O mecanismo de créditos da Carrot aplica esse modelo em trilhos públicos e abertos: **a rede opera como um registry público para a economia circular — infraestrutura aberta e digital de MRV e créditos** sobre a qual standards, registries e coalizões de compradores estabelecidos podem construir. Os créditos são instrumentos de mercado que operam *sobre* trilhos de propósito público, com regras e fluxos de valor visíveis e inspecionáveis. O padrão de DPI absorve essa extensão de forma direta: **o trilho permanece público; o crédito é a camada de formação de mercado que torna o trilho economicamente viável para as pessoas que realizam o trabalho ambiental.** Um ponto crucial de integridade: registrar um crédito em um registry público confere durabilidade e auditabilidade — não integridade. A integridade vem da metodologia e da verificação independente *antes* do registry. A Carrot é a infraestrutura compartilhada sobre a qual operadores, autores de metodologia, verificadores homologados e compradores constroem; ela não executa projetos ambientais em campo e não é a verificadora. Essa separação permite que a rede funcione como trilhos compartilhados para todas as partes interessadas — e, como todas constroem sobre a mesma infraestrutura aberta, torna a rede escalável e interoperável.
## Formando mercados, não apenas registrando-os [#formando-mercados-não-apenas-registrando-os]
Trilhos públicos e um instrumento de geração de créditos tornam um mercado *possível*. O que o faz *funcionar* é a capacidade de moldar a demanda e reduzir o risco da oferta, permitindo que o capital se mova antes que o resultado exista. É aqui que a infraestrutura pública faz mais do que registrar transações — ela pode ajudar a *transformar* um mercado, moldando-o na direção de um resultado definido, em vez de apenas compensar transações individuais.
Essa reformulação tem uma base rigorosa e depende de uma distinção que vale explicitar. A visão convencional trata o mercado como uma condição natural que ocasionalmente **falha** — por externalidades como a poluição ou pela ausência de bens públicos —, deixando ao setor público o papel de **corrigir** a falha e então recuar. Em *Governing the Economics of the Common Good: from correcting market failures to shaping collective goals* (2024), Mazzucato rejeita essa premissa: mercados não são dados naturais a serem remendados, mas *"resultados de estruturas de governança"* — construídos e, portanto, passíveis de ser **moldados** pelos atores que os governam. A tarefa não é *corrigir* um mercado depois que ele falha, mas **formá-lo e moldá-lo**, orientando-o para uma direção escolhida coletivamente.
Para a economia ambiental, a distinção é decisiva — é o diagnóstico que abriu este documento. As centenas de bilhões que deveriam fluir para resultados ambientais e sociais verificados, mas não fluem, indicam um mercado a **formar**, não uma falha a corrigir. Os canais atuais tampouco o formarão sozinhos: o financiamento climático privado transfronteiriço flui predominantemente como dívida de projetos para energia em escala de serviços públicos em poucos grandes mercados, **e não alcança o trabalho ambiental distribuído** — pequenos produtores, cooperativas e cadeias municipais — onde os resultados de economia circular são efetivamente produzidos. Parte do que mantém esse trabalho fora de alcance é o custo de entrada: programas e registries convencionais de créditos cobram taxas iniciais de homologação e registro que excluem pequenos e médios operadores — poucas instalações de compostagem ou centros de reciclagem conseguem arcar com a homologação em um registry, muito menos assumir esse custo sem garantia de que a venda de créditos algum dia o compensará. Como registry digital nativo, a Carrot reduz significativamente esse custo de participação — ampliando o acesso e, com ele, uma oferta de créditos que os mercados atuais ainda não alcançam. A Carrot é infraestrutura para essa formação: um trilho governado para um propósito público fixo, construído para dar direção a um mercado, não apenas registrar o que acontece dentro dele.
O mecanismo que faz isso do lado da demanda é a **demanda antecipada coordenada** — clubes, coalizões e alianças de compradores (o padrão usado para vacinas e, agora, para remoção de dióxido de carbono) e, em sua forma mais estruturada, o Advance Market Commitment (AMC). Ele também é o mecanismo de coordenação mencionado na abertura deste documento: uma forma de compradores dispostos a agir em conjunto, no nível do sistema, sem esperar unanimidade. Um AMC é um compromisso assumido *antes* de a oferta existir para comprar um volume definido de um **resultado verificado** a um preço definido. Esse compromisso antecipado torna a oferta financiável: transforma "esperamos que alguém compre isto" em "este volume já está vendido", criando a certeza de demanda que permite que um fornecedor — e seus financiadores — invista. O AMC entra para dar a um mercado que precisa ser formado sua primeira demanda firme. O padrão tem histórico comprovado:
* **Saúde.** O caso canônico é o AMC pneumocócico: em 2009, cinco governos e a **Bill & Melinda Gates Foundation** comprometeram **US$ 1,5 bilhão** por meio da **Gavi, the Vaccine Alliance**, para garantir demanda por vacinas pneumocócicas antes que os fabricantes tivessem construído a oferta. Funcionou — mais de um bilhão de doses já foram fornecidas a países de renda mais baixa, e a licitação final reduziu o preço para US$ 2 por dose. A mesma lógica, em ritmo emergencial, sustentou os **acordos de compra antecipada da COVID-19**, que comprometeram cerca de **US$ 18 bilhões** com vacinas que ainda não existiam.
* **Remoção de carbono.** A Frontier Climate — coalizão de compradores criada pela Stripe — usou compromissos antecipados (pré-compras e contratos de compra com pagamento na entrega) para tirar tecnologias iniciais de remoção de carbono dos laboratórios. O compromisso de seus compradores cresceu para **US$ 1,8 bilhão** (junho de 2026), com cerca de **US$ 694 milhões já contratados** com fornecedores de remoção de carbono — e **71% dos fundadores afirmaram que isso influenciou sua decisão de criar uma empresa de remoção de carbono** (Ransohoff, *How to Start an Advance Market Commitment*, 2024). Ransohoff inclui explicitamente a **remoção de gases de efeito estufa, como metano e óxido nitroso,** entre os próximos domínios adequados para um AMC.
* **Em escala de coalizão.** A **Symbiosis Coalition** (Google, Meta, Microsoft e Salesforce) anunciou a intenção de contratar até **20 milhões de toneladas de créditos de remoção de carbono baseados na natureza até 2030** por meio de um processo compartilhado que prioriza a qualidade — um exemplo atual de compradores coordenando demanda antecipada. O *Commitments Playbook* (2024), da Renaissance Philanthropy, descreve como essas coalizões são formadas: compromissos âncora, um chamado público à ação e prazos definidos que transformam promessas em demanda coordenada.
Um compromisso antecipado, porém, só é tão confiável quanto a verificação e a liquidação que o sustentam. Para se comprometer a comprar "um resultado verificado" antes de ele existir, o comprador precisa confiar que o resultado poderá ser **verificado de forma independente**, **registrado de forma única**, para que não seja contado ou vendido duas vezes, e **liquidado com transparência**. Essas são as três funções de confiança — identidade, troca de dados e liquidação — fornecidas pela infraestrutura pública digital e pelos bens públicos digitais disponibilizados pela Rede Carrot: metodologias abertas, um registry público aberto e código de verificação aberto. Em termos de financiamento ao desenvolvimento, é isso que torna um resultado **financiável**: quando muitos compradores se comprometem antecipadamente a comprar uma produção futura, essa certeza de demanda permite que o capital trate pequenos produtores ambientais distribuídos como aptos a receber investimento — a lógica de formação de mercados que instituições de financiamento ao desenvolvimento já aplicam ao financiamento combinado (o International Finance Corporation defende esse argumento no financiamento de economia circular em mercados emergentes).
Esse é o caminho que a infraestrutura foi construída para viabilizar: **bens públicos digitais → resultados verificáveis e registrados de forma única → resultados com os quais compradores podem se comprometer antecipadamente → investimento financiável e com risco reduzido → um mercado que paga por resultados.** A Rede Carrot fornece a infraestrutura pública sobre a qual esses compromissos podem ser coordenados, acompanhados e ampliados. Ela não opera um compromisso de mercado nem atua como compradora; torna o padrão possível e confiável para coalizões, financiadores e partes obrigadas que o executam. Os trilhos são deliberadamente indiferentes ao motivo pelo qual um comprador paga: seja a demanda proveniente de uma coalizão voluntária, de uma parte obrigada por regulamentação ou de um programa público que paga por resultados, a verificação, o registro único e a liquidação são os mesmos. Nenhum mercado voluntário consegue, sozinho, fechar uma lacuna da dimensão apresentada no início deste documento; o que ele comprova é a infraestrutura de confiança de que todo canal de demanda precisa para alcançar o trabalho distribuído onde os resultados são produzidos. Usada dessa forma, a infraestrutura apoia uma transição do financiamento climático e ambiental **de promessas para resultados verificados** — construída sobre trilhos públicos.
## A Carrot no debate global sobre DPI [#a-carrot-no-debate-global-sobre-dpi]
Os mercados ambientais agora são uma fronteira explícita para DPI — e a Carrot é uma contribuição operacional a essa fronteira, não uma alegação sem base concreta:
* O **relatório *Digital Public Infrastructure for Climate* do ITS Rio e de Ronaldo Lemos** (2025), preparado para a Presidência da COP30, descreve a "Climate DPI" como um sistema operacional para a ação climática e propõe uma "ClimateStack" modular cujas camadas incluem explicitamente **mercados de carbono e liquidação de créditos e financiamento climático** — funções voltadas ao mercado, não apenas aos dados. A Rede Carrot é uma implementação operacional em estágio inicial dessa função de financiamento e registry, focada primeiro em resíduos e metano, e demonstra como essas camadas de liquidação e mercado podem ser construídas como bens públicos, não como uma bolsa proprietária. Com os parceiros e o capital adequados, os mesmos trilhos podem atender a DPI de natureza e clima de forma mais ampla — por desenho, eles são independentes de domínio.
* O trabalho **"Nature ID" do UNDP** propõe DPI para natureza e clima como uma camada de interoperabilidade para dados ambientais, rastreabilidade em mercados de carbono e créditos de biodiversidade — mencionando referências concretas como o Cadastro Ambiental Rural do Brasil.
* As instituições que definem DPI — **UCL IIPP**, o **Co-Develop Fund** (Rockefeller Foundation, Bill & Melinda Gates Foundation, Omidyar Network e Nilekani Philanthropies), o **UNDP** e o **Banco Mundial** — concentraram-se em identidade, pagamentos e troca de dados. A contribuição da Carrot é demonstrar que o mesmo padrão de desenho, o mesmo standard de governança e o mesmo potencial de formação de mercados se estendem a alegações ambientais — de resíduos e metano hoje a água, natureza e biodiversidade no futuro. A própria Carrot não comercializa materiais nem opera serviços em campo; ela torna tangível o valor do bem público verificado e o direciona ao ecossistema que o produziu.
## Construindo DPI com responsabilidade: os riscos que orientam nosso desenho [#construindo-dpi-com-responsabilidade-os-riscos-que-orientam-nosso-desenho]
A DPI não é automaticamente benigna, e um projeto de infraestrutura pública confiável deve dizer isso de forma concreta. O *Universal DPI Safeguards Framework* da ONU (UNDP e Escritório das Nações Unidas para Tecnologias Digitais e Emergentes, 2024) e uma extensa literatura independente documentam danos reais causados por sistemas reais — exclusão, vigilância e captura. A lição mais difícil das implementações em larga escala é precisa: **quando o acesso a um serviço essencial é condicionado a um trilho digital, as falhas desse trilho atingem com mais força as pessoas mais vulneráveis — e sistemas "voluntários" tendem a se tornar obrigatórios na prática à medida que o valor essencial se concentra no trilho.** Como construtora não estatal, a própria Rede Carrot está sujeita ao ciclo de vida do Universal DPI Safeguards, e aceitamos esse standard.
Como a rede foi desenhada para enfrentar cada modo de falha — com transparência, inclusive onde uma salvaguarda ainda está amadurecendo:
* **Exclusão / transição para obrigatoriedade na prática.** A Carrot recompensa pessoas por contribuições ambientais no nível do sistema; não se interpõe entre ninguém e seu alimento, sua identidade, seus benefícios ou seu sustento, portanto o risco de condicionar o bem-estar não surge da mesma forma. O risco mais sutil é próprio da Carrot: à medida que a demanda se concentra no trilho, um participante que não esteja registrado pode perder acesso ao mercado *recompensado* por sua contribuição. A rede é uma camada adicional de mercado: a participação é opcional, e os participantes podem negociar — e negociam — fora dos trilhos; compradores privados e canais administrados por municípios existem, embora continuem pequenos, locais e difíceis de escalar, e nenhum comprador é obrigado a adquirir créditos exclusivamente pela Carrot.
* **Vigilância e risco de dados.** Um registry que registra as contribuições de trabalhadores identificados é, por si só, uma possível superfície de vigilância, portanto o escopo da transparência pública importa. A transparência do registry público é **limitada aos registros de créditos** — emissão, transferência e aposentadoria —, enquanto dados operacionais e pessoais têm **acesso restrito a auditores e verificadores**, não são abertos a todos, e são tratados segundo práticas de minimização de dados, criptografia e retenção e conforme a legislação de privacidade aplicável (LGPD/GDPR), como estabelecido na [Política de Privacidade](/docs/terms/privacy-policy) publicada.
* **Captura.** A Carrot é **deliberadamente centralizada hoje**, sob uma equipe de desenvolvimento focada, para garantir qualidade fundacional, visão clara e liderança inicial sólida. Essa é uma característica da fase inicial, não o estado final: a participação se amplia para mais partes interessadas ao longo do tempo, e **salvaguardas são acrescentadas conforme a rede cresce, alinhadas ao propósito declarado da Fundação.** As proteções estruturais que permanecem são o propósito imutável (a missão não pode ser alterada unilateralmente), a supervisão federal externa e as interfaces e o código abertos, para que outros possam construir sobre os trilhos — e, se necessário, dar continuidade a eles de forma independente.
* **Integridade do registry.** Registrar um crédito em um registry público confere durabilidade e auditabilidade — não integridade. Mercados de carbono e ambientais já apresentaram créditos fracos como se fossem verificados; a Carrot aplica a integridade antes do registry, na **metodologia e na verificação independente por terceiros**. Por exemplo, cada unidade de material (um MassID) pode conter no máximo um crédito de carbono e um crédito de reciclagem, o que evita dupla contagem, e os benefícios associados nunca são precificados no crédito de carbono. As metodologias publicadas na Carrot enfrentam diretamente os riscos de compensação e greenwashing, e compradores de créditos que exagerem suas alegações podem ser suspensos.
Apresentamos esses compromissos para que possamos ser responsabilizados por eles, por meio de mecanismos identificados, não de garantias de bom caráter — código aberto que qualquer pessoa pode auditar, um registry público que qualquer pessoa pode inspecionar, supervisão federal da Fundação e uma [Política de Distribuição de Recompensas](/docs/standard/policies/rewards-distribution) e [Termos e Condições](/docs/terms/terms-and-conditions) publicados. Nesse domínio, a integridade precisa ser demonstrada por mecanismos — conformidade, rastreabilidade e transparência —, não declarada.
## Saiba mais [#saiba-mais]
O mercado mencionado na abertura deste documento não espera ser corrigido; espera ser formado — e nenhuma empresa ou governo pode formá-lo sozinho. Essa formação exige os três elementos indicados no início, e a Rede Carrot é onde eles podem coexistir em escala: um sistema de financiamento que direciona capital a resultados verificados e distribui valor às pessoas que os produzem; uma camada de tecnologia, construída com bens públicos digitais, que torna esses resultados confiáveis; e uma administradora vinculada a um propósito imutável e supervisionada externamente, que mantém os trilhos fiéis ao propósito declarado. Cada elemento já pode ser inspecionado. O próprio trabalho de formação é compartilhado por desenho — pertence aos compradores, desenvolvedores, financiadores e órgãos públicos para os quais esses trilhos foram construídos. As notas a seguir descrevem onde cada um pode começar.
**Para financiadores filantrópicos e investidores catalíticos** — A Carrot Foundation está estruturada para receber capital filantrópico e catalítico em apoio aos trilhos de propósito público: desenvolvimento de metodologias, pipeline de dMRV e governança da rede. Esse capital também pode financiar a capacidade inicial da própria Fundação — os custos administrativos e de desenvolvimento necessários para estabelecer uma instituição de propósito público antes que as taxas publicadas da rede possam sustentá-la. Os mesmos trilhos permitem que um financiador ou uma coalizão de compradores direcione compromissos antecipados baseados em resultados para resultados ambientais **e sociais** verificados — fluxos de materiais mais limpos e menos emissões, além de empregos verdes, inclusão e desenvolvimento local —, reduzindo o risco para os produtores que os entregam. A filantropia usada dessa forma é **capital de formação de mercados**: atua antes que um mercado possa se sustentar e deixa como legado trilhos abertos sobre os quais outros constroem. Financiadores que queiram examinar diretamente os trilhos, a Política de Distribuição de Recompensas ou o registry público — ou explorar o que um compromisso âncora poderia ajudar a formar — estão convidados a iniciar essa conversa com a Fundação. Para suporte, entre em contato com [fund.impact@carrot.eco](mailto:fund.impact@carrot.eco).
**Para participantes e integradores do ecossistema** — A Rede Carrot é aberta às pessoas e empresas que produzem resultados ambientais verificados — nas cadeias atuais de economia circular: Geradores de Resíduos, [Processadores](/docs/protocol/supply-chain) e [Recicladores](/docs/protocol/supply-chain#o-papel-do-reciclador) — e aos integradores que as conectam aos trilhos compartilhados. A recompensa está vinculada a resultados verificados, conforme uma tabela publicada e baseada em regras, contra a qual os participantes podem planejar e investir. Para suporte ao onboarding, os participantes podem entrar em contato com [onboard@carrot.eco](mailto:onboard@carrot.eco); para homologação de desenvolvedores de projetos e recicladores, [operations@carrot.eco](mailto:operations@carrot.eco); e, para integradores{/* Termo genérico aprovado na fonte; não é o nome canônico do papel. */} da rede, [integration@carrot.eco](mailto:integration@carrot.eco).
**Para compradores e coalizões de demanda** — Um crédito na rede é um instrumento baseado em resultados: o pagamento é liberado mediante um resultado verificado de forma independente, registrado de forma única para que não seja contado ou vendido duas vezes e liquidado com transparência — visível desde a compra até as pessoas que produziram o resultado. Os mesmos trilhos permitem que coalizões coordenem compromissos antecipados com resultados que ainda não existem, com a verificação e a liquidação já implementadas. Para suporte, entre em contato com [registry@carrot.eco](mailto:registry@carrot.eco).
**Para governos e órgãos públicos** — A infraestrutura foi construída para aliviar a carga do setor público, não substituí-lo: reduzir custos de tratamento de resíduos e fiscalização, encargos de saúde pública e remediação, liberar orçamentos municipais e apoiar empregos verdes e produtividade locais — com verificação executada pelo sistema de dMRV, dados de rastreabilidade fornecidos por Integradores e liquidação para o mercado, enquanto o Estado preserva seu mandato, sua autoridade regulatória e seu papel de garantia de última instância. Ela também pode viabilizar novas políticas baseadas em mercado: sob a **Responsabilidade Estendida do Produtor (EPR)**, por exemplo, os produtores podem cumprir obrigações financiando diretamente resultados verificados de redução de resíduos — conformidade demonstrada por resultados, não apenas por documentação. Para suporte, entre em contato com [gov.support@carrot.eco](mailto:gov.support@carrot.eco).
**Para pesquisadores e atores de políticas públicas** — Frameworks de metodologia, código de verificação e registry público de créditos são bens públicos digitais publicamente inspecionáveis. Para pesquisa e desenvolvimento de metodologias, entre em contato com [science@carrot.eco](mailto:science@carrot.eco).
**Para perguntas gerais** — [contact@carrot.eco](mailto:contact@carrot.eco).
**Páginas relacionadas:** [A Carrot Foundation](/docs/network/the-foundation) · [Governança](/docs/network/governance) · [A Rede](/docs/network) · [Política de Distribuição de Recompensas](/docs/standard/policies/rewards-distribution) · [Termos e Condições](/docs/terms/terms-and-conditions)
**Como citar:** McKee, I., & Doria, M. (2026). *Digital Public Infrastructure for Global Climate Finance — Case: Low-carbon circular economy.* Carrot Foundation White Paper v1.6.
## Recursos externos [#recursos-externos]
* Mazzucato, M., Eaves, D. & Vasconcellos, B. (2024). *Digital Public Infrastructure and Public Value: What is "public" about DPI?* UCL IIPP WP 2024-05. Revisado por pares: *Journal of Economic Policy Reform* 29(2):113–141 (2026), acesso aberto.
* Mazzucato, M. (2024). *Governing the Economics of the Common Good: from correcting market failures to shaping collective goals.* *Journal of Economic Policy Reform* 27(1):1–24, acesso aberto. [https://doi.org/10.1080/17487870.2023.2280969](https://doi.org/10.1080/17487870.2023.2280969)
* Eaves, D. & Sandman, J. (2023). *What is Digital Public Infrastructure?* Co-Develop.
* Banco Mundial / ID4D (2022). *A Digital Stack for Transforming Service Delivery: ID, Payments, and Data Sharing.*
* Ransohoff, N. (2024). *How to Start an Advance Market Commitment.* Works in Progress / Frontier.
* Renaissance Philanthropy (2024). *Commitments Playbook.*
* Symbiosis Coalition (2024). *Introducing Symbiosis.*
* International Finance Corporation (IFC) (2025). *Unlocking Social and Environmental Impact: Outcome-Based Finance in Clean Cooking, Distributed Renewable Energy, and Small-Scale Agribusiness.* Consulte também o trabalho da IFC sobre financiamento combinado como instrumento de formação de mercados para a economia circular em mercados emergentes.
* Banco Mundial (2025). *Carbon Crediting: A Results-Based Approach to Mobilizing Additional Climate Financing.* Consulte também o SCALE — Scaling Climate Action by Lowering Emissions, fundo fiduciário abrangente do Banco Mundial para financiamento climático baseado em resultados.
* WBCSD — *Global Circularity Protocol.*
* IHLEG — Independent High-Level Expert Group on Climate Finance (2025). *Delivering an integrated climate finance agenda in support of the Baku to Belém Roadmap to 1.3T.* LSE Grantham Research Institute, novembro de 2025.
* Climate Policy Initiative (2025). *Global Landscape of Climate Finance 2025.*
* UNEP (2025). *Global Methane Status Report 2025.*
* Circle Economy — *Circularity Gap Report 2021* (e edições anuais).
* ITS Rio & Lemos, R. (2025). *Digital Public Infrastructure for Climate.* Presidência da COP30.
* UNDP — *Digital Public Infrastructure* e *The Case for Nature ID.*
* *Universal DPI Safeguards Framework* (UNDP / UN ODET, 2024) — dpi-safeguards.org.
# Interoperabilidade
## Projetado para integração [#projetado-para-integração]
Os smart contracts da Rede Carrot são construídos em padrões abertos e implantados em uma blockchain pública, tornando-os inerentemente interoperáveis com sistemas externos e ferramentas padronizadas. Cada operação — desde a emissão de [MassIDs](/docs/protocol/mass-ids) até a compra de [créditos](/docs/protocol/credits) e a distribuição de recompensas — emite eventos on-chain que sistemas externos podem monitorar, indexar e verificar.
## Verificabilidade on-chain [#verificabilidade-on-chain]
Todas as transações de smart contracts da Carrot são publicamente visíveis na blockchain. Isso significa:
* **Compras e aposentadorias de créditos** podem ser verificadas de forma independente por auditores, reguladores ou qualquer parte interessada.
* **Saldos de tokens e registros de certificados** podem ser consultados em tempo real.
* **A cadeia completa de proveniência** — de MassID, passando por certificado, até crédito aposentado — é rastreável on-chain.
Como esses dados residem na blockchain pública, a transparência e a confiança não dependem da infraestrutura da Carrot. Qualquer explorador de blockchain (como [PolygonScan](https://polygonscan.com/)) ou indexador pode acessar dados brutos de transações diretamente on-chain. O [Carrot Registry](/docs/protocol/registry) adiciona uma visão focada no domínio, combinando dados on-chain com dados da plataforma (definições de metodologia, execução de regras, homologações) para contexto ambiental e rastreabilidade.
## Eventos consultáveis [#eventos-consultáveis]
Cada operação principal emite eventos estruturados que podem ser indexados por sistemas off-chain:
| Operação | Eventos principais |
| ----------------- | ---------------------------------------------------------------------------- |
| **Emissão** | MassID emitido, Certificado emitido, Créditos emitidos |
| **Compra** | Compra executada, Créditos queimados ou transferidos, Recompensas atribuídas |
| **Aposentadoria** | Créditos aposentados, Créditos queimados, Recibo de aposentadoria emitido |
| **Recompensas** | Recompensas registradas, Saques de notas de recompensa |
| **Revogação** | Token revogado |
Como toda compra é atualmente aposentada integralmente no momento da venda, uma compra emite uma queima de crédito em vez de uma transferência de entrega ao comprador. A transferência aparece apenas no caminho de aposentadoria parcial, que ainda não é usado em produção.
Esses eventos permitem que aplicações de terceiros construam dashboards, ferramentas de análise ou sistemas de relatórios de conformidade sobre dados da Carrot, sem exigir acesso direto à plataforma.
## Transferibilidade de créditos [#transferibilidade-de-créditos]
Enquanto todos os NFTs no sistema Carrot são [soulbound](/docs/protocol/credit-lifecycle) (intransferíveis), os tokens de crédito (ERC-20) são transferíveis por design. Isso significa:
* Créditos podem ser negociados em exchanges descentralizadas ou mercados OTC.
* Liquidez de mercado secundário pode se desenvolver em torno de créditos ambientais.
* Compradores podem adquirir créditos de múltiplas fontes e consolidá-los antes da aposentadoria.
Dois desvios em relação a um ERC-20 comum importam para integradores:
* **A pausa interrompe toda movimentação de saldo.** Minting, transferências e queimas param enquanto o contrato Credit está pausado, porque a verificação de pausa fica na única etapa interna pela qual toda mudança de saldo passa. Aprovações e permits continuam disponíveis.
* **A queima iniciada pelo detentor está desabilitada.** `burn` e `burnFrom` aparecem na ABI do contrato, mas revertem para qualquer chamador que não seja o [Vault](/docs/protocol/smart-contracts) ou o CreditRetirementManager, de modo que a [aposentadoria](/docs/protocol/credit-retirement) é o único caminho que destrói créditos.
Essa fungibilidade e transferibilidade tornam os créditos Carrot composáveis com o ecossistema mais amplo de finanças descentralizadas (DeFi), mantendo total rastreabilidade até o trabalho de reciclagem verificado.
## Descoberta de contratos baseada em registro [#descoberta-de-contratos-baseada-em-registro]
A arquitetura de smart contracts utiliza um [ContractRegistry](/docs/protocol/smart-contracts/contract-categories) que mapeia nomes lógicos para endereços implantados. Esse design permite:
* **Atualizações contínuas** — Os contratos utilizam o padrão de proxy UUPS (EIP-1967), de modo que o endereço do proxy permanece estável entre atualizações. Quando o proxy é atualizado (`upgradeToAndCall`), o endereço do proxy e sua entrada no ContractRegistry permanecem os mesmos, então todos os contratos dependentes continuam operando sem reimplantação. A chamada de atualização pode carregar calldata de migração, que a nova implementação executa sobre o armazenamento já existente do proxy.
* **Acoplamento fraco** — Os contratos não codificam endereços de suas dependências diretamente, tornando o sistema mais resiliente e fácil de evoluir.
## Rede de implantação [#rede-de-implantação]
A Rede Carrot é agnóstica em relação à rede blockchain: os smart contracts são implementados em Solidity e podem ser implantados em qualquer rede compatível com EVM. Atualmente, a Carrot implanta na [Polygon PoS](https://polygon.technology/) pelos seguintes motivos:
* **Baixo custo de transação** — Operações com créditos ambientais (emissão, compra, aposentadoria) podem ser executadas de forma acessível em escala.
* **Compatibilidade EVM** — Compatibilidade total com ferramentas, carteiras e ecossistema de desenvolvedores Ethereum.
* **Ecossistema estabelecido** — Amplo suporte de indexadores, exploradores e protocolos DeFi.
A produção roda na mainnet Polygon PoS (chain ID 137, [polygonscan.com](https://polygonscan.com/)). Ambientes que não são de produção rodam na testnet Polygon Amoy (chain ID 80002, [amoy.polygonscan.com](https://amoy.polygonscan.com/)), então uma integração apontada para um ambiente que não seja de produção deve indexar a Amoy, e não a mainnet.
[Saiba mais sobre smart contracts](/docs/protocol/smart-contracts) · [Saiba mais sobre categorias de contratos](/docs/protocol/smart-contracts/contract-categories) · [Acesse o Carrot Registry](https://registry.carrot.eco)
# Metadata Viewer
## O que é o Metadata Viewer [#o-que-é-o-metadata-viewer]
Os tipos de registro que a [Rede Carrot](/docs/network) escreve um a um no [registry](/docs/registry) público — um [MassID](/docs/protocol/mass-ids), um [Certificado](/docs/protocol/certificates), um Recibo de Compra de Crédito ou um Recibo de [Aposentadoria de Crédito](/docs/protocol/credit-retirement) — carregam cada um um documento de proveniência endereçado por conteúdo e armazenado no [IPFS](https://ipfs.tech/). A entrada on-chain guarda a referência, não o conteúdo de proveniência. Ela não é vazia de dados — um Certificado acompanha na cadeia seus montantes total, comprado, aposentado e disponível, e um recibo registra as partes, os montantes e as alocações de certificado —, mas a cadeia de custódia por trás do registro é o que vive no IPFS. Tokens de [crédito](/docs/protocol/credits) fungíveis também são registros do registry, mas não carregam documento de proveniência próprio e o viewer não os abre.
O Metadata Viewer ([viewer.carrot.eco](https://viewer.carrot.eco)) é a ferramenta que segue essa referência e renderiza o documento por trás dela. Ele lê a URI de metadados do token diretamente do [smart contract](/docs/protocol/smart-contracts), busca o documento no IPFS e o confere contra o schema que o próprio registro declara — tudo no navegador de quem está lendo.
Ele responde uma pergunta mais estreita que a do [Carrot Registry](/docs/protocol/registry): não "o que este registro significa em contexto", e sim "o que exatamente este registro diz, e ele concorda com a cadeia". Ele não é, por si só, prova de que um registro está íntegro — [o que ele confere](#o-que-o-viewer-confere) é mais estreito que isso, e a diferença está detalhada abaixo.
## Como abrir um registro [#como-abrir-um-registro]
O viewer lê sua entrada a partir da URL, então qualquer registro pode ser linkado diretamente. Na maioria das vezes quem lê chega por um link já gerado pela plataforma (veja [Onde esses links aparecem](#onde-esses-links-aparecem)); o contrato da URL está documentado aqui para que um registro também possa ser aberto à mão.
**Por endereço de contrato.** A forma canônica. Um registro é endereçado pela tripla endereço do contrato, rede e identificador do token:
```text
https://viewer.carrot.eco/?contractAddress=0x&network=polygon&tokenId=
```
`network` aceita `polygon` para a mainnet pública da [Polygon](https://polygon.technology/) (chain ID 137) e `amoy` para a rede de testes Polygon Amoy (chain ID 80002). O host é o mesmo nas duas — o viewer escolhe a rede por esse parâmetro, e endereços e identificadores de token são locais a cada cadeia, então `network` precisa nomear a cadeia em que o registro foi escrito.
**Por tipo de registro.** Na mainnet, o viewer consegue resolver o endereço do contrato sozinho, através do [ContractRegistry](/docs/protocol/smart-contracts) on-chain, então um tipo de registro substitui o endereço:
```text
https://viewer.carrot.eco/?recordType=mass-id&network=polygon&tokenId=
```
| `recordType` | Registro |
| --------------------------- | ---------------------------------------------- |
| `mass-id` | Um lote verificado de material residual |
| `recycled-id` | Prova de que o material foi reciclado |
| `gas-id` | Reduções de emissões de gases de efeito estufa |
| `credit-purchase-receipt` | Prova de que créditos foram comprados |
| `credit-retirement-receipt` | Prova de que créditos foram aposentados |
**Por referência IPFS.** Um documento de proveniência também pode ser aberto diretamente pelo seu identificador de conteúdo, sem saber qual contrato o guarda:
```text
https://viewer.carrot.eco/?cid=
```
Isso ainda lê a cadeia: o registro nomeia o próprio contrato e token, e a conferência de ida e volta descrita abaixo relê esse contrato para confirmar que o documento bate. O que o identificador poupa é ter que saber o endereço.
O viewer também aceita um documento colado ou enviado da máquina de quem está lendo, e é isso que dá sentido a essa ida e volta: dá para saber se um documento que chegou até você é o mesmo que o contrato e o token do próprio registro resolvem.
## Onde esses links aparecem [#onde-esses-links-aparecem]
Links do viewer são gerados sempre que um registro é apresentado como evidência:
* **O Certificado de Impacto** — o PDF emitido para uma compra de créditos — lista os registros públicos daquele pedido na seção **Registros públicos**, cada um deles um link para o viewer: o recibo de compra e, quando o pedido foi aposentado na mesma transação, o recibo de aposentadoria. Um pedido aposentado depois, em transação separada, gera o recibo de aposentadoria após a emissão do PDF.
* **Registros de certificado** carregam um link do viewer para a sua própria entrada no registry, ao lado do link do [explorador de blockchain](/docs/glossary#blockchain-block-explorer) para o mesmo token.
Um Certificado de Impacto emitido é um documento fixo: os links impressos nele são escritos no momento da emissão e nunca são reescritos, então cada um continua apontando para o registro para o qual foi emitido.
## O que o registro fixa [#o-que-o-registro-fixa]
As âncoras de integridade do registro fazem parte do seu formato e existem independentemente de qualquer ferramenta lê-las:
* **O schema, fixado de três formas** — uma URL com a versão, uma referência IPFS para esse schema e o hash SHA-256 da versão exata contra a qual o registro foi escrito. Os schemas de registro da Carrot são open source em [carrot-foundation/schemas](https://github.com/carrot-foundation/schemas).
* **Um hash de auditoria** — um hash SHA-256 gravado no momento da emissão, para que quem tenha os dados de origem — enviados pelos [Integradores](/docs/protocol/network-integrators) — possa reconciliá-los com o registro publicado. Quem lê o registro público não consegue recalculá-lo apenas a partir dele, porque o documento publicado é tarjado (veja abaixo).
* **Uma referência ao build do viewer** — veja a seção final desta página.
## O que o viewer confere [#o-que-o-viewer-confere]
Três conferências rodam, e cada uma reporta o seu próprio status. Elas são mais estreitas que as âncoras acima, e a diferença importa se você depende delas:
* **Estrutura** — O documento é validado contra a cópia do schema fixada no build do viewer, casada pela URL de schema que o registro declara. Quando um registro declara uma versão que o build não carrega, o viewer reporta **não conferido estruturalmente** em vez de validar, e campos introduzidos depois daquele build não são renderizados.
* **Ida e volta on-chain** — Quando um documento é aberto pela referência IPFS, ou colado ou enviado, o viewer relê a URI de metadados do contrato e do token que o próprio registro nomeia e exige que ela resolva para o mesmo documento: **verified** ou **mismatch**. É a conferência mais forte que o viewer faz. Ela não roda quando o registro é aberto por endereço de contrato, porque nesse caso o documento veio daquele contrato desde o início.
* **Rede** — A rede embutida no registro precisa ser uma das duas cadeias suportadas; caso contrário o registro é rejeitado.
O viewer não recalcula nenhum dos hashes do registro, e não verifica se os bytes devolvidos por um gateway realmente correspondem ao identificador de conteúdo solicitado. O endereçamento por conteúdo torna essa conferência possível — qualquer alteração no documento produz um identificador diferente — mas ela é feita por quem lê, buscando o identificador através de um cliente que valida endereçamento por conteúdo, ou fixando o documento novamente no IPFS e comparando os identificadores.
Documentos de proveniência são públicos, então atributos pessoais e comercialmente sensíveis são [omitidos ou mascarados](/docs/integrations/guides/privacy-and-masking) antes da publicação: um atributo marcado como privado fica de fora do documento publicado por completo, e um que continua público mas é sinalizado como sensível é publicado mascarado, com o valor completo preservado para auditores. O que o viewer renderiza é o registro publicado — a cadeia de custódia como ela foi liberada para publicação. A visibilidade é definida por evento, além de por atributo, então um evento marcado como privado fica ausente do documento por completo; o que você está lendo não é necessariamente o histórico operacional completo que um auditor vê.
## O viewer também é verificável [#o-viewer-também-é-verificável]
Uma ferramenta de verificação pela qual só o autor pode responder desloca o problema de confiança em vez de resolvê-lo. Todo registro de proveniência da Carrot embute uma referência IPFS para o próprio build do viewer, de modo que a ferramenta que lê o registro fica fixada por endereço de conteúdo, exatamente como o documento que ela lê. Quem não quiser confiar na cópia servida em `viewer.carrot.eco` pode executar o build referenciado.
## Onde ele se encaixa [#onde-ele-se-encaixa]
Três superfícies apresentam os mesmos fatos em profundidades diferentes:
| Superfície | O que mostra | Lê de |
| ----------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | ---------------------- |
| **Carrot Registry** | Registros em contexto ambiental — metodologias, resultados de verificação, credenciamentos, ciclo de vida dos créditos | A plataforma da Carrot |
| **Metadata Viewer** | O documento de proveniência por trás de um registro, conferido contra o schema que o registro declara | A cadeia e o IPFS |
| **Explorador de blockchain** (ex.: PolygonScan) | Transações on-chain brutas, chamadas de contrato e logs de eventos | A cadeia |
O Registry é onde quem lê começa, partindo de uma pergunta sobre impacto. O Metadata Viewer é onde essa pessoa chega quando a pergunta passa a ser se um registro específico se sustenta por conta própria.
[Saiba mais sobre o Carrot Registry](/docs/protocol/registry) · [Saiba mais sobre a criação de registros no registry](/docs/protocol/on-chain-minting)
# Certificados
## O que são certificados? [#o-que-são-certificados]
Certificados são a camada intermediária do [ciclo de vida dos créditos](/docs/protocol/credit-lifecycle) da Rede Carrot — eles ficam entre os [MassIDs](/docs/protocol/mass-ids) (que rastreiam resíduos físicos) e os [Créditos](/docs/protocol/credits) (que são comprados e vendidos no mercado). Um certificado representa um único MassID que passou pela verificação de metodologia, comprovando uma quantidade específica de reciclagem ou reduções de emissões. No registry público de créditos, cada certificado é um registro permanente e intransferível mantido pelo [Vault](/docs/protocol/smart-contracts); quando é emitido, uma quantidade equivalente de créditos fungíveis é criada automaticamente (1 crédito = 1 tonelada métrica).
Isso garante que cada crédito em circulação seja respaldado por um certificado verificado, que por sua vez é respaldado por um MassID verificado.
## Tipos de certificados [#tipos-de-certificados]
A Rede Carrot emite tipos de certificados vinculados a metodologias. Cada metodologia define qual tipo de certificado emite e qual símbolo de crédito é gerado:
| Certificado | Crédito gerado (exemplo) | Emitido por | O que verifica |
| -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| **RecycledID** | `C-BIOW` ([TRC](/docs/protocol/credits#tokenized-recycling-credits-trc)) quando emitido sob [BOLD Recycling](/docs/methodologies/bold-recycling) | Metodologias de reciclagem | Que uma quantidade específica de material residual foi certificada como reciclada em uma instalação credenciada |
| **GasID** | `C-CARB.CH4` ([TCC](/docs/protocol/credits#tokenized-carbon-credits-tcc)) quando emitido sob [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) | Metodologias de carbono | Que uma quantidade específica de emissões de gases de efeito estufa (CO₂e) foi reduzida por meio do desvio de resíduos ou tratamento biológico |
Outras metodologias podem emitir símbolos de crédito diferentes para seus certificados.
### RecycledID [#recycledid]
Um certificado RecycledID é emitido quando um MassID de um tipo específico de resíduo chega a um [Reciclador credenciado](/docs/protocol/supply-chain#o-papel-do-reciclador), passa pela verificação de Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)) — a mesma infraestrutura que sustenta tanto créditos de reciclagem quanto créditos de carbono — e satisfaz todas as regras definidas por uma metodologia de reciclagem ativa. O certificado registra o peso do material reciclado certificado e referencia o MassID subjacente que comprova a proveniência. Sob a metodologia [BOLD Recycling](/docs/methodologies/bold-recycling), cada RecycledID gera uma quantidade correspondente de créditos `C-BIOW`; outras metodologias de reciclagem podem emitir símbolos de crédito diferentes.
### GasID [#gasid]
Um certificado GasID quantifica as **reduções de emissões** de gases de efeito estufa alcançadas pelo desvio de resíduos ou tratamento biológico em vez da disposição em aterro sanitário ou lixão. GasIDs são gerados diretamente de MassIDs por uma metodologia de carbono: as reduções de emissões são calculadas comparando o cenário de desvio ou tratamento com o cenário de disposição de referência.
O cálculo central é: **Reduções de Emissões = Emissões de Linha de Base − Emissões Reais**. Sob a metodologia [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon), cada GasID gera uma quantidade correspondente de créditos `C-CARB.CH4` (reduções de metano); outras metodologias de carbono podem emitir símbolos de crédito diferentes.
Reduções de Emissões = Emissões de Linha de Base − Emissões Reais
* **Emissões de Linha de Base (BE)** — As emissões de GEE que teriam ocorrido se os resíduos fossem enviados a um aterro sanitário ou lixão (ex.: metano proveniente da decomposição de resíduos orgânicos ao longo do período de degradação modelado).
* **Emissões Reais (RE)** — As emissões de GEE que ocorreram durante o processo de reciclagem ou [tratamento biológico](/docs/glossary#biological-treatment).
A diferença representa o benefício ambiental da reciclagem, medido em toneladas métricas de CO₂-equivalente.
Para resíduos biológicos (resíduos alimentares, resíduos verdes), os cálculos de GasID exigem complexidade adicional porque a compostagem envolve a mistura de diferentes tipos de resíduos. Uma instalação de compostagem opera com uma proporção de mistura específica — por exemplo, 60% de resíduos alimentares e 40% de resíduos verdes.
Para calcular as reduções de emissões pela compostagem:
1. Os MassIDs de cada tipo de resíduo são combinados de acordo com a proporção de mistura verificada da instalação.
2. As emissões de linha de base são calculadas usando a metodologia [UNFCCC CDM Tool 04](https://cdm.unfccc.int/methodologies/PAmethodologies/tools/am-tool-04-v8.0.pdf) para emissões de locais de disposição de resíduos sólidos.
3. As emissões reais da compostagem são calculadas usando [UNFCCC CDM Tool 13](https://cdm.unfccc.int/methodologies/PAmethodologies/tools/am-tool-13-v2.pdf) para emissões do projeto e de vazamento provenientes da compostagem.
O resultado demonstra o impacto ambiental: a compostagem de 1 tonelada de resíduos alimentares misturada com 1 tonelada de resíduos verdes pode entregar mais de 2 toneladas de CO₂e em reduções de emissões em comparação com a disposição em aterro sanitário sem captura de metano.
## Como os certificados são criados [#como-os-certificados-são-criados]
O ciclo de vida do certificado segue uma sequência clara:
1. **MassIDs se acumulam** — À medida que os resíduos percorrem a [cadeia de custódia](/docs/protocol/supply-chain), MassIDs são criados e validados em cada ponto de transferência.
2. **A verificação de metodologia é aprovada** — Quando os MassIDs satisfazem todas as regras definidas por uma metodologia específica — seja uma metodologia de reciclagem (produzindo um RecycledID) ou uma metodologia de carbono (produzindo um GasID) — os MassIDs tornam-se elegíveis para certificação.
3. **Certificados são criados** — O Inventory Manager registra cada certificado e o vincula ao seu MassID de origem por meio do `CertificateRegistry`. A plataforma registra o evento de emissão, sincronizando o certificado com seu MassID de respaldo, tipo de crédito, quantidade e contexto de metodologia.
4. **Créditos são gerados** — Ao mesmo tempo, créditos fungíveis são emitidos em uma quantidade equivalente ao certificado e depositados no Vault como inventário disponível para compras de crédito.
## Rastreamento de certificados [#rastreamento-de-certificados]
Cada certificado rastreia seu saldo disponível à medida que os créditos são comprados e aposentados:
* **Quantidade total** — Definida na emissão, imutável. O impacto ambiental total que este certificado representa.
* **Quantidade comprada** — Incrementada quando créditos respaldados por este certificado são comprados.
* **Quantidade aposentada** — Incrementada quando créditos comprados são permanentemente aposentados.
* **Quantidade disponível** — Total menos comprada. Os créditos ainda disponíveis para venda.
Esse rastreamento garante que cada compra e aposentadoria de crédito possa ser rastreada até um certificado específico e, por meio desse certificado, até o MassID subjacente e o trabalho físico de reciclagem.
[Saiba mais sobre créditos](/docs/protocol/credits) · [Saiba mais sobre o ciclo de vida dos créditos](/docs/protocol/credit-lifecycle)
### Diagram: certificate-creation-flow
Este fluxo de criação de certificados começa com MassIDs acumulados, passa pela verificação dMRV e então se divide dentro do Vault. O material verificado gera RecycledID no ramo de reciclagem e GasID no ramo de emissões; esses certificados sustentam a emissão de créditos TRC e TCC como saídas separadas da mesma base de evidências.
# Ciclo de Vida dos Créditos
## De resíduo físico a créditos negociáveis [#de-resíduo-físico-a-créditos-negociáveis]
A Rede Carrot transforma trabalho de reciclagem verificado em ativos ambientais por meio de uma estrutura em camadas do registry público de créditos. Cada camada se baseia na anterior, criando uma cadeia de evidências inquebrável desde o resíduo físico até os créditos disponíveis para compra.
A hierarquia possui cinco camadas:
1. **[MassID](/docs/protocol/mass-ids)** — Um lote verificado de resíduos (tipo de material, peso, cadeia de custódia do [Gerador de Resíduos](/docs/protocol/supply-chain) ao [Reciclador](/docs/protocol/supply-chain#o-papel-do-reciclador)). Implementado como um registro permanente e intransferível no Registry.
2. **[Certificado](/docs/protocol/certificates)** ([GasID](/docs/protocol/certificates#gasid) ou [RecycledID](/docs/protocol/certificates#recycledid)) — Representa um resultado ambiental verificado quando os MassIDs passam pela verificação de [metodologia](/docs/methodologies) em uma instalação credenciada. Implementado como um registro permanente e intransferível no Registry.
3. **[Crédito](/docs/protocol/credits)** — Uma unidade negociável de impacto ambiental verificado em que 1 crédito = 1 tonelada métrica. Emitido automaticamente quando os certificados são criados, em quantidade equivalente. Cada metodologia emite créditos sob seu próprio símbolo de crédito (ex.: [BOLD Recycling](/docs/methodologies/bold-recycling) emite `C-BIOW`, [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) emite `C-CARB.CH4` para metano). Implementado como uma unidade digital fungível — emitida e transacionada em qualquer quantidade, incluindo frações.
4. **`CreditPurchaseReceipt`** — Um recibo permanente e intransferível registrado quando créditos são [comprados](/docs/protocol/credit-purchase). Fornece prova auditável de que a transação ocorreu.
5. **`CreditRetirementReceipt`** — Um recibo permanente e intransferível registrado quando créditos são [aposentados](/docs/protocol/credit-retirement). Fornece prova permanente de que a compensação ambiental foi reivindicada.
## Como as camadas se conectam [#como-as-camadas-se-conectam]
Cada camada da hierarquia faz referência à camada abaixo dela, criando rastreabilidade completa:
| Camada | Objeto do Registry | Modelo público | Detalhe de implementação | Transferível? | O que comprova |
| ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------- | ------------------------ | ------------- | ---------------------------------------------------- |
| Rastreamento | MassID | Registro permanente | ERC-721 | Não | Resíduo físico foi coletado, triado e transportado |
| Certificação | [GasID](/docs/protocol/certificates#gasid) / [RecycledID](/docs/protocol/certificates#recycledid) | Registro permanente | ERC-721 | Não | Impacto ambiental foi verificado por dMRV |
| Emissão de crédito | [TRC](/docs/protocol/credits#tokenized-recycling-credits-trc) / [TCC](/docs/protocol/credits#tokenized-carbon-credits-tcc) (ex.: `C-BIOW`, `C-CARB.CH4`) | Crédito fungível | ERC-20 | Sim | 1 crédito = 1 tonelada métrica de impacto verificado |
| Compra | `CreditPurchaseReceipt` | Registro permanente | ERC-721 | Não | Créditos foram comprados com pagamento em USDC |
| Aposentadoria | `CreditRetirementReceipt` | Registro permanente | ERC-721 | Não | Créditos foram destruídos e reivindicados |
Todos esses registros ficam no registry público de créditos.
## Por que os registros são intransferíveis? [#por-que-os-registros-são-intransferíveis]
Todos os MassIDs, certificados e recibos no Registry são intransferíveis — eles não podem ser movidos entre contas. Esta é uma escolha de design deliberada:
* **Trilha de auditoria à prova de adulteração** — Como os registros não podem ser movidos, a cadeia de proveniência do resíduo ao crédito é permanente e verificável.
* **Sem negociação especulativa** — MassIDs e certificados representam trabalho físico verificado, não ativos especulativos. Impedir transferências garante que permaneçam vinculados ao seu contexto original.
* **Custódia via [Vault](/docs/protocol/smart-contracts)** — Todos os registros intransferíveis são mantidos pelo Vault, que gerencia a custódia em nome da rede.
Apenas os créditos são transferíveis, pois são a camada projetada para atividade de mercado — compra, manutenção e aposentadoria de compensações ambientais.
## Dois caminhos de crédito [#dois-caminhos-de-crédito]
O ciclo de vida dos créditos produz dois tipos de crédito independentes, cada um representando um resultado ambiental diferente. Cada caminho é conduzido por um framework de metodologia diferente que processa MassIDs de forma independente:
### Caminho de reciclagem [#caminho-de-reciclagem]
MassID → RecycledID → [Tokenized Recycling Credit (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc)
Comprova que o material de resíduo foi fisicamente reciclado. Os Tokenized Recycling Credits (TRC) utilizam uma unidade de 1 tonelada métrica de material reciclado certificado e são emitidos proporcionalmente à quantidade verificada de cada certificado. A metodologia BOLD Recycling emite TRCs com o símbolo de crédito `C-BIOW`; outras metodologias de reciclagem podem usar símbolos diferentes. Os TRCs são específicos por material — cada TRC representa um fluxo de material certificado.
### Caminho de carbono [#caminho-de-carbono]
MassID → GasID → [Tokenized Carbon Credit (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc)
Comprova que emissões de gases de efeito estufa foram reduzidas ao reciclar em vez de descartar em aterros. Os Tokenized Carbon Credits (TCC) utilizam uma unidade de 1 tonelada métrica de CO₂-equivalente em reduções de emissões e são emitidos proporcionalmente à quantidade verificada de cada certificado GasID. A metodologia BOLD Carbon (CH₄) emite TCCs com o símbolo de crédito `C-CARB.CH4` (metano); outras metodologias de carbono podem usar símbolos diferentes. Uma metodologia de carbono calcula a diferença de emissões entre o cenário de reciclagem e o cenário de linha de base de aterro diretamente a partir dos dados do MassID.
O mesmo MassID pode embasar tanto um RecycledID quanto um GasID, já que cada certificado é emitido por um framework de metodologia independente — uma metodologia de reciclagem verifica o resultado físico da reciclagem, enquanto uma metodologia de carbono quantifica as reduções de emissões.
## Rastreabilidade de ponta a ponta [#rastreabilidade-de-ponta-a-ponta]
O ciclo de vida dos créditos permite rastreabilidade completa desde o crédito aposentado até o resíduo físico:
**Aposentadoria de crédito** → `CreditRetirementReceipt` → Crédito (ex.: `C-BIOW`, `C-CARB.CH4`) → Certificado (RecycledID ou GasID) → MassID → Lote de resíduo físico com cadeia de custódia
Essa rastreabilidade é publicamente verificável por meio do [Carrot Registry](/docs/protocol/registry) e de qualquer explorador de blockchain como o [PolygonScan](https://polygonscan.com/). Qualquer auditor, regulador ou parte interessada pode rastrear um crédito aposentado em todas as camadas até os lotes específicos de resíduos e os participantes da reciclagem que o produziram.
[Saiba mais sobre certificados](/docs/protocol/certificates) · [Saiba mais sobre créditos](/docs/protocol/credits) · [Saiba mais sobre compra](/docs/protocol/credit-purchase) · [Saiba mais sobre aposentadoria](/docs/protocol/credit-retirement)
# Compra de Créditos
## O comprador de créditos [#o-comprador-de-créditos]
A Rede Carrot é um mercado orientado pela demanda — a maior parte do valor vem dos compradores de créditos. Os compradores de créditos são tipicamente organizações — produtores, fabricantes, importadores, distribuidores e seus representantes (como Organizações de Responsabilidade do Produtor) — mas indivíduos também podem comprar créditos para compensar pegadas de resíduos e carbono.
Os compradores de créditos adquirem [Tokenized Recycling Credits (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc) e [Tokenized Carbon Credits (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc) para:
* **Cumprir compromissos ESG** — Demonstrar ações ambientais verificáveis para funcionários, clientes, acionistas e reguladores.
* **Atender mandatos de EPR** — Leis de Responsabilidade Estendida do Produtor exigem cada vez mais que produtores financiem a recuperação e reciclagem de seus produtos e embalagens.
* **Compensar pegadas de carbono** — Aposentar créditos de carbono para reivindicar permanentemente as reduções de emissões de gases de efeito estufa alcançadas por meio da reciclagem.
## O fluxo de compra [#o-fluxo-de-compra]
Os créditos são comprados **apenas por meio de interfaces Carrot** — compradores não compram diretamente no Registry. Quando um comprador utiliza uma interface Carrot (ex.: a [Loja Carrot](https://store.carrot.eco) para indivíduos, ou interfaces fornecidas pela Carrot para organizações), a plataforma executa o seguinte fluxo de liquidação atômica:
| Etapa | Ação | Descrição |
| ----- | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1 | **Ordem de compra assinada** | A ordem de compra é assinada com uma assinatura de dados tipados EIP-712 por uma chave operada pela Carrot e registrada no contrato `CreditPurchaseManager` como signatário autorizado. O comprador autoriza a compra pela interface da Carrot e pelo provedor de pagamento — o comprador não assina a ordem on-chain. |
| 2 | **Pagamento transferido** | USDC é transferido do pagador para o smart contract `RewardsVault`, onde fica disponível para distribuição de recompensas aos participantes. |
| 3 | **Certificado atualizado** | Os valores comprados são registrados nos certificados correspondentes, reduzindo o inventário disponível para cada certificado alocado. |
| 4 | **Créditos liquidados** | Créditos (ex.: `C-BIOW`, `C-CARB.CH4`) são queimados diretamente do Vault na parcela aposentada do pedido — eles nunca passam pela conta do comprador. Qualquer remanescente não aposentado é transferido do Vault para a conta do comprador. |
| 5 | **Recibo registrado** | Um Recibo de Compra de Crédito é registrado como prova pública e auditável da transação de compra. |
| 6 | **Recompensas registradas** | Um Merkle root é registrado on-chain para a distribuição de recompensas, permitindo que os participantes reivindiquem sua parte. |
A entrega depende de inventário verificado. Se ainda não houver [certificados](/docs/protocol/certificates) correspondentes para o pedido completo, a compra pode ser aceita e mantida para entrega diferida — a plataforma reavalia automaticamente e executa a transação de liquidação assim que houver inventário. Um pedido é entregue integralmente; uma compra não é atendida parcialmente.
Saiba mais sobre a [distribuição de recompensas](/docs/protocol/rewards-distribution).
Uma vez liquidada, cada compra e seus recibos são publicamente verificáveis por meio do [Carrot Registry](/docs/protocol/registry) ou de qualquer explorador de blockchain (ex.: [PolygonScan](https://polygonscan.com/)).
## Alocação de certificados [#alocação-de-certificados]
Todo crédito é respaldado por um certificado — seja um RecycledID (para créditos de reciclagem) ou um GasID (para créditos de carbono). Quando uma compra é criada, a plataforma aloca certificados do inventário disponível para atender o pedido. Os certificados são alocados de modo a distribuir cada venda entre o maior número possível de participantes distintos nas recompensas — cada rodada de alocação avança o certificado cujos participantes receberam menos até então, em faixas de valor. A idade do certificado serve apenas como critério de desempate e para varrer o remanescente.
Uma única compra pode abranger múltiplos certificados caso nenhum certificado individual tenha saldo disponível suficiente para preencher o pedido. O recibo de compra registra cada alocação de certificado, mantendo uma trilha de auditoria clara dos créditos comprados até o trabalho de reciclagem verificado e os [MassIDs](/docs/protocol/mass-ids) subjacentes.
## Aposentadoria integrada [#aposentadoria-integrada]
Compradores podem adquirir e aposentar créditos em uma **única transação atômica**. Onde a ordem de compra carrega uma quantidade de aposentadoria positiva para uma alocação, aquela parcela é comprada e imediatamente destruída na mesma operação do Registry. Tanto um **Recibo de Compra de Crédito** quanto um **Recibo de Aposentadoria de Crédito** são registrados na mesma transação.
Este é o caminho mais comum para compradores de compliance — organizações e indivíduos que precisam reivindicar a compensação ambiental imediatamente após a compra. Simplifica o processo em uma única etapa e reduz os custos de transação.
Os contratos do registry também suportam a aposentadoria standalone como uma transação separada, para compradores que mantêm créditos e os aposentam posteriormente. Veja [Aposentadoria de Créditos](/docs/protocol/credit-retirement) para detalhes sobre ambos os caminhos de aposentadoria.
## Métodos de pagamento em moeda fiduciária [#métodos-de-pagamento-em-moeda-fiduciária]
A Rede Carrot reconhece que muitos compradores de créditos não possuem infraestrutura blockchain. Para resolver isso, a plataforma suporta **métodos de pagamento em moeda fiduciária** para compradores que preferem fluxos de pagamento tradicionais. Os métodos disponíveis dependem da região do comprador e são exibidos no checkout, e esse conjunto se amplia conforme novos meios de pagamento são adicionados. A plataforma realiza a conversão para que a liquidação sempre ocorra em USDC, independentemente de como o comprador paga.
***
[Créditos](/docs/protocol/credits) · [Distribuição de Recompensas](/docs/protocol/rewards-distribution) · [Smart Contracts](/docs/protocol/smart-contracts) · [Aposentadoria de Créditos](/docs/protocol/credit-retirement)
### Diagram: credit-purchase-flow
Este fluxo de compra agrupa o comprador, a camada de liquidação automatizada do registry e seus registros públicos em uma transação de seis etapas: ordem assinada, USDC transferido, certificado atualizado, créditos liquidados, recibo registrado e recompensas registradas. A anotação de transação atômica resume a mensagem: a compra conclui todas as mudanças de estado em conjunto ou reverte sem liquidação parcial.
# Aposentadoria de Créditos
## O que é aposentadoria de créditos? [#o-que-é-aposentadoria-de-créditos]
A aposentadoria de créditos é o ato de remover permanentemente créditos ambientais de circulação para reivindicar a compensação que eles representam. Quando um [Tokenized Recycling Credit (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc) ou [Tokenized Carbon Credit (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc) é aposentado, o crédito é destruído permanentemente no registry público de créditos e nunca pode ser revendido, reutilizado ou contabilizado duplamente.
A aposentadoria é o que transforma um ativo financeiro negociável em uma reivindicação ambiental permanente. Até que os créditos sejam aposentados, eles representam inventário disponível. Após a aposentadoria, eles representam impacto reivindicado — registrado permanentemente no registry público de créditos imutável e visualizável por meio do [Carrot Registry](/docs/protocol/registry) ou de qualquer explorador on-chain público.
## Dois caminhos de aposentadoria [#dois-caminhos-de-aposentadoria]
A Rede Carrot suporta dois métodos para aposentar créditos:
### Aposentadoria standalone [#aposentadoria-standalone]
Os contratos do registry suportam aposentar créditos mantidos contra o saldo de um comprador a qualquer momento após a compra — útil para compradores que adquirem créditos antecipadamente e os aposentam de acordo com seus próprios cronogramas de relatórios.
1. O detentor solicita a aposentadoria por meio de uma interface da Carrot. A ordem de aposentadoria — que nomeia os [certificados](/docs/protocol/certificates) e as quantidades a aposentar — é assinada por uma chave registrada nos contratos do registry como signatário autorizado, e qualquer relayer pode então submetê-la. A autorização vem dessa assinatura, não da carteira do próprio detentor.
2. Os créditos são destruídos permanentemente a partir do saldo sob custódia do [Vault](/docs/protocol/smart-contracts), contra o direito registrado do detentor. Créditos já entregues a uma conta externa precisam ser devolvidos ao Vault antes.
3. O valor de aposentadoria do certificado correspondente é atualizado.
4. Um **Recibo de Aposentadoria de Crédito** é registrado como prova permanente.
5. A aposentadoria é registrada no registry público de créditos.
### Aposentadoria integrada [#aposentadoria-integrada]
Os créditos são comprados e aposentados em uma única transação atômica. Este é o caminho mais comum para compradores que sabem que desejam reivindicar a compensação imediatamente após a compra.
1. Uma [ordem de compra](/docs/protocol/credit-purchase) é assinada por uma chave registrada nos contratos do registry como signatário autorizado. A ordem carrega uma quantidade de aposentadoria para cada alocação de certificado, além dos metadados de aposentadoria (beneficiário, id do recibo, URI dos metadados). São as quantidades que determinam se há aposentadoria e de quanto: onde são positivas, aquela parcela é queimada e o recibo de aposentadoria é registrado; os metadados identificam esse recibo.
2. O pagamento em USDC é transferido para o `RewardsVault` para [distribuição de recompensas](/docs/protocol/rewards-distribution).
3. **Os créditos são destruídos** diretamente no Vault — eles nunca passam pela conta do comprador. Quando apenas parte de uma compra é aposentada, o remanescente é transferido do Vault para o comprador.
4. Tanto um **Recibo de Compra de Crédito** quanto um **Recibo de Aposentadoria de Crédito** são registrados na mesma transação.
5. A aposentadoria é registrada no registry público de créditos.
A aposentadoria integrada é o caminho recomendado para a maioria dos compradores, pois simplifica o processo e reduz o número de transações.
## O recibo de aposentadoria [#o-recibo-de-aposentadoria]
Toda aposentadoria produz um **`CreditRetirementReceipt`** — um registro permanente e intransferível que serve como prova pública. O recibo registra:
* **Tipo de crédito** — Se TRC (ex.: `C-BIOW`) ou TCC (ex.: `C-CARB.CH4`) foi aposentado
* **Quantidade** — A quantidade de créditos aposentados (em toneladas métricas)
* **Detentor do crédito** — O endereço da conta contra a qual os créditos aposentados estavam registrados
* **Beneficiário** — O identificador da parte para a qual a aposentadoria é reivindicada, que pode ser o próprio detentor ou alguém que ele designe
* **Timestamp** — O timestamp do bloco quando a aposentadoria ocorreu
* **Referências de certificados** — Links para os certificados correspondentes ([GasID](/docs/protocol/certificates#gasid) ou [RecycledID](/docs/protocol/certificates#recycledid))
* **Referências de [MassID](/docs/protocol/mass-ids)** — Links para os lotes de resíduos subjacentes
Por ser intransferível, o recibo não pode ser movido. Ele é mantido permanentemente pelo Vault e permanece associado publicamente ao endereço da conta do detentor do crédito e ao identificador do beneficiário — e a aposentadoria que ele registra, os créditos queimados e os certificados por trás deles não podem ser desfeitos.
## Por que a aposentadoria importa [#por-que-a-aposentadoria-importa]
A aposentadoria resolve um problema crítico nos mercados ambientais: **dupla contagem**. Nos mercados tradicionais de compensação de carbono e reciclagem, o mesmo crédito pode ser vendido múltiplas vezes ou reivindicado por múltiplas partes porque não existe um mecanismo definitivo para marcar um crédito como utilizado.
Na Rede Carrot, a aposentadoria é irreversível. Créditos destruídos não podem ser recriados, e o recibo público de aposentadoria fornece prova inequívoca de quem reivindicou a compensação. Essa prova não depende dos sistemas da Carrot — qualquer aposentadoria também pode ser verificada de forma independente por meio de um explorador público de blocos (ex.: [PolygonScan](https://polygonscan.com/)). Isso torna os créditos Carrot adequados para conformidade regulatória onde auditabilidade e não duplicação são obrigatórias.
## Conformidade EPR e ESG [#conformidade-epr-e-esg]
Os recibos de aposentadoria são a evidência primária para relatórios regulatórios e voluntários:
* **Extended Producer Responsibility (EPR)** — Produtores aposentam TRCs correspondentes à sua pegada de resíduos (ex.: 50 toneladas métricas de TRCs de um fluxo de material certificado para compensar 50 toneladas métricas desse material colocado no mercado). Como os créditos herdam rastreabilidade geográfica dos MassIDs, as aposentadorias podem satisfazer mandatos específicos por localização.
* **Relatórios ESG** — Organizações referenciam seus recibos de aposentadoria em relatórios de sustentabilidade, demonstrando que compromissos são respaldados por trabalho de reciclagem verificado e permanentemente reivindicado.
[Saiba mais sobre compra de créditos](/docs/protocol/credit-purchase) · [Saiba mais sobre certificados](/docs/protocol/certificates) · [Acesse o Registry](https://registry.carrot.eco)
# Créditos
## O que são créditos? [#o-que-são-créditos]
Créditos são as unidades negociáveis de impacto ambiental verificado no topo do [ciclo de vida dos créditos](/docs/protocol/credit-lifecycle) da Rede Carrot. Cada crédito representa **1 tonelada métrica** de impacto verificado — seja material reciclado ou reduções de emissões de gases de efeito estufa. No registry público de créditos, os créditos são unidades digitais fungíveis com precisão decimal: podem ser emitidos, mantidos, transferidos, comprados e aposentados em qualquer quantidade, incluindo frações.
Os créditos são o mecanismo pelo qual o trabalho ambiental realizado pelos [participantes da reciclagem](/docs/protocol/supply-chain) se torna uma commodity que organizações e indivíduos podem adquirir para compensar seus resíduos e pegadas de carbono.
## Tipos de crédito [#tipos-de-crédito]
A Rede Carrot suporta duas **categorias** de créditos ambientais. Cada categoria pode ter múltiplos símbolos de crédito, dependendo de qual metodologia emitiu os créditos:
| Categoria | Descrição | Símbolo exemplo | Emitido por | Unidade |
| -------------------------------- | ----------------------------------------------------- | --------------- | ----------------------------------------------------------------------- | ---------------------------------------------------------------- |
| Tokenized Recycling Credit (TRC) | Material reciclado certificado | `C-BIOW` | [BOLD Recycling](/docs/methodologies/bold-recycling) | 1 crédito = 1 tonelada métrica de material reciclado certificado |
| Tokenized Carbon Credit (TCC) | Reduções de emissões de gases de efeito estufa (CO₂e) | `C-CARB.CH4` | [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) (metano) | 1 crédito = 1 tonelada métrica de CO₂e em reduções |
Nem todo TRC é `C-BIOW` — `C-BIOW` é o crédito emitido pela metodologia BOLD Recycling. Outras metodologias de reciclagem podem emitir TRCs com diferentes símbolos de crédito. Da mesma forma, nem todo TCC é `C-CARB.CH4` — `C-CARB.CH4` é o crédito de metano emitido pela metodologia BOLD Carbon (CH₄); outras metodologias de carbono podem emitir TCCs com símbolos diferentes.
### Tokenized Recycling Credits (TRC) [#tokenized-recycling-credits-trc]
Os TRCs representam resíduos reciclados certificados. Quando [MassIDs](/docs/protocol/mass-ids) de um tipo específico de material passam pela verificação sob uma **metodologia de reciclagem** em uma instalação credenciada, os Certificados [RecycledID](/docs/protocol/certificates#recycledid) são criados e os créditos são emitidos em quantidade equivalente. A metodologia BOLD Recycling emite TRCs com o símbolo de crédito `C-BIOW`. Como os MassIDs registram a localização de origem da geração do resíduo, os TRCs podem ser rastreados até municípios específicos — tornando-os uma ferramenta para demonstrar conformidade com os mandatos de Responsabilidade Estendida do Produtor (EPR).
Os TRCs são específicos por material — cada TRC representa um fluxo de material certificado. Essa granularidade permite que compradores de créditos direcionem os fluxos de resíduos que correspondam às pegadas de seus produtos.
### Tokenized Carbon Credits (TCC) [#tokenized-carbon-credits-tcc]
Os TCCs representam reduções de emissões de gases de efeito estufa alcançadas por meio do desvio de resíduos ou tratamento biológico. Eles são lastreados por Certificados [GasID](/docs/protocol/certificates#gasid), que são gerados diretamente a partir dos MassIDs por uma metodologia de carbono — de forma independente dos RecycledIDs e TRCs. O cálculo das reduções de emissões é feito comparando o resultado do desvio ou tratamento com o cenário de disposição de referência (o que teria ocorrido se o resíduo fosse para um aterro sanitário ou lixão). A metodologia BOLD Carbon (CH₄) emite TCCs com o símbolo de crédito `C-CARB.CH4` (reduções de metano por meio da compostagem). Outras metodologias de carbono podem emitir TCCs com símbolos diferentes.
Os TCCs são particularmente valiosos para a reciclagem de resíduos biológicos. A compostagem de resíduos alimentares e verdes previne as emissões de metano que, de outra forma, ocorreriam ao longo de 20 anos de decomposição em aterro sanitário. As metodologias do [UNFCCC Clean Development Mechanism](https://unfccc.int/process-and-meetings/the-kyoto-protocol/mechanisms-under-the-kyoto-protocol/the-clean-development-mechanism) utilizadas para quantificar essas reduções de emissões demonstram que a compostagem de 2 toneladas de resíduos orgânicos pode entregar mais de 2 toneladas de CO₂e em reduções de emissões em comparação com o descarte em aterro.
## Ciclo de vida dos créditos [#ciclo-de-vida-dos-créditos]
Os créditos seguem um ciclo de vida claro, desde a emissão até a aposentadoria:
1. **Emitidos** — Quando um Certificado é criado pelo `InventoryManager`, os créditos são emitidos em quantidade equivalente e depositados no [Vault](/docs/protocol/smart-contracts).
2. **Mantidos** — Os créditos permanecem no Vault como inventário disponível até serem comprados.
3. **Comprados** — Quando um comprador [adquire créditos](/docs/protocol/credit-purchase), o pagamento (em USDC) é enviado ao `RewardsVault` para distribuição aos participantes, e um `CreditPurchaseReceipt` é registrado como prova auditável da transação.
4. **Aposentados, na liquidação ou depois** — A aposentadoria destrói os créditos no Vault e registra um `CreditRetirementReceipt` como prova. Ela ocorre na mesma transação da compra ou, mais tarde, contra um saldo entregue à conta do comprador. Créditos aposentados não podem ser revendidos ou reutilizados.
## Por que os créditos são fungíveis [#por-que-os-créditos-são-fungíveis]
Os MassIDs e os Certificados representam, cada um, lotes ou resultados únicos; os créditos, por sua vez, são fungíveis por design. Cada crédito de um determinado símbolo (ex.: `C-BIOW`) representa a mesma unidade — 1 tonelada métrica de material reciclado certificado para aquela metodologia — independentemente de quais MassIDs específicos o lastreiam.
Essa fungibilidade é o que torna os créditos negociáveis como commodities. Os compradores não precisam avaliar lotes individuais de resíduos; eles adquirem unidades padronizadas de impacto ambiental. Ao mesmo tempo, a cadeia completa de proveniência é preservada: cada crédito pode ser rastreado de volta, por meio de seu Certificado, até os MassIDs subjacentes, proporcionando total transparência para auditores e reguladores.
## Créditos e conformidade com EPR [#créditos-e-conformidade-com-epr]
Como os MassIDs registram a origem geográfica dos resíduos, os créditos herdam essa rastreabilidade. Uma empresa que opera no Brasil pode adquirir TRCs lastreados especificamente por resíduos coletados em municípios brasileiros, demonstrando conformidade com as regulamentações locais de EPR. Essa rastreabilidade específica por localização distingue os créditos Carrot dos offsets ambientais genéricos e os torna diretamente aplicáveis à conformidade regulatória.
[Saiba mais sobre a compra de créditos](/docs/protocol/credit-purchase) · [Saiba mais sobre os Certificados](/docs/protocol/certificates) · [Saiba mais sobre o ciclo de vida dos créditos](/docs/protocol/credit-lifecycle)
# MassIDs
## O que é um MassID? [#o-que-é-um-massid]
Um MassID representa um lote verificado de materiais ambientais na Rede Carrot — o registro fundamental para o processo de Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)) que sustenta tanto créditos de reciclagem quanto créditos de carbono. Uma vez emitido no registry público de créditos, cada MassID é um registro intransferível e auditável, mantido pelo [Vault](/docs/protocol/smart-contracts). Um operador da rede pode revogar um MassID quando os dados que o sustentam são posteriormente invalidados; a revogação é bloqueada assim que [créditos](/docs/protocol/credits) de seus [certificados](/docs/protocol/certificates) já tenham sido vendidos, e os certificados vinculados precisam ser revogados antes da revogação do MassID.
Quando qualquer quantidade de resíduo pós-consumo ou pós-industrial é identificada, medida e a custódia é estabelecida entre duas partes, um MassID é registrado no ledger imutável da plataforma da Carrot. Ele só é tokenizado no registry público depois de ser aprovado na verificação dMRV (veja abaixo). Ele registra três propriedades fundamentais:
* **Tipo de material** — O que é o resíduo (ex.: vidro transparente, resíduo orgânico alimentar, plásticos mistos)
* **Peso** — Quanto existe (em quilogramas)
* **Cadeia de custódia** — Cada participante que manuseou o material, da origem à reciclagem
Os metadados do MassID são armazenados no [IPFS](https://ipfs.tech/) — InterPlanetary File System — onde o endereçamento por conteúdo evidencia qualquer adulteração e permite verificação pública; a disponibilidade contínua depende de pinning ativo. A referência no Registry vincula esses metadados a cada lote de resíduos e à sua jornada pela [cadeia de suprimentos de reciclagem](/docs/protocol/supply-chain).
## Cadeia de custódia [#cadeia-de-custódia]
A cadeia de custódia registrada em cada MassID rastreia cada participante que manuseia o material. Os participantes se enquadram em seis categorias de função:
| Função | Chave | Descrição |
| ---------------------------------- | ----- | ----------------------------------------------------------------------------------------- |
| **Gerador de Resíduos** | G | A pessoa ou empresa que produz o resíduo |
| **Custodiante de Ponto de Coleta** | BC | Gerencia contentores e pontos de coleta |
| **Transportador** | H | Transporta resíduos entre locais |
| **Processador** | P | Separa, acumula ou pré-processa materiais |
| **Reciclador** | R | Realiza a reciclagem ou tratamento biológico final |
| **Integrador** | I | A [plataforma de software](/docs/protocol/network-integrators) que digitaliza a logística |
Cada categoria de função pode incluir múltiplos participantes. Por exemplo, uma cadeia de reciclagem de vidro pode envolver dois [transportadores](/docs/protocol/supply-chain) (coleta local e transporte de longa distância) e dois [processadores](/docs/protocol/supply-chain) (centro de acumulação local e a fábrica de envase de vidro).
O registro público comprova a cadeia sem expor as pessoas que a compõem. Cada participante na cadeia de custódia é registrado sob um identificador estável de participante, e o registro do MassID carrega apenas esse identificador — como um hash não reversível — ao lado da função do participante, nunca um nome ou um endereço de blockchain. As localizações são publicadas em nível de cidade, com coordenadas arredondadas para cerca de 0,1 grau. Em outras superfícies da rede, como tabelas de recompensas e perfis de participantes, Processadores, [Recicladores](/docs/protocol/supply-chain#o-papel-do-reciclador) e [Integradores](/docs/protocol/network-integrators) podem ser nomeados quando a organização tem perfil público; [Geradores de Resíduos](/docs/protocol/supply-chain), Transportadores e [Custodiantes de Ponto de Coleta](/docs/protocol/supply-chain) são omitidos por padrão e não são nomeados ali.
As recompensas são vinculadas aos participantes por meio desse mesmo identificador. Cada participante é elegível para uma parte dos recursos das vendas quando créditos gerados a partir daquele MassID são vendidos.
## Como os MassIDs são criados [#como-os-massids-são-criados]
MassIDs são gerados em três cenários principais:
### 1. Entrega no contentor [#1-entrega-no-contentor]
Quando um usuário deposita resíduos em um ponto de coleta. Se o produto puder ser identificado de forma única (via código QR, código de barras ou reconhecimento por IA), MassIDs são criados correspondendo à composição de resíduos daquele produto.
### 2. Coleta de resíduos [#2-coleta-de-resíduos]
Quando um transportador coleta resíduos de um gerador. O modelo de precisão graduada incentiva a pesagem na origem: geradores que pesam na coleta recebem atribuição de créditos mais precisa e, em programas [Pay-As-You-Throw](/docs/protocol/the-solution#payt), contas menores.
Quatro cenários se aplicam dependendo do nível de dados disponíveis:
* **Pesado na coleta** — MassID criado com tipo de material e peso exatos
* **Origem identificada, mas pesado na entrega** — MassID criado na entrega com o gerador registrado como origem
* **Rota mista sem pesagem na origem** — Todos os geradores na rota recebem distribuição igual de MassIDs com base no que foi validado na instalação de entrega
* **Sem pesagem, contentor identificado** — Peso estimado com base no tipo de contentor e médias validadas
### 3. Entrega em processadores e recicladores [#3-entrega-em-processadores-e-recicladores]
Quando resíduos chegam a uma instalação, o validador confirma o conteúdo do material (tipo e peso). Os MassIDs no inventário da instalação são gerenciados com base no **First-In-First-Out (FIFO)** — os MassIDs mais antigos são processados e creditados primeiro.
## Janela de envio [#janela-de-envio]
Os dados podem — e devem — chegar à rede conforme a operação acontece: uma massa reciclada hoje já pode ser enviada hoje. O que vem a seguir é um prazo limite, não a abertura de uma janela.
### O framework de metodologia define o limite [#o-framework-de-metodologia-define-o-limite]
Os dois [frameworks de metodologia](/docs/standard/concepts/mvf) só aceitam uma massa cujo evento Recycled tenha ocorrido **em ou após 1º de janeiro do ano civil anterior, em UTC** — o período de projeto permitido, publicado como **Período do projeto** nos [parâmetros-chave do BOLD Recycling](/docs/methodologies/bold-recycling/framework#parâmetros-chave) e nos [parâmetros-chave do BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon#parametros-chave). Um MassID fora desse período é reprovado na verificação da metodologia e não gera crédito, tenha sido enviado quando for.
Ou seja, o ano em que o material foi reciclado é o que determina qual é o último ciclo dele. O limite é avaliado sobre o timestamp UTC do evento, então um evento Recycled registrado em 31 de dezembro a partir das 21h (horário de Brasília) já conta como do ano seguinte:
| Reciclado em (UTC) | Último ciclo que pode analisar | Os dados precisam chegar à rede até |
| ------------------ | ------------------------------ | ----------------------------------- |
| 2025 | 2026 | 30 de novembro de 2026 |
| 2026 | 2027 | 30 de novembro de 2027 |
| 2027 | 2028 | 30 de novembro de 2028 |
### Como cada ciclo fecha [#como-cada-ciclo-fecha]
* **Até 30 de novembro, 23h59 (horário de Brasília, UTC-3)** — os dados das massas e a documentação necessária precisam chegar à rede para serem analisados no ciclo daquele ano.
* **De 1 a 15 de dezembro** — período reservado para a [verificação da metodologia](/docs/standard/concepts/lifecycle), o trabalho de asseguração de terceiros em torno dela e os ajustes decorrentes, seguidos da emissão dos casos aprovados. Correções solicitadas para envios recebidos dentro do prazo continuam sendo aceitas nesse período.
A janela existe porque a verificação, o trabalho de asseguração que a sustenta e os ajustes que eles exigem precisam de tempo entre o corte dos dados e o fechamento do ciclo.
15 de dezembro é a data-alvo de fechamento do ciclo, não uma garantia de emissão: um MassID só gera crédito quando sua documentação está completa e ele é aprovado na verificação da metodologia.
Envios recebidos após 30 de novembro — e casos ainda pendentes no fechamento — são avaliados no ciclo seguinte sempre que o período de projeto permitido ainda os alcançar. Uma massa que já está no seu último ano elegível não tem ciclo seguinte: quando o ano vira, o evento Recycled dela passa a estar fora desse período.
A elegibilidade segue a **data do evento Recycled**, não a data em que os dados foram enviados.
Enviar dentro do prazo não torna uma massa elegível quando o evento Recycled dela está fora do
período de projeto permitido, e o prazo não altera como o vintage do crédito é determinado.
## Prova de Trabalho Físico e Procedência [#prova-de-trabalho-físico-e-procedência]
MassIDs fornecem duas formas de prova verificável:
* **Proof-of-Provenance** — A cadeia de custódia estabelece de onde o resíduo veio e quem o manuseou em cada etapa, criando um caminho rastreável da origem à reciclagem.
* **Proof-of-Physical-Work** — Cada evento da cadeia de suprimentos registrado no MassID (coleta, entrega, triagem, confirmação de reciclagem) constitui evidência de que trabalho físico real foi realizado — resíduos foram coletados, transportados, separados e reciclados.
Juntas, essas provas formam a base do processo de dMRV que leva à geração de créditos. Apenas MassIDs que chegam a uma instalação certificada de reciclagem ou tratamento biológico, com cadeia de custódia validada em cada ponto, tornam-se elegíveis para gerar créditos.
Este registro no Registry é a tecnologia que viabiliza o modelo [**Recycle-to-Earn**](/docs/glossary#recycle-to-earn) — onde cada participante verificado na cadeia de suprimentos de reciclagem recebe recompensas proporcionais à sua contribuição.
Após um MassID passar por todas as verificações e ser elegível para gerar um Certificado, ele é [registrado no registry público](/docs/protocol/on-chain-minting) — seus metadados endereçados por conteúdo são armazenados no IPFS, com disponibilidade dependente de pinning contínuo, e a referência do MassID é gravada no Registry.
[Saiba mais sobre verificação dMRV](/docs/protocol/dmrv) · [Explore o ciclo de vida dos créditos](/docs/protocol/credit-lifecycle)
### Diagram: massid-lifecycle
Este ciclo de vida do MassID acompanha eventos de coleta, manifesto de transporte, pesagem, triagem, recebimento, manifesto de reciclagem e conclusão do tratamento biológico até a auditoria do MassID e outputs metodológicos auditáveis. As raias identificam gerador ou transportador, processador ou reciclador, integrador e Plataforma Carrot; os marcadores coloridos mostram verificações de estrutura, metodologia e auditoria acumuladas antes da aprovação.
# Criação de Registros no Registry
## De dados verificados a registros públicos no registry [#de-dados-verificados-a-registros-públicos-no-registry]
Após um [MassID](/docs/protocol/mass-ids) ser aprovado na [verificação de metodologia](/docs/protocol/methodology-execution), ele é emitido como registro no registry — transformado de um registro verificado mantido pela plataforma em uma entrada auditável e publicamente verificável no registry público. A emissão cria um vínculo publicamente verificável entre o trabalho físico de reciclagem e sua representação digital no registry.
A emissão no registry é a ponte entre o processo de verificação de Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)) e o [ciclo de vida dos créditos](/docs/protocol/credit-lifecycle) que, em última instância, produz créditos ambientais negociáveis — incluindo créditos de reciclagem e créditos de carbono.
## O processo de criação do registro [#o-processo-de-criação-do-registro]
### 1. Verificação concluída [#1-verificação-concluída]
O MassID foi aprovado em todas as verificações de [metodologia](/docs/methodologies). Seu tipo de material, peso e cadeia de custódia são validados, e todas as condições de conformidade definidas pela metodologia aplicável são atendidas. O MassID é marcado como pronto para registro no Registry.
### 2. Criação de metadados [#2-criação-de-metadados]
Metadados estruturados são compilados para o MassID. Esses metadados capturam o registro completo de proveniência:
| Campo | Descrição |
| ---------------------- | ---------------------------------------------------------------------------------------------------------------- |
| **Tipo de material** | A classificação do material residual (ex.: vidro transparente, plástico, resíduo orgânico alimentar) |
| **Peso** | O peso verificado em quilogramas |
| **Cadeia de custódia** | Cada participante que manuseou o material, identificado por um hash não reversível de participante e pela função |
| **Timestamps** | Quando cada evento na cadeia de custódia ocorreu |
Esses metadados se tornam a descrição endereçada por conteúdo referenciada pelo registro do MassID no Registry. A metodologia que verificou o material — nome, versão e um link para a especificação publicada — e uma referência à verificação ficam pinadas no certificado emitido a partir deste MassID, que referencia o MassID por token id e URI IPFS. Os resultados das regras, as decisões de revisão e seus insumos permanecem na plataforma e são refletidos no Carrot Registry.
### 3. Armazenamento descentralizado [#3-armazenamento-descentralizado]
Os metadados compilados são enviados para o [IPFS](https://ipfs.tech/) (InterPlanetary File System), produzindo uma URI endereçada por conteúdo. Essa URI é única para o conteúdo dos metadados — qualquer alteração nos dados produziria uma URI diferente, tornando evidente qualquer adulteração do registro armazenado.
A URI do IPFS é então referenciada pelo registro on-chain no Registry, vinculando a entrada leve na blockchain aos metadados completos armazenados na infraestrutura descentralizada.
### 4. Criação do registro no Registry [#4-criação-do-registro-no-registry]
O MassID é registrado on-chain como um registro intransferível no Registry, mantido pelo contrato [Vault](/docs/protocol/smart-contracts). A implementação usa ERC-721, enquanto o modelo público é o próprio registro MassID. A transação de criação registra a URI dos metadados do IPFS on-chain, associando a entrada no Registry aos seus dados de proveniência. Como os metadados são endereçados por conteúdo, essa associação evidencia qualquer adulteração: uma alteração posterior na referência on-chain emite um evento público, de modo que o registro é auditável, e não silenciosamente editável.
Um registro no Registry também pode ser revogado. Um operador da rede pode revogar um MassID quando os dados que o sustentam se mostram inválidos, o que substitui sua referência de metadados por um registro de revogação e remove o token do Vault. A revogação é bloqueada assim que créditos dos [certificados](/docs/protocol/certificates) daquele MassID já tenham sido vendidos, e ela não é em cascata — os certificados vinculados precisam ser revogados antes.
Como os registros MassID são intransferíveis, eles não podem ser negociados ou movidos entre contas. Isso garante que a cadeia de proveniência permaneça intacta e evita atividade especulativa sobre registros de verificação.
### 5. Vinculação de registros [#5-vinculação-de-registros]
A plataforma atualiza seus registros internos para conectar o MassID verificado ao ID de seu registro on-chain. Essa vinculação garante que a plataforma, a blockchain e o [Carrot Registry](/docs/protocol/registry) referenciem os mesmos dados subjacentes — criando um registro consistente e auditável entre sistemas.
IPFS (InterPlanetary File System) é uma rede de armazenamento descentralizada onde os arquivos são endereçados pelo hash de seu conteúdo, e não por localização. Isso fornece duas propriedades importantes para MassIDs registrados:
* **Evidência de adulteração** — A URI endereçada por conteúdo é derivada dos próprios metadados. Se alguém alterasse os metadados após o upload, a URI mudaria, revelando imediatamente a mudança. A referência on-chain identifica, portanto, exatamente os metadados para os quais aponta, e qualquer alteração nessa referência é ela própria publicada como um evento público.
* **Disponibilidade distribuída** — Os metadados não ficam vinculados a um único servidor ou organização, mas permanecem acessíveis apenas enquanto pelo menos um nó realiza pinning ativo. O pinning contínuo faz parte, portanto, dos controles de durabilidade da rede.
Juntas, essas propriedades tornam evidente qualquer adulteração dos metadados que sustentam cada MassID registrado e permitem verificá-los de forma independente, enquanto o Registry preserva uma referência auditável — um requisito fundamental para créditos ambientais que devem resistir ao escrutínio regulatório.
## O que acontece a seguir [#o-que-acontece-a-seguir]
MassIDs registrados são a base sobre a qual o restante do ciclo de vida dos créditos é construído. Uma vez que um MassID existe no Registry:
* **Certificados são gerados** — Quando MassIDs são aprovados na verificação de metodologia em uma instalação credenciada por auditores terceiros independentes, certificados (RecycledID ou GasID) são registrados, referenciando os registros MassID subjacentes como prova do trabalho físico realizado.
* **Créditos são emitidos** — Cada certificado gera [créditos](/docs/protocol/credits) fungíveis (TRC ou TCC), usando a unidade definida por sua metodologia. Esses créditos são as unidades negociáveis que compradores adquirem para cumprir seus compromissos ambientais.
* **Rastreabilidade completa é estabelecida** — A partir de um crédito aposentado, qualquer parte pode rastrear de volta pelo certificado, até o MassID registrado, os metadados no IPFS e, por fim, os lotes específicos de resíduos e os participantes da cadeia de suprimentos que realizaram o trabalho. Essa rastreabilidade é publicamente verificável por meio do [Carrot Registry](/docs/protocol/registry) ou qualquer explorador de blocos da blockchain (ex.: [PolygonScan](https://polygonscan.com/)).
## Páginas relacionadas [#páginas-relacionadas]
* [Ciclo de Vida dos Créditos](/docs/protocol/credit-lifecycle) — O ciclo de vida e as relações entre MassID, Certificado e Crédito
* [Smart Contracts](/docs/protocol/smart-contracts) — A infraestrutura on-chain que gerencia a criação de registros e a custódia
* [MassIDs](/docs/protocol/mass-ids) — A unidade de dados fundamental representando lotes de resíduos verificados
# dMRV
## O que é dMRV? [#o-que-é-dmrv]
Monitoramento, Relato e Verificação digital (dMRV) é o processo ponta a ponta para executar critérios de frameworks de metodologia aprovados — da captura de dados ao registro de evidências e à geração de créditos. Ele fornece dados, ferramentas e trilhas de auditoria que permitem a [organismos de validação e verificação (VVBs)](/docs/glossary#vvb) independentes e terceirizados realizar garantia escalável sobre créditos de reciclagem e de carbono.
O MRV tradicional depende de auditorias manuais, comprovantes em papel e certificação por terceiros que leva de 3 a 5 anos e custa entre US$250–500 mil por projeto. O dMRV da Carrot transforma o fluxo operacional em evidência revisável — da captura de dados no ponto de geração de resíduos, passando pela execução da metodologia, até a geração de créditos — tornando a verificação mais contínua, transparente e escalável enquanto preserva o papel da garantia externa.
O sistema dMRV da Carrot é a base dos mercados de créditos ambientais da [Rede Carrot](/docs/network), abrangendo tanto os [Tokenized Recycling Credits (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc) quanto os [Tokenized Carbon Credits (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc).
## Como a verificação funciona [#como-a-verificação-funciona]
O sistema dMRV da Carrot orquestra a execução ao aplicar critérios de frameworks de metodologia
aprovados a dados da cadeia de suprimentos e registrar resultados auditáveis. A Carrot Foundation
não cria metodologias, frameworks de verificação ou aplicações de dMRV; ela aprova metodologias,
frameworks e aplicações de terceiros para uso na Rede Carrot. Verificadores independentes fornecem
garantia sobre as evidências e o processo de governança quando aplicável.
O processo de dMRV segue um fluxo definido:
1. **Captura de dados** — [Integradores](/docs/protocol/network-integrators) conectam aplicações de logística e gestão de resíduos à Rede Carrot, submetendo eventos da [cadeia de suprimentos](/docs/protocol/supply-chain) (coleta, triagem, reciclagem) conforme ocorrem.
2. **Codificação de resíduos** — Cada lote de resíduos é codificado em um [MassID](/docs/protocol/mass-ids), criando um registro digital de tipo de material, peso e procedência. Os MassIDs são atualizados por meio de eventos da cadeia de suprimentos conforme os materiais se movem ao longo do fluxo.
3. **Cadeia de custódia** — Cada transferência e transformação é registrada no MassID, estabelecendo uma cadeia de custódia ininterrupta desde a origem do resíduo até o [Reciclador](/docs/protocol/supply-chain#o-papel-do-reciclador) certificado. Isso constitui a **Prova de Trabalho Físico** (Proof-of-Physical-Work) — evidência verificável de que o trabalho físico de coleta, triagem, transporte e reciclagem realmente ocorreu.
4. **Verificação da metodologia** — Cada [metodologia](/docs/methodologies) é traduzida em um [Framework de Verificação de Metodologia (MvF)](/docs/standard/concepts/mvf) — a especificação que define regras e cálculos — e implementada como uma [Aplicação de Verificação de Metodologia (MvA)](/docs/standard/concepts/mva) que automatiza a verificação. Essas aplicações confirmam que os dados da cadeia de suprimentos atendem aos requisitos da metodologia.
Uma regra pode passar, falhar ou retornar um resultado indeterminado. Um resultado
indeterminado pausa a execução da verificação e encaminha a regra para uma decisão humana
registrada — o revisor aprova ou rejeita a regra com uma justificativa escrita, e a decisão
fica guardada junto à execução. Veja [Execução da
Metodologia](/docs/protocol/methodology-execution) para entender como funciona a etapa de
revisão e o que acontece quando ela não é resolvida.
5. **Geração de créditos** — MassIDs que passam pela verificação de uma metodologia específica geram [Certificados](/docs/protocol/certificates) ([GasID](/docs/protocol/certificates#gasid) para reduções de emissões de carbono, [RecycledID](/docs/protocol/certificates#recycledid) para reciclagem), que por sua vez emitem créditos fungíveis (TCC e TRC). Cada metodologia emite créditos sob seu próprio símbolo no Registry (ex.: [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) emite `C-CARB.CH4`, [BOLD Recycling](/docs/methodologies/bold-recycling) emite `C-BIOW`).
6. **Verificabilidade pública** — Registros do Registry — da emissão à [aposentadoria de créditos](/docs/protocol/credit-retirement) — são visualizáveis pelo [Carrot Registry](/docs/protocol/registry) ou, de forma independente da Carrot, por qualquer [explorador público de blockchain](/docs/glossary#blockchain-block-explorer). Auditores, compradores de créditos, reguladores ou qualquer pessoa podem verificar os registros por conta própria.
Para detalhes técnicos sobre como as regras da metodologia são executadas, veja [Execução da Metodologia](/docs/protocol/methodology-execution).
## Validadores e eventos da cadeia de suprimentos [#validadores-e-eventos-da-cadeia-de-suprimentos]
Transferências de materiais na cadeia de suprimentos de reciclagem sempre ocorrem entre duas partes: um detentor e um receptor. O **receptor** atua como [Validador](/docs/glossary#validator), confirmando o conteúdo do material (peso, qualidade, origem) e atualizando o MassID a cada operação logística. O detentor mantém acesso aos dados de validação e pode contestá-los.
Os dados da cadeia de suprimentos incluem coletas, entregas, pesagens, triagem e confirmações de reciclagem. A cada transferência de material, o receptor atua como Validador e atualiza a cadeia de custódia do MassID, contribuindo para o registro de Prova de Trabalho Físico. Para a lista completa de tipos de eventos e como são validados, veja a [Especificação de Eventos](/docs/integrations/reference/event-specification) e as regras da metodologia (ex.: [regras do BOLD Recycling](/docs/methodologies/bold-recycling/framework/application/application-rules)).
## Integridade de Dados e Confiança [#integridade-de-dados-e-confiança]
Prova de Autoridade (Proof-of-Authority, PoA) é o mecanismo que garante a integridade dos dados e a confiança na Rede Carrot. Opera em três níveis: autopoliciamento econômico entre os participantes, homologação de instalações conduzida por auditores independentes, e supervisão da rede pela [Fundação Carrot](/docs/network/the-foundation).
### Autopoliciamento por incentivos econômicos [#autopoliciamento-por-incentivos-econômicos]
Como as recompensas econômicas estão vinculadas ao rastreamento validado de resíduos e à geração de créditos, cada participante tem interesse financeiro em manter a precisão dos dados. Se um MassID é sinalizado por atividade suspeita ou dados imprecisos, ele é desqualificado da geração de créditos — e **todos os participantes** vinculados a esse MassID sofrem a perda financeira. Isso cria um autopoliciamento natural ao longo de toda a cadeia de suprimentos.
Como as operações logísticas no meio e no fim da cadeia de suprimentos são tipicamente pagas por peso, a confiabilidade dos dados de peso torna-se inerentemente alta. Recicladores compram materiais ou cobram por serviços com base no peso, criando alinhamento econômico com a precisão dos dados.
### Homologação de instalações [#homologação-de-instalações]
Recicladores devem ser homologados por meio de uma **auditoria independente** antes de poderem participar da geração de créditos. Esses auditores independentes avaliam operações das instalações, capacidade de processamento e manuseio de materiais para garantir que a instalação atenda aos requisitos da metodologia. A Carrot não realiza essa homologação — ela é conduzida por organismos de auditoria externos.
### Supervisão da rede [#supervisão-da-rede]
A Fundação Carrot fornece uma camada adicional de confiança por meio da supervisão em nível de rede. A autoridade de supervisão da Fundação inclui:
* **Suspender** participantes que tentam manipular dados — todos os MassIDs na cadeia de custódia desse participante são excluídos da geração de créditos
* **Solicitar informações** de qualquer participante na cadeia — a falta de resposta pode resultar em exclusão permanente
* **Desqualificar permanentemente** casos de fraude confirmada, com créditos emitidos anteriormente congelados até resolução
As ferramentas de supervisão incluem manifestos de transferência de resíduos, comprovantes de compra de materiais e dados históricos de desempenho que rastreiam variações nos volumes de resíduos e tempos de trânsito.
## Detecção de Anomalias (CaE) [#detecção-de-anomalias-cae]
O [Carrot Analytic Engine (CaE)](/docs/glossary#cae) é a camada de avaliação da pilha de verificação — uma camada de aprendizado de máquina projetada para analisar dados de dMRV e detectar anomalias, inconsistências e padrões suspeitos nos dados da cadeia de suprimentos. Quando o CaE sinaliza irregularidades, a plataforma pode encaminhar eventos para revisão adicional ou pausar a emissão de créditos. Hoje, a emissão de créditos é condicionada aos resultados das regras da metodologia: uma regra que o código decide contra bloqueia a emissão, e uma regra que retorna resultado indeterminado pausa a execução para uma decisão humana registrada. Veja [Ecossistema de Metodologias](/docs/standard/concepts/ecosystem#platform-intelligence-layers) para mais detalhes.
## Consultoria de Metodologia (CaA) [#consultoria-de-metodologia-caa]
O [Carrot Agentic Advisor (CaA)](/docs/glossary#caa) é uma camada de IA que identifica oportunidades de melhoria em metodologias, qualidade de dados e processos em todo o ecossistema. Veja [Ecossistema de Metodologias](/docs/standard/concepts/ecosystem#platform-intelligence-layers) para mais detalhes.
## Por que o dMRV importa [#por-que-o-dmrv-importa]
Os mercados tradicionais de créditos ambientais sofrem com problemas persistentes de confiança: contagem dupla, alegações não verificadas e registros opacos. Resíduos físicos, ao contrário de emissões de carbono, são tangíveis e mensuráveis — mas sem um sistema de verificação digital, créditos baseados em resíduos enfrentam os mesmos desafios de confiança. Na verificação tradicional, um agente de VVB tipicamente analisa aproximadamente 2% dos dados do projeto por meio de auditorias manuais periódicas. A infraestrutura de dMRV da Carrot verifica 100% dos dados relacionados a cada MassID e certificado, permitindo que VVBs realizem verificações mais completas e contínuas.
O dMRV da Carrot resolve isso digitalizando todo o processo de verificação — executando regras da metodologia contra dados da cadeia de suprimentos e registrando os resultados verificados no registry público. O resultado são créditos ambientais respaldados por resultados físicos verificáveis, em vez de estimativas, projeções ou comprovantes em papel.
[Saiba mais sobre certificados](/docs/protocol/certificates) · [Explore a cadeia de suprimentos](/docs/protocol/supply-chain)
### Diagram: dmrv-process-flow
O fluxo do processo dMRV agrupa a camada de dados e a camada de verificação da Carrot em dois subfluxos empilhados. Captura de dados, codificação de resíduos e cadeia de custódia registram evidências na camada de dados; verificação metodológica, emissão de certificado e criação de crédito consomem essas evidências na camada de verificação. Uma única aresta-ponte marca a transição da evidência coletada para o crédito verificado.
# Execução da Metodologia
## Visão geral [#visão-geral]
As [Metodologias](/docs/methodologies) definem a base científica para a geração de créditos ambientais. Cada metodologia é traduzida em um [framework de metodologia (MvF)](/docs/standard/concepts/mvf) — a especificação de regras, gatilhos e critérios de verificação — e implementada como uma [Methodology Verification Application (MvA)](/docs/standard/concepts/mva) que executa essas regras na plataforma sob esse framework. A plataforma recebe dados estruturados dos [Integradores](/docs/protocol/network-integrators), os processa através do MvA de acordo com as regras do framework de metodologia, e produz resultados verificados — [MassIDs](/docs/protocol/mass-ids) e [certificados](/docs/protocol/certificates) que se tornam a base para créditos emitidos no registry público de créditos.
Esta página explica o pipeline de execução de ponta a ponta: como os dados entram na plataforma, como são processados e como os resultados verificados são produzidos. A execução e os resultados das regras são persistidos após cada regra e reportados em tempo real no [Carrot Registry](/docs/protocol/registry) ([registry.carrot.eco](https://registry.carrot.eco)).
## Como os dados entram na plataforma [#como-os-dados-entram-na-plataforma]
Os Integradores enviam dados da cadeia de suprimentos via [Carrot API](/docs/integrations/api). Esses dados descrevem os eventos físicos que ocorrem ao longo da [cadeia de suprimentos de reciclagem](/docs/protocol/supply-chain):
| Tipo de dado | Descrição |
| ----------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| **Movimentações de resíduos** | Coletas e entregas — tipo de material, peso e os participantes envolvidos |
| **Resultados ambientais** | Confirmações de reciclagem e tratamento biológico, incluindo quantidades certificadas e métodos de processamento |
A homologação de instalações não faz parte do que os integradores enviam. Os registros de
homologação — e a verificação presencial por terceiros que os sustenta — são mantidos pela Carrot na
camada de homologação, e o pipeline de verificação os consulta ao avaliar um MassID. Os envios dos
integradores cobrem movimentações de resíduos e resultados ambientais.
Cada envio é armazenado como um **registro versionado** que captura o estado dos dados em um ponto específico no tempo. Os dados registrados são **imutáveis** — não podem ser alterados ou excluídos, apenas estendidos com novos eventos ou versões. Cada alteração nos dados da cadeia de suprimentos é rastreável, criando uma trilha de auditoria completa desde o envio inicial até a verificação final.
## Processamento e verificação [#processamento-e-verificação]
Quando novos dados chegam, a plataforma os processa através de um pipeline estruturado:
1. **Reconhecimento de documento** — A plataforma identifica o tipo de dado recebido (movimentação de resíduos, relatório de auditoria, evento de emissão) e o encaminha para o processamento apropriado.
2. **Sincronização de entidades** — As entidades relevantes — MassIDs, certificados e registros de participantes — são atualizadas para refletir o que aconteceu no mundo físico. Por exemplo, um evento de entrega atualiza a cadeia de custódia do MassID para incluir a instalação receptora.
3. **Avaliação de gatilhos** — A plataforma verifica se algum gatilho de metodologia se aplica aos dados recebidos. Se uma condição de gatilho for atendida, as regras correspondentes do framework de metodologia são enfileiradas para execução pelo MvA.
## Gatilhos de metodologia [#gatilhos-de-metodologia]
Cada framework de metodologia (MvF) define **gatilhos** — condições sobre os dados recebidos que, quando correspondidas, fazem as regras serem executadas. Os gatilhos conectam eventos do mundo real à lógica de verificação que produz resultados ambientais. As condições exatas dos gatilhos são definidas por framework; consulte o [catálogo de metodologias](/docs/methodologies) para o comportamento de cada framework.
As condições de gatilho são orientadas por documentos e eventos. Os dois frameworks publicados usam a mesma:
* **Auditoria do MassID** — Quando o documento de auditoria de um MassID é aberto sob uma metodologia, a plataforma executa as regras de validação de MassID daquele framework contra os eventos da cadeia de suprimentos enviados. Quando todas essas regras passam, a emissão de certificado é disparada (ex.: RecycledID ou GasID sob [BOLD Recycling](/docs/methodologies/bold-recycling) ou [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon)).
Os gatilhos garantem que as regras só sejam executadas quando dados relevantes mudam, mantendo a execução eficiente e previsível.
## Execução de regras [#execução-de-regras]
Quando um gatilho é disparado, a plataforma executa as regras do framework de metodologia via MvA em uma sequência definida. Após cada regra ser executada, seu resultado é persistido e disponibilizado em tempo real no Carrot Registry.
### 1. Preparar [#1-preparar]
A plataforma determina quais regras se aplicam ao escopo disparado e estabelece a ordem de execução. Cada framework de metodologia define suas regras como uma sequência ordenada, garantindo avaliação consistente independentemente de quando o gatilho é disparado.
### 2. Avaliar [#2-avaliar]
Cada regra na sequência é executada. Uma regra avalia condições contra os dados atuais, realiza cálculos quando necessário e produz saídas. As regras podem validar tipos de material, verificar a completude da cadeia de custódia, calcular pesos ou avaliar conformidade com critérios específicos da metodologia. O resultado de cada regra é persistido imediatamente e visível no Carrot Registry, para que o progresso da execução e os resultados estejam disponíveis em tempo real.
### 3. Revisar quando necessário [#3-revisar-quando-necessário]
Regras que o código não consegue resolver por conta própria retornam um resultado que exige revisão. A execução então pausa para uma decisão humana registrada: um revisor aprova ou rejeita cada regra sinalizada com justificativa escrita obrigatória, e a decisão é guardada junto à execução, com a identidade do revisor e o momento em que ela foi tomada. Se a janela de revisão se encerrar com regras sinalizadas ainda sem decisão, essas regras são rejeitadas automaticamente e a verificação falha.
### 4. Finalizar [#4-finalizar]
Após todas as regras serem concluídas — e depois que qualquer revisão necessária for resolvida — a plataforma finaliza as saídas: MassIDs verificados são marcados como elegíveis para minting on-chain, certificados são enfileirados para emissão e o estado é atualizado em todas as entidades afetadas. Os registros do registry em si — MassIDs registrados, certificados e créditos emitidos — são gravados no ledger público. Os resultados das regras, as decisões de revisão e suas entradas ficam na plataforma, e tudo isso é refletido no Carrot Registry.
## Resultados [#resultados]
A execução da metodologia produz dois resultados principais:
* **MassIDs verificados** — MassIDs que passaram em todas as verificações da metodologia e estão prontos para [minting on-chain](/docs/protocol/on-chain-minting). Sua cadeia de custódia está completa, tipo de material e peso estão validados e todas as condições de conformidade estão satisfeitas.
* **Certificados** — Quando um MassID passa em todas as regras de verificação da metodologia em uma instalação homologada, certificados ([RecycledID](/docs/protocol/certificates#recycledid) ou [GasID](/docs/protocol/certificates#gasid)) são emitidos. Os certificados vinculam o resultado ambiental verificado ao MassID subjacente e iniciam o minting de [tokens de crédito](/docs/protocol/credits) fungíveis.
Para gerar um certificado ou crédito, a massa rastreada precisa satisfazer todos os critérios aplicáveis do framework. A maior parte dos critérios é resolvida por validação em código, e um critério que o código decide contra bloqueia a emissão de certificado e a geração de crédito até que o problema seja corrigido conforme o framework aplicável. Os critérios que o código não consegue resolver por conta própria são decididos pela revisão humana registrada descrita acima — uma revisão aprovada resolve o critério sem que o código o decida, e uma revisão rejeitada faz a verificação falhar.
Apenas dados destinados a serem públicos são registrados na **blockchain pública** — por exemplo, MassIDs mintados, Certificados, tokens de crédito e recibos de aposentadoria. Esses dados on-chain são publicamente acessíveis: visualizáveis através de qualquer [explorador de blockchain](/docs/glossary#blockchain-block-explorer) (ex.: [PolygonScan](https://polygonscan.com/)) ou o Carrot Registry, que fornece uma visão amigável e focada no domínio da execução de regras e resultados para auditores, reguladores e compradores de créditos.
## Páginas relacionadas [#páginas-relacionadas]
* [dMRV](/docs/protocol/dmrv) — O processo de execução e evidência para critérios de frameworks de metodologia aprovados
* [MvF](/docs/standard/concepts/mvf) e [MvA](/docs/standard/concepts/mva) — Como os frameworks de metodologia e suas implementações definem e executam regras
* [Criação de Registros no Registry](/docs/protocol/on-chain-minting) — Como MassIDs verificados se tornam registros permanentes no registry
* [Metodologias](/docs/methodologies) — As bases científicas validadas e seus frameworks que definem as regras de verificação
# Integradores
## O que é um Integrador? [#o-que-é-um-integrador]
Um Integrador é uma aplicação de software de terceiros que envia dados da [cadeia de suprimentos](/docs/protocol/supply-chain) à [Rede Carrot](/docs/network) por meio da [Carrot API](/docs/integrations/api). Os Integradores são a ponte entre as operações físicas de reciclagem e a camada de verificação digital da Rede Carrot — eles digitalizam as atividades de gestão de resíduos que seus clientes realizam todos os dias.
Os Integradores são tipicamente plataformas de logística, aplicações de gestão de resíduos ou ferramentas de software de reciclagem que já atendem participantes da cadeia de suprimentos de reciclagem — [Geradores de Resíduos, Custodiantes de Ponto de Coleta, Transportadores, Processadores e Recicladores](/docs/protocol/supply-chain). Ao se integrar à Rede Carrot, essas plataformas desbloqueiam a geração de créditos e recompensas para sua base de usuários existente, sem exigir que esses usuários interajam diretamente com a Rede Carrot.
## Como a integração funciona [#como-a-integração-funciona]
Para se tornar um Integrador, uma plataforma de software passa pelo processo de **homologação** da Carrot — uma análise formal que verifica se a plataforma pode enviar dados precisos da cadeia de suprimentos de forma confiável. Uma vez homologada, a plataforma se conecta à Rede Carrot por meio da Carrot API.
Através dessa integração, os Integradores:
* **Enviam dados de eventos da cadeia de suprimentos** — Cada coleta, entrega e validação de material realizada por seus usuários é reportada à Rede Carrot, criando o rastro digital que sustenta o Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)) por trás dos créditos de reciclagem e de carbono.
* **Criam e atualizam MassIDs** — À medida que os materiais se movem pela cadeia de suprimentos, os dados do integrador alimentam a cadeia de custódia do [MassID](/docs/protocol/mass-ids), registrando o que foi coletado, por quem e para onde foi.
* **Viabilizam a distribuição de recompensas** — Ao digitalizar toda a cadeia de custódia, da geração de resíduos até a reciclagem certificada, os integradores possibilitam que cada participante receba sua parcela de [recompensas](/docs/protocol/rewards-distribution).
## Por que os Integradores são importantes [#por-que-os-integradores-são-importantes]
A Rede Carrot não opera caminhões de coleta de resíduos nem instalações de triagem. É uma camada de verificação e geração de créditos que depende de dados precisos e em tempo real da cadeia de suprimentos física. Os Integradores fornecem esses dados.
Essa arquitetura cria uma separação de responsabilidades:
* **Os Integradores** se concentram no que fazem de melhor — software de logística, otimização de rotas, gestão de frotas e operações com clientes.
* **A Rede Carrot** se concentra em verificação, [execução da metodologia](/docs/protocol/methodology-execution) e geração de créditos — usando os dados que os integradores fornecem.
Para os clientes do integrador, o resultado é transparente: eles continuam usando seu software de gestão de resíduos existente, e a verificação e geração de créditos da Rede Carrot acontecem em segundo plano. Geradores de Resíduos ganham uma parcela fixa por tipo de resíduo pelo material que separaram, Transportadores ganham recompensas pelo transporte verificado, e Processadores e Recicladores ganham recompensas pelo processamento verificado — tudo sem precisar interagir com um sistema separado.
## Incentivos [#incentivos]
Os Integradores recebem uma parcela dos recursos das vendas quando os créditos gerados a partir dos MassIDs que eles ajudaram a rastrear são comprados — [Tokenized Recycling Credits (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc) ou [Tokenized Carbon Credits (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc). A emissão de um certificado, por si só, não gera recompensa: a parcela é definida quando os créditos são vendidos. Essa parcela de recompensas é definida na [Política de Distribuição de Recompensas](/docs/standard/policies/rewards-distribution).
Isso cria um alinhamento direto: quanto mais cadeias de suprimentos um integrador digitaliza, quanto mais material chega à reciclagem certificada e quanto mais dos créditos resultantes são comprados, mais recompensas o integrador recebe. O modelo incentiva os integradores a integrar novos clientes, expandir para novos tipos de resíduos e melhorar a qualidade dos dados — tudo isso fortalece a rede.
## Ecossistema aberto [#ecossistema-aberto]
A Rede Carrot opera como um ecossistema aberto. Qualquer plataforma de software que atenda aos requisitos de homologação pode se tornar um Integrador. Essa abertura também se aplica a propostas de metodologias, frameworks de verificação de metodologia e aplicações de dMRV de terceiros: contribuidores do ecossistema podem submetê-los para revisão e aprovação sob o [Carrot dMRV Standard](/docs/standard). Os [Autores de MvF](/docs/standard/concepts/mvf#o-papel-do-mvf-author) são incentivados por meio de uma parcela dos recursos das compras de créditos, incentivando a inovação em toda a rede.
Essa abordagem distribuída permite que a Rede Carrot escale entre geografias e tipos de resíduos sem construir integrações personalizadas para cada mercado. Provedores locais de software de gestão de resíduos trazem sua experiência de domínio e relacionamento com clientes; a Rede Carrot fornece a infraestrutura de verificação e o mercado de créditos.
[Saiba mais sobre a cadeia de suprimentos](/docs/protocol/supply-chain) · [Saiba mais sobre recompensas](/docs/protocol/rewards-distribution)
# Carrot Registry
## O que é o Carrot Registry? [#o-que-é-o-carrot-registry]
O Carrot Registry ([registry.carrot.eco](https://registry.carrot.eco)) é a camada de registro técnico da superfície pública de verificação da Carrot. Ele apresenta dados públicos e auditáveis de forma amigável; os registros gravados no ledger imutável são especificamente identificados como imutáveis. Isso torna as alegações ambientais da Rede Carrot verificáveis de forma independente, sem depender de ferramentas técnicas ou registros brutos de transações.
Dentro do Registry, a consulta e a verificação de registros individuais são o **Explorer**. O nome se refere a essa seção, não à superfície como um todo.
Ao lado do Registry, o **Atlas** é a superfície pública das entidades — uma página por registro, e o endereço gravado nos metadados on-chain de cada registro. Veja [Atlas](#atlas) abaixo.
## Seções principais [#seções-principais]
O Registry é organizado em torno dos conceitos centrais do pipeline de Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)) e do [ciclo de vida dos créditos](/docs/protocol/credit-lifecycle) — desde MassIDs verificados até créditos de reciclagem e de carbono aposentados. As principais seções incluem:
| Seção | O que você pode ver |
| ------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Definições de Framework de Metodologia** | Definições e documentação de frameworks de metodologia (MvF) publicados — as regras operacionais que traduzem uma metodologia validada em lógica de verificação executável. |
| **Regras de Aplicação (MvA)** | Regras da Methodology Verification Application (MvA) — a lógica de verificação executada contra os dados da cadeia de suprimentos. |
| **Verificação de MassID** | Resultados da execução da metodologia — execuções de regras, entradas e resultados para cada verificação de MassID. |
| **Certificados** | Certificados GasID e RecycledID, seus MassIDs de respaldo e saldos de créditos disponíveis. |
| **MassIDs** | Lotes verificados individuais de resíduos — documentos, eventos e metadados. |
| **Homologações de Participantes** | Status de homologação de Integradores e participantes aprovados. |
| **Compras e Aposentadorias de Créditos** | Registros de compras e aposentadorias de créditos, recibos e comprovações de ação ambiental. |
Estas são algumas das seções principais; dados adicionais como saldos de créditos e oferta total de créditos também estão disponíveis no Registry.
Nem tudo o que o Registry exibe é gravado no ledger público imutável. Apenas certos dados são registrados nele — por exemplo, [MassIDs](/docs/protocol/mass-ids) registrados, [Certificados](/docs/protocol/certificates) e [créditos](/docs/protocol/credits) emitidos, recibos de compra e aposentadoria e compromissos de recompensas. Definições de frameworks de metodologia, regras de aplicação (MvA), resultados de execução de metodologia (execuções de regras e entradas), documentos e eventos da cadeia de suprimentos, e homologações de participantes são mantidos e exibidos pela plataforma; o Registry apresenta tanto dados do ledger quanto dados da plataforma em um só lugar.
Dos dados exibidos, os MassIDs são os únicos registros inseridos diretamente por [Integradores](/docs/protocol/network-integrators) — eles enviam dados da [cadeia de suprimentos](/docs/protocol/supply-chain) via a [Carrot API](/docs/integrations/api) que a plataforma processa em lotes verificados de resíduos. [Frameworks de metodologia](/docs/standard/concepts/mvf) (MvF), [regras de aplicação](/docs/standard/concepts/mva) (MvA), [execuções de metodologia](/docs/protocol/methodology-execution), Certificados, créditos, [compras de créditos](/docs/protocol/credit-purchase) e [aposentadorias de créditos](/docs/protocol/credit-retirement) são produzidos e registrados pela plataforma.
Registros do ledger — MassIDs registrados, Certificados e créditos emitidos, e recibos de compra e aposentadoria — são respaldados por transações públicas imutáveis e apresentados no Registry com contexto ambiental, para que qualquer pessoa possa rastrear um crédito aposentado de volta através do seu certificado até os MassIDs subjacentes e o trabalho físico que eles representam.
## Atlas [#atlas]
O **Atlas** ([atlas.carrot.eco](https://atlas.carrot.eco)) é a superfície pública das entidades da
Rede Carrot — uma página por registro, em linguagem simples: o lote de resíduos, sua cadeia de
custódia, o certificado e o cálculo por trás dele. Ele encaminha ao Registry para o detalhe técnico
bruto que ele mesmo não exibe.
O Atlas também é onde um link seguido de fora da Carrot chega. Os metadados públicos de cada
registro carregam um endereço do Atlas, então um explorador de blockchain, uma carteira ou um
marketplace que leia um token chega à página daquele registro:
| Endereço | Registro |
| ------------------------------------- | ----------------------------------------------------------- |
| `atlas.carrot.eco/mass-ids/{id}` | Um lote de resíduos verificado |
| `atlas.carrot.eco/certificates/{id}` | Um certificado GasID ou RecycledID |
| `atlas.carrot.eco/verifications/{id}` | A auditoria por trás de um certificado |
| `atlas.carrot.eco/methodologies/{id}` | A metodologia sob a qual um certificado foi emitido |
| `atlas.carrot.eco/credit-orders/{id}` | Uma compra de créditos e seus recibos |
| `atlas.carrot.eco/collections/{id}` | Uma coleção de créditos |
| `atlas.carrot.eco/contracts/{slug}` | Um tipo de registro como um todo — sua descrição de coleção |
Esses endereços são fixados pelos próprios registros que os carregam: cada um fica gravado em
metadados já publicados, então continua resolvendo para registros emitidos no passado. As páginas
para as quais eles resolvem seguem evoluindo.
## Exploradores de blockchain [#exploradores-de-blockchain]
A atividade on-chain — minting de MassIDs e Certificados, emissão de créditos, compras, aposentadorias e distribuição de recompensas — é registrada em uma blockchain pública. Esses dados on-chain podem ser verificados através de qualquer [explorador de blockchain](/docs/glossary#blockchain-block-explorer) (ex.: [PolygonScan](https://polygonscan.com/) para Polygon PoS, que a Carrot utiliza) sem depender da infraestrutura da Carrot.
Um explorador de blockchain exibe transações e interações brutas on-chain, como:
* Emissão e minting de créditos
* Transações de compra e aposentadoria de créditos
* Transferências de tokens e chamadas de contratos
* Distribuição de recompensas e outros eventos de contratos
O Carrot Registry combina dados on-chain com dados da plataforma — como definições de frameworks de metodologia, resultados de execução de regras e homologações — para apresentar uma visão focada no domínio com dados da cadeia de suprimentos e trilhas de auditoria ambiental, para que usuários não técnicos possam verificar e explorar sem ler hashes de transação ou logs de contratos.
| Ferramenta | O que mostra | Depende da Carrot |
| ----------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------- |
| **Carrot Registry** | Dados on-chain (MassIDs, certificados, créditos, compras, aposentadorias) mais dados da plataforma (frameworks e regras de metodologia, resultados de verificação de MassIDs, homologações) — com contexto ambiental | Sim |
| **Explorador de blockchain** (ex.: PolygonScan) | Apenas transações brutas on-chain — emissão de créditos, minting, compras, aposentadorias, distribuição de recompensas, chamadas de contratos, logs de eventos | Não |
## Por que isso importa [#por-que-isso-importa]
O Carrot Registry torna as alegações ambientais da Rede Carrot verificáveis de forma independente. Qualquer pessoa pode rastrear um crédito aposentado de volta através do seu certificado até os MassIDs subjacentes e o trabalho físico que eles representam. Essa transparência ponta a ponta distingue os créditos Carrot dos offsets ambientais tradicionais.
Como os dados on-chain são registrados em uma blockchain pública, a verificação desses dados não depende da disponibilidade da Carrot — qualquer explorador de blockchain pode confirmar os mesmos fatos de forma independente. A [Carrot Foundation](/docs/network/the-foundation) pode usar esses dados para iniciativas como rankings que reconhecem organizações que contribuem para a recuperação de resíduos e o desenvolvimento do mercado de reciclagem.
[Saiba mais sobre dMRV](/docs/protocol/dmrv) · [Saiba mais sobre aposentadoria de créditos](/docs/protocol/credit-retirement)
# Distribuição de Recompensas
## Como as recompensas funcionam [#como-as-recompensas-funcionam]
Quando [uma quantidade de créditos é comprada](/docs/protocol/credit-purchase), os recursos dessa venda são partilhados com cada participante que contribuiu para o trabalho ambiental que esses créditos representam. Este é o mecanismo central de incentivo da Rede Carrot — ele garante que os [participantes da cadeia de suprimentos](/docs/protocol/supply-chain), os [Integradores](/docs/protocol/network-integrators), os [Autores de MvF](/docs/standard/concepts/mvf#o-papel-do-mvf-author) e [Desenvolvedores de MvA](/docs/standard/concepts/mva#o-papel-do-mva-developer) sejam todos recompensados por suas contribuições verificadas.
As recompensas são pagas em [USDC](/docs/glossary#usdc) (uma moeda digital rastreável atrelada ao dólar americano), proporcionando aos participantes **valor estável** sem exposição à volatilidade de preços de mercado. Os participantes podem sacar suas recompensas em moeda fiduciária ou stablecoin de acordo com suas necessidades. Consulte a [Política de Distribuição de Recompensas](/docs/standard/policies/rewards-distribution#moeda-de-pagamento-e-saque) para detalhes completos sobre moeda de pagamento e opções de saque.
## Mecânica de distribuição [#mecânica-de-distribuição]
A distribuição segue a cadeia de custódia do [MassID](/docs/protocol/mass-ids) em três etapas:
### Etapa 1: Divisão por valor de crédito [#etapa-1-divisão-por-valor-de-crédito]
Quando um comprador [adquire uma quantidade de créditos](/docs/protocol/credit-purchase), o pedido é atendido alocando um ou mais [certificados](/docs/protocol/certificates) (cada um lastreado por [MassIDs](/docs/protocol/mass-ids)). Os recursos são divididos entre esses MassIDs proporcionalmente ao valor dos créditos retirados de cada um. Quando todos os créditos retirados têm o mesmo valor unitário — como numa alocação só de reciclagem, em que um crédito é uma tonelada métrica de material certificado — isso se reduz a dividir por peso: um MassID que contribui com 10 kg em uma alocação de 1.000 kg recebe 1% dos recursos daquela alocação. Não se reduz a peso quando uma compra mistura tipos de crédito precificados de formas diferentes, como faz o modelo pareado de carbono e reciclagem.
### Etapa 2: Divisão por função [#etapa-2-divisão-por-função]
A parcela de cada MassID é então distribuída entre todas as categorias de participantes. Cada categoria recebe um percentual definido pela [Política de Distribuição de Recompensas](/docs/standard/policies/rewards-distribution):
| Participante | Chave | Papel na distribuição |
| --------------------------------------- | ----- | ------------------------------------------------------------------------------------------------ |
| **Gerador de Resíduos** | G | Recompensado pela separação na fonte |
| **Gestor de Resíduos** | WM | Recompensado por coordenar e direcionar a destinação dos resíduos |
| **Custodiante de Ponto de Coleta** | BC | Recompensado por fornecer e manter o contentor ou ponto de coleta |
| **Transportador** | H | Recompensado pelo transporte |
| **Processador** | P | Recompensado pela triagem e pré-processamento |
| **Reciclador** | R | Recompensado pela reciclagem certificada |
| **Integrador** | I | Recompensado pela digitalização da cadeia de suprimentos |
| **Autor de MvF** | A | Recompensado pela criação do framework de metodologia (MvF) |
| **Desenvolvedor de MvA** | D | Recompensado pela implementação do framework como MvA (software de verificação executável) |
| **Distribution Fee** | DF | Cobre a gestão de transações e a liquidação e o pagamento das recompensas aos participantes |
| **Registry** | RG | Cobre a emissão e a manutenção dos registros de emissão de créditos e certificados |
| **digital MRV and Integrity Component** | dMRV | Alimenta a Foundation Treasury e sustenta o desenvolvimento do protocolo e a integridade da rede |
Os percentuais totais de todas as categorias sempre somam 100% do valor do MassID. G, WM, BC, H, P e R são [papéis da cadeia de suprimentos](/docs/protocol/supply-chain). O [Gestor de Resíduos](/docs/protocol/supply-chain#waste-manager) coordena a destinação sem assumir a custódia física; os demais papéis desse grupo manuseiam o material. As outras categorias (I, A, D, DF, RG, dMRV) são participantes do ecossistema e componentes de rede que fornecem infraestrutura digital, [frameworks de metodologia](/docs/standard/concepts/mvf), [MvAs](/docs/standard/concepts/mva) e a infraestrutura da rede que viabilizam a execução da metodologia e a geração de créditos. Para a lista completa de participantes, os fundos de destino e os percentuais específicos por tipo de resíduo, consulte a [Política de Distribuição de Recompensas](/docs/standard/policies/rewards-distribution).
### Etapa 3: Alocação aos participantes [#etapa-3-alocação-aos-participantes]
A parcela de cada categoria é enviada ao(s) participante(s) daquela categoria. Se uma categoria possui mais de um participante — por exemplo, dois [Transportadores](/docs/protocol/supply-chain) — a parcela é dividida entre eles. Os componentes de rede (DF, RG, dMRV) não são pagamentos a participantes: a Distribution Fee e o Registry cobrem as operações da rede, e o digital MRV and Integrity Component alimenta a [Foundation Treasury](/docs/glossary#foundation-treasury).
Para resíduos orgânicos, um Gestor de Resíduos confirmado recebe 4%, retirados das categorias
Transportador (1%), Processador (1%) e Reciclador (2%). Sem Gestor de Resíduos confirmado, cada
parcela retorna à origem. Se houver mais de um Gestor de Resíduos confirmado, eles dividem a parcela
de 4% da categoria.
## Confirmação de um Gestor de Resíduos [#confirmação-de-um-gestor-de-resíduos]
Concluir o onboarding como Gestor de Resíduos não cria, por si só, elegibilidade para recompensas. O
Gestor de Resíduos deve declarar os Geradores de Resíduos que atende, e cada gerador deve confirmar
esse vínculo durante o próprio onboarding. As duas partes precisam concluir o onboarding antes que
o vínculo afete a distribuição. Uma declaração unilateral não produz efeito.
## O mecanismo de incentivo: alcançando a fonte [#o-mecanismo-de-incentivo-alcançando-a-fonte]
O mecanismo de distribuição muda drasticamente quando o **Gerador de Resíduos não é identificado** na cadeia de custódia. Isso é intencional — cria um poderoso incentivo para estender a tecnologia de rastreamento até a fonte de geração de resíduos e para incentivar a mudança de comportamento — incentivando os geradores de resíduos na fonte de criação de resíduos a participar de uma melhor triagem e a contratar serviços de reciclagem de alto desempenho.
Quando o Gerador de Resíduos não é identificado:
* **100% da parcela do Gerador de Resíduos** é redirecionada para o **[Community Pool](/docs/glossary#community-pool)** — um fundo discricionário que reinveste valor no crescimento da rede aberta.
* **Todos os outros participantes logísticos e de serviço** (Transportadores, [Processadores](/docs/protocol/supply-chain), [Recicladores](/docs/protocol/supply-chain) e o [Integrador](/docs/protocol/network-integrators) — e o Custodiante de Ponto de Coleta, quando aplicável) recebem um **pagamento com desconto de 25%** em comparação ao que receberiam em uma cadeia de suprimentos totalmente rastreada. Os valores descontados também são direcionados ao Community Pool.
Um Gerador de Resíduos não identificado não pode ser associado a um vínculo confirmado com Gestor
de Resíduos para o MassID. Portanto, o Gestor de Resíduos não recebe parcela nesse caso, e seus 4%
condicionais retornam às categorias Transportador, Processador e Reciclador.
Isso recicla para o crescimento do ecossistema o valor que de outra forma ficaria ocioso, em vez de permitir que seja capturado por qualquer parte privada. Para como a rede organiza seus fundos — [Foundation Treasury](/docs/glossary#foundation-treasury), Community Pool e [Impact Pool](/docs/glossary#impact-pool) — consulte a [Política de Distribuição de Recompensas](/docs/standard/policies/rewards-distribution#fundos-de-destino).
Isso cria um incentivo financeiro direto para que cada participante busque a identificação na fonte. Quando as recompensas de um Transportador são reduzidas porque o Gerador de Resíduos está ausente da cadeia de custódia, esse Transportador tem uma razão concreta para adotar ferramentas que rastreiem os resíduos desde o ponto de geração.
Quando uma cadeia de suprimentos é **totalmente digitalizada** — rastreando os resíduos desde o Gerador de Resíduos em cada etapa até o Reciclador — os participantes elegíveis recebem 100% de suas recompensas alocadas. A elegibilidade do Gestor de Resíduos ainda exige o vínculo confirmado descrito acima. Este é o incentivo econômico que impulsiona a rede em direção à total transparência da cadeia de suprimentos.
## Reivindicação de recompensas [#reivindicação-de-recompensas]
As recompensas são comprometidas on-chain no momento da venda, por meio de um mecanismo de reivindicação com preservação de privacidade. Durante cada compra de créditos, uma raiz de Merkle é registrada no registry público de créditos, representando a distribuição completa de recompensas para aquela transação. Essa raiz compromete a distribuição completa sem revelar valores individuais ou identidades no momento da venda.
As identidades dos participantes permanecem pseudônimas nos registros públicos. O compromisso de recompensa registrado no momento da venda não carrega identificador direto de participante — dentro dele cada participante é um hash com escopo de compra, de modo que as distribuições comprometidas, sozinhas, não podem ser correlacionadas entre compras, e um observador pode verificar que uma distribuição é válida sem determinar qual participante do mundo real corresponde a uma determinada entrada. Essa garantia vale para o compromisso, não para todo registro público: um [MassID](/docs/protocol/mass-ids) publica um identificador estável de participante como hash não reversível, e quando um participante saca, a carteira que reivindica e o valor ficam registrados on-chain, então um participante que reivindica de várias compras com a mesma carteira fica vinculável entre esses saques.
O primeiro pagamento de um participante é liquidado pela Carrot, e é isso que vincula a carteira de saque dele; a partir daí o participante reivindica diretamente contra a prova on-chain. Um saque em stablecoin é liquidado direto a partir dessa reivindicação; um pagamento em moeda fiduciária é realizado por meio de um provedor de pagamento integrado. Cada reivindicação é verificada contra a raiz de Merkle registrada usando uma prova de Merkle, garantindo que o valor da distribuição está correto sem revelar publicamente as identidades dos participantes.
**Auditabilidade**: Embora as identidades dos participantes estejam protegidas da visualização pública, auditores autorizados podem acessar os dados subjacentes para identificar participantes para fins de conformidade e regulatórios. Isso equilibra a privacidade individual com os requisitos de prestação de contas dos mercados de créditos ambientais.
As recompensas são registradas usando **árvores de Merkle** — uma estrutura de dados criptográfica que compromete toda a distribuição em um único valor on-chain (a raiz de Merkle). Isso significa que a distribuição completa de uma compra é representada por um único hash armazenado on-chain, em vez de registrar a recompensa de cada participante individualmente.
A recompensa de cada participante é uma **folha** na árvore. Quando um participante reivindica sua recompensa, ele submete uma prova de Merkle — um caminho criptográfico curto que prova que sua folha específica faz parte da raiz comprometida. O contrato inteligente verifica essa prova on-chain, confirmando que o valor da reivindicação está correto.
As reivindicações requerem **autorização de dupla assinatura**:
1. **Autorização do backend** — Uma assinatura do backend da plataforma confirmando a identidade do participante e conformidade KYC. Isso impede que carteiras não autorizadas reivindiquem recompensas.
2. **Assinatura do participante** — Uma assinatura da própria carteira do participante, comprovando propriedade. No caminho normal de reivindicação, isso impede que a plataforma movimente fundos sem o participante.
Nesse caminho, nenhuma das partes pode reivindicar recompensas sozinha: o backend não pode pagar recompensas para uma carteira não registrada, e o participante não pode reivindicar sem passar pela verificação de identidade. A recuperação de chave perdida é a exceção — a carteira de saque pode ser reapontada sem a assinatura do participante, então não é a assinatura do participante que protege esse caminho. O que o protege é que as duas etapas ficam atrás de papéis diferentes — um operador solicita a troca, um administrador a executa — e toda troca fica registrada on-chain. Essa separação é disciplina de governança, não garantia no nível da chave: a separação de papéis só é validada na inicialização, e o `DEFAULT_ADMIN_ROLE` pode conceder a si mesmo o papel de operador depois disso (veja [segurança dos smart contracts](/docs/protocol/smart-contracts/security)). Este design garante:
* **Privacidade** — A árvore de Merkle não carrega identificador direto de participante; cada participante aparece nela como um hash com escopo de compra.
* **Verificabilidade** — Cada reivindicação é verificada contra a raiz de Merkle comprometida, garantindo a correção da distribuição.
* **Segurança** — No caminho normal de reivindicação, a dupla assinatura impede reivindicações não autorizadas e a movimentação de fundos por uma só parte; a recuperação de carteira, em vez disso, exige dois papéis distintos, mantidos por partes separadas como disciplina de governança, e fica registrada on-chain.
## Governança das recompensas [#governança-das-recompensas]
O percentual alocado a cada categoria de participante não é fixo — é governado pela [Carrot Foundation](/docs/network/the-foundation) com contribuições dos participantes do ecossistema. Os percentuais podem ser ajustados por tipo de resíduo para otimizar o desempenho da reciclagem em mercados específicos.
Por exemplo, a Foundation poderia aumentar a parcela do Gerador de Resíduos para um fluxo de resíduos em que a coleta é o gargalo, ou ajustar a parcela do Transportador onde o custo de transporte é a barreira para a reciclagem.
***
[Compra de Créditos](/docs/protocol/credit-purchase) · [Cadeia de Suprimentos](/docs/protocol/supply-chain) · [Contratos Inteligentes](/docs/protocol/smart-contracts)
# Cadeia de Suprimentos da Reciclagem
## Visão geral [#visão-geral]
A cadeia de suprimentos da reciclagem é o caminho físico que os materiais percorrem desde a geração de resíduos, passando pela coleta, triagem, transporte e processamento em instalações de reciclagem ou tratamento biológico credenciadas. Compreender esse fluxo é essencial para entender como a [Rede Carrot](/docs/network) gera valor — cada etapa é digitalizada, verificada e recompensada.
O princípio fundamental: **a reciclagem de alto desempenho começa na origem**. Separar e limpar resíduos misturados após a contaminação é caro demais e tecnicamente complexo para a maioria das localidades. O sistema de incentivos da Rede Carrot foi projetado para alcançar o Gerador de Resíduos, porque a triagem na origem é a ação isolada mais impactante para o desempenho da reciclagem.
## Participantes [#participantes]
Sete categorias de papéis definem quem faz o quê na cadeia de suprimentos da reciclagem. Cinco
assumem a custódia física do material; o Gestor de Resíduos coordena a destinação sem custódia, e o
Integrador fornece a ponte de dados:
| Papel | Responsabilidade | Elegibilidade para recompensa |
| ---------------------------------- | ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| **Gerador de Resíduos** | Produz resíduos e realiza a triagem na origem | Sim — uma parcela fixa por tipo de resíduo pelo material separado, reduzida para grandes empresas e para onboarding incompleto |
| **Gestor de Resíduos** | Coordena a destinação sem assumir a custódia física | Sim — 4% em orgânicos quando o vínculo com o gerador está confirmado |
| **Custodiante de Ponto de Coleta** | Gerencia contentores e pontos de coleta | Sim — recompensado pela infraestrutura de contentores |
| **Transportador** | Transporta resíduos entre locais | Sim — recompensado pelo trabalho logístico |
| **Processador** | Separa, acumula e pré-processa materiais | Sim — recompensado pelo trabalho de processamento |
| **Reciclador** | Realiza reciclagem ou tratamento biológico certificado | Sim — recompensado pela reciclagem; também como Processador quando registra os eventos de triagem |
| **Integrador** | Fornece o software logístico que digitaliza a cadeia de suprimentos | Sim — recompensado como provedor de software |
Os participantes frequentemente desempenham múltiplos papéis. Um transportador com sua própria instalação de triagem é tanto Transportador quanto Processador. Um gerador de resíduos que entrega diretamente a um processador também é um Transportador. Um reciclador que também recebe e tria o material é registrado sob os dois papéis — Processador e Reciclador — e é recompensado por cada um. Um Gestor de Resíduos que também transporta material atua como Gestor de Resíduos e Transportador e pode ser recompensado por cada papel executado.
Além dos participantes da cadeia de suprimentos, a Rede Carrot também distribui recompensas para participantes do ecossistema que viabilizam a execução da metodologia e a geração de créditos — tanto para créditos de reciclagem quanto para créditos de carbono: o [Autor do MvF](/docs/standard/concepts/mvf#o-papel-do-mvf-author), o [Desenvolvedor do MvA](/docs/standard/concepts/mva#o-papel-do-mva-developer) e as operações da própria rede (cobrindo infraestrutura de Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)), supervisão da rede e processamento de dados). Veja a [Distribuição de Recompensas](/docs/protocol/rewards-distribution) completa para todas as categorias de participantes.
### Gestor de Resíduos [#gestor-de-resíduos]
O **Gestor de Resíduos** é contratado pelo Gerador de Resíduos para selecionar e contratar
prestadores de serviço, direcionar o material a instalações específicas e reportar conformidade
regulatória. Ele não transporta, separa nem trata o material. Sua contribuição é a decisão de
destinação: pode direcionar o mesmo material ao descarte ou à reciclagem certificada.
Concluir o onboarding como Gestor de Resíduos não cria, por si só, elegibilidade para recompensas. O
Gestor de Resíduos deve declarar os geradores que atende, e cada Gerador de Resíduos deve confirmar
esse vínculo. As duas partes precisam concluir o onboarding antes que o Gestor de Resíduos seja
reconhecido nos ativos daquele gerador. Uma declaração unilateral não produz efeito nas recompensas.
Para resíduos orgânicos, um Gestor de Resíduos confirmado recebe uma parcela de 4%. Se nenhum
estiver confirmado, a alocação permanece com as categorias Transportador, Processador e Reciclador;
se houver mais de um, eles dividem a parcela da categoria. Consulte a
[Política de Distribuição de Recompensas](/docs/standard/policies/rewards-distribution) para ver a
alocação exata e as regras de desconto.
## Fluxo de materiais [#fluxo-de-materiais]
Os materiais se movem pela cadeia de suprimentos através de dois modelos logísticos:
### Transporte local [#transporte-local]
Os transportadores executam múltiplos eventos de coleta ao longo de uma rota porta a porta, coletando resíduos dos geradores e entregando-os a um processador local. O processador valida o conteúdo na entrega, criando ou atualizando [MassIDs](/docs/protocol/mass-ids) para cada tipo de material e peso.
### Transporte de longa distância [#transporte-de-longa-distância]
O material é enviado de um processador para outro, ou de um processador para um reciclador. A transferência é registrada como uma Coleta e uma Entrega cobertas por um único Manifesto de Transporte, com os resíduos validados apenas pela instalação receptora. Embarques de longa distância normalmente transportam volumes maiores de material pré-triado.
Em cada ponto de transferência, o receptor atua como [Validador](/docs/protocol/dmrv#validators-and-supply-chain-events), confirmando o conteúdo do material e atualizando a cadeia de custódia do MassID. Essa validação em cada transferência é o que cria a Proof-of-Physical-Work que sustenta a geração de créditos.
## Alcançando a origem [#alcançando-a-origem]
A [distribuição de recompensas](/docs/protocol/rewards-distribution) da Rede Carrot é especificamente projetada para alcançar o gerador de resíduos — a origem da criação de resíduos. Isso é fundamental porque:
* **Geradores de resíduos precisam de incentivos para separar** — Sem feedback sobre a qualidade da triagem e recompensas financeiras pela participação, não há razão para indivíduos e empresas separarem diligentemente.
* **Dados da origem viabilizam o Pay-As-You-Throw** — Quando os resíduos são pesados e rastreados desde o ponto de geração, cada gerador paga precisamente pelo que produz, criando incentivos diretos para a redução de resíduos.
* **A triagem na origem transforma a economia da reciclagem** — Remover a contaminação por resíduos orgânicos dos fluxos recicláveis pode melhorar as taxas de recuperação em 2-4x nas instalações de triagem subsequentes.
As recompensas de reciclagem certificada, distribuídas pela cadeia de custódia do [MassID](/docs/protocol/mass-ids), fornecem o incentivo econômico para que os geradores separem corretamente e permaneçam engajados com o sistema.
## O papel do Reciclador [#o-papel-do-reciclador]
O Reciclador ocupa uma posição especial na cadeia de suprimentos. Um Reciclador é um processador que foi **credenciado** por auditores terceirizados para realizar reciclagem certificada para um tipo específico de material residual.
* Uma fábrica de garrafas de vidro que usa cacos em seus fornos é um Reciclador de vidro certificado — não pode reciclar plástico.
* Uma instalação de tratamento biológico que transforma resíduos alimentares em composto é um Reciclador de resíduos alimentares certificado — não pode reciclar eletrônicos.
Somente quando os MassIDs chegam a um Reciclador credenciado e passam pelo processo de validação do dMRV é que se tornam elegíveis para a emissão de [Tokenized Recycling Credits (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc) e [Tokenized Carbon Credits (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc).
## Como a cadeia de suprimentos gera valor [#como-a-cadeia-de-suprimentos-gera-valor]
A cadeia de suprimentos da reciclagem gera valor conectando geradores de resíduos que precisam de serviços de descarte com compradores de créditos que precisam de compensações ambientais — e recompensando cada contribuidor verificado no processo:
* **Geradores de Resíduos** ganham visibilidade sobre sua pegada de resíduos, recebem recompensas pela triagem e podem demonstrar conformidade com regulamentações de resíduos.
* **Gestores de Resíduos** recebem uma parcela por direcionar resíduos orgânicos à reciclagem certificada quando o vínculo com o gerador está confirmado.
* **Custodiantes de Ponto de Coleta** abrem caminho para empresas privadas e parcerias público-privadas patrocinarem redes de contentores, recebendo recompensas de compras de créditos.
* **Transportadores** obtêm novas fontes de receita com rotas dedicadas para tipos específicos de resíduos, complementando a renda tradicional de transporte.
* **Processadores e Recicladores** recebem recursos adicionais provenientes de compras de créditos, além das vendas de materiais existentes, melhorando a economia da reciclagem como serviço profissional.
* **[Integradores](/docs/protocol/network-integrators)** recebem uma parcela das recompensas por fornecer o software logístico que digitaliza a cadeia de suprimentos.
Esse sistema distribuído de recompensas abre o mercado de reciclagem para inovação e atividade empreendedora, garantindo que todos os stakeholders sejam recompensados por sua contribuição ambiental verificada.
[Saiba mais sobre MassIDs](/docs/protocol/mass-ids) · [Saiba mais sobre dMRV](/docs/protocol/dmrv)
### Diagram: supply-chain-participants
Este diagrama mostra a cadeia de custódia física do Gerador de Resíduos ao Custodiante de Ponto de Coleta, Transportador, Processador e Reciclador. O Gestor de Resíduos fica fora desse grupo e se conecta por um vínculo condicional porque coordena a destinação sem manusear o material. O Integrador se conecta ao lado como ponte de dados.
# Ecossistema de Metodologias
## Visão sistêmica [#visão-sistêmica]
O ecossistema de metodologias transforma standards científicos em verificação automatizada e auditável. Cada estágio possui papéis, entradas e saídas definidos:
Para um mapa acessível de todos os papéis ao redor deste pipeline, veja [Papéis no Ecossistema de
Créditos](/docs/protocol/credit-ecosystem-roles).
**Metodologia** (base científica) → **[MvF](/docs/standard/concepts/mvf)** (especificação de verificação) → **[MvA](/docs/standard/concepts/mva)** (implementação em software) → **Orquestração** (avaliação automatizada) → **[Certificados](/docs/protocol/certificates)** (resultados verificados) → **[Créditos](/docs/protocol/credits)** (unidades rastreáveis emitidas no Registry)
Esse pipeline converte dados brutos da [cadeia de suprimentos](/docs/protocol/supply-chain) — coletados por [Integradores](/docs/protocol/network-integrators) por meio de [MassIDs](/docs/protocol/mass-ids) — em créditos de impacto ambiental verificados e negociáveis.
## Standards e metodologias [#standards-e-metodologias]
Um **standard** governa a criação e gestão de metodologias e a emissão de créditos. Sob cada standard há N metodologias; a governança está no nível do standard.
* Onde não existe um standard global estabelecido (ex.: créditos de reciclagem), Carrot assume o papel de standard através do [Carrot dMRV Standard](/docs/standard).
* Para domínios com standards estabelecidos (ex.: carbono — UNFCCC [AMS-III.F](/docs/glossary#ams-iii-f)), Carrot fornece o registry público de créditos e a infraestrutura de Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)) enquanto a metodologia referencia o standard externo.
## Objetos da metodologia [#objetos-da-metodologia]
| Objeto | Definição | Exemplo |
| --------------- | ---------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| **MvF** | Especificação de verificação que define escopo, regras e fórmulas | BOLD Recycling Framework v1.0.1 |
| **MvA** | Software que implementa o MvF como processadores de regras executáveis | Processadores de regras do BOLD Recycling |
| **Certificado** | Saída certificada pela metodologia para um único MassID, confirmando reivindicação ambiental | RecycledID, GasID |
| **Crédito** | Unidade rastreável emitida no registry público de créditos e respaldada por certificados verificados | TRC (ex.: `C-BIOW` do BOLD Recycling), TCC (ex.: `C-CARB.CH4` do BOLD Carbon (CH₄)) |
## Construção de um programa de créditos [#construção-de-um-programa-de-créditos]
Um [**Responsável pelo Programa**](/docs/protocol/credit-ecosystem-roles#program-owner)
lidera a construção de um programa de créditos. Ele avalia o mercado-alvo, coordena o desenvolvimento
da metodologia, do MvF e do MvA e propõe a política de recompensas específica do programa. A proposta
deve seguir o Carrot dMRV Standard e permanece sujeita à Comunidade de Especialistas e aos processos
de governança da Carrot; o Responsável pelo Programa não aprova o próprio programa.
Um [**Desenvolvedor de Rede**](/docs/protocol/credit-ecosystem-roles#network-developer) pode então
ajudar o programa a crescer ao prospectar participantes, coordenar o processo de homologação exigido
pelo framework de metodologia e enviar dados comprobatórios. Auditorias independentes permanecem
independentes: o Desenvolvedor de Rede não aprova participantes nem substitui a garantia de terceira
parte.
Esses são papéis de desenvolvimento do programa e da rede, não categorias de recompensa. Nenhum dos
dois recebe recompensas do protocolo ou aparece nos percentuais de distribuição; serviços separados
só podem ser remunerados por contratos fora da distribuição do protocolo.
## Quem pode criar uma metodologia dMRV [#quem-pode-criar-uma-metodologia-dmrv]
Proponentes de metodologias podem ser indivíduos, organizações ou instituições de pesquisa com expertise no domínio da reivindicação ambiental alvo. Criar uma metodologia de dMRV requer:
* **Expertise no domínio** — Compreensão profunda da ciência ambiental e das abordagens de medição
* **Base científica** — Fundamentação em standards internacionais estabelecidos (ex.: metodologias CDM da UNFCCC, diretrizes do IPCC)
* **Alinhamento com o [Carrot dMRV Standard](/docs/standard)** — Todas as metodologias devem atender aos requisitos do Standard para rastreabilidade, adicionalidade e transparência
### Qualificações do proponente [#qualificações-do-proponente]
Proponentes devem demonstrar credenciais adequadas ao tipo de contribuição:
* **Expertise no domínio** — Publicações científicas, certificações ambientais ou experiência demonstrada com metodologias no domínio alvo
* **Capacidade técnica** — Para propostas de MvF: capacidade de estruturar frameworks de verificação com regras testáveis, matrizes de rastreabilidade e políticas de evidência. Para propostas de MvA: capacidade de engenharia de software na stack tecnológica da plataforma
* **Posição institucional** — Histórico limpo, sem inconformidades não resolvidas, conflitos de interesse ou restrições regulatórias
Esses requisitos funcionam como uma barreira de integridade — garantindo que a qualidade da metodologia comece no nível do proponente.
O mecanismo preferencial de entrada é por meio de [Chamadas de Propostas (RFP)](/docs/standard/policies/rfp-process). Para orientação prática sobre como participar, consulte o [Guia de Participação em RFPs](/docs/standard/guides/rfp-participation-guide).
O processo de proposta segue o [ciclo de vida da metodologia](/docs/standard/concepts/lifecycle): proposta, validação pela comunidade, desenvolvimento e implantação em produção.
## Integração e entrada de dados [#integração-e-entrada-de-dados]
Os Integradores são a ponte entre as atividades reais da cadeia de suprimentos e o sistema digital de verificação:
1. Integradores coletam dados da cadeia de suprimentos e submetem documentos MassID via a [Carrot API](/docs/integrations/api).
2. O MvA avalia cada documento contra as regras do framework de metodologia (MvF).
3. Quando os MassIDs passam pela verificação da metodologia, Certificados são gerados.
4. Créditos são emitidos a partir dos Certificados e, quando esses créditos são vendidos, os recursos das vendas são distribuídos como [recompensas](/docs/protocol/rewards-distribution) aos participantes.
Consulte a [documentação da API](/docs/integrations/api) para detalhes de integração.
## Comunidade de Especialistas [#comunidade-de-especialistas]
A Comunidade de Especialistas fornece governança e supervisão científica para o ecossistema de metodologias. Ela opera dentro do framework mais amplo de [participação comunitária progressiva](/docs/network/governance#progressive-community-participation), aplicando as mesmas três fases especificamente à governança de metodologias:
1. **Engajamento** — Participação aberta em discussões, feedback e propostas de metodologias. Qualquer especialista no domínio pode contribuir.
2. **Consultiva** — Painéis de revisão de especialistas avaliam novas propostas de metodologias e revisões de frameworks quanto ao rigor científico e viabilidade prática.
3. **Deliberativa** — Decisões vinculantes de governança sobre aprovação de metodologias, ajustes de escopo e resolução de colisões.
O papel da Comunidade de Especialistas evolui conforme o ecossistema amadurece, com a [Carrot Foundation](/docs/network/the-foundation) expandindo progressivamente a participação comunitária nas decisões de governança.
## Camadas de inteligência da plataforma [#camadas-de-inteligência-da-plataforma]
A plataforma inclui duas camadas de inteligência que apoiam a verificação e a evolução do ecossistema (distintas do corpo de governança da Comunidade de Especialistas):
* **[Carrot Analytic Engine (CaE)](/docs/glossary#cae)** — A camada de avaliação da stack de verificação. O CaE pode analisar saídas do MvA, detectar anomalias, inconsistências e padrões suspeitos em dados e resultados de verificação. Quando o CaE sinaliza irregularidades, a plataforma pode pausar a emissão de créditos, acionar revisão humana ou recomendar revisões de metodologia e regras. O CaE aprimora a qualidade da auditoria, mas não certifica créditos.
* **[Carrot Agentic Advisor (CaA)](/docs/glossary#caa)** — A camada consultiva da stack de verificação. O CaA pode aprender com resultados de verificação e feedback para identificar oportunidades de melhoria, otimização de processos e evolução de metodologias. Pode recomendar ajustes de parâmetros, atualizações de metodologia e melhorias de qualidade a autores, desenvolvedores e organismos de validação. O CaA funciona como um consultor inteligente, não como autoridade.
Essas camadas não substituem as regras da metodologia ou a governança; elas sinalizam e apoiam decisões, e suas saídas podem alimentar o [pacote de evidências digitais](/docs/glossary#digital-evidence-package) quando relevante.
## Integridade e antifraude [#integridade-e-antifraude]
O ecossistema inclui múltiplas camadas de proteção contra dupla contagem e fraude:
* **Detecção de colisões** — O registro de escopo e a revisão pela comunidade evitam que metodologias sobrepostas sejam implantadas. Veja a política de [Metodologias em Colisão](/docs/standard/policies/colliding-methodologies).
* **Regras de unicidade** — Regras de tempo de execução como `waste-mass-is-unique` e `no-conflicting-certificate-or-credit` impedem que a mesma massa de resíduos seja verificada ou creditada duas vezes.
* **Trilhas de auditoria** — Cada resultado de verificação é registrado de forma imutável com os dados exatos avaliados, tornando o sistema auditável de forma independente.
## Interoperabilidade [#interoperabilidade]
As metodologias na Rede Carrot são projetadas para compartilhar infraestrutura:
* **Formato comum de documentos** — Todas as metodologias utilizam MassIDs para dados da cadeia de suprimentos, permitindo padrões de validação consistentes.
* **Bibliotecas de regras compartilhadas** — Processadores de regras para verificações comuns (identificação de atores, pesagem, geolocalização) são implementados uma vez e reutilizados em todas as metodologias.
* **Arquitetura extensível** — Novas metodologias podem construir sobre regras existentes enquanto adicionam lógica específica do domínio (ex.: cálculo de emissões para [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon)).
[Saiba mais sobre o Carrot dMRV Standard](/docs/standard) · [Saiba mais sobre o ciclo de vida da metodologia](/docs/standard/concepts/lifecycle)
### Diagram: layered-architecture
Este diagrama de arquitetura em camadas mapeia responsabilidade, camada e função desde a metodologia científica validada até MvF, MvA, orquestração da Plataforma Carrot e outputs auditáveis. Registry ou terceiros definem o que medir; autores e desenvolvedores traduzem e implementam; a Carrot executa verificações, anomalias CaE, recomendações CaA e pacotes de evidências sob revisão independente de VVBs.
# Ciclo de Vida da Metodologia
## Estágios do ciclo de vida [#estágios-do-ciclo-de-vida]
Toda metodologia de Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)) na [Rede Carrot](/docs/network) — incluindo metodologias de carbono e outras categorias de créditos — segue um ciclo de vida definido, desde a proposta inicial até a operação em produção e eventual descontinuação:
1. **Proposta** — Um proponente submete o conceito da metodologia para avaliação.
2. **Validação** — A Comunidade de Especialistas revisa a proposta quanto ao rigor científico e viabilidade.
3. **Desenvolvimento** — A especificação do [MvF](/docs/standard/concepts/mvf) e a implementação do [MvA](/docs/standard/concepts/mva) são construídas e testadas.
4. **Homologação** — O MvF concluído é avaliado contra [seis dimensões de qualidade](/docs/standard/policies/quality-and-accreditation) e, quando aprovado, formalmente homologado para operação em produção.
5. **Produção** — A metodologia é implantada e começa a processar documentos [MassID](/docs/protocol/mass-ids).
6. **Versionamento** — A metodologia evolui por meio de versões à medida que regras são refinadas ou adicionadas.
7. **Descontinuação** — A metodologia é aposentada quando não é mais válida ou foi substituída.
## Proposta e validação [#proposta-e-validação]
Propostas tipicamente se originam de uma [Chamada de Propostas (RFP)](/docs/standard/policies/rfp-process) — a Carrot publica uma chamada formal com escopo, tipo, requisitos de elegibilidade, critérios de avaliação e cronograma. Seis tipos de RFP cobrem diferentes necessidades de contribuição, desde propostas de resolução de problemas até autoria de MvF e desenvolvimento de MvA. Proponentes também podem entrar via parceria ou submissão direta, sujeitos aos mesmos requisitos de integridade e qualificação. Consulte o [Guia de Participação em RFPs](/docs/standard/guides/rfp-participation-guide) para orientação prática de submissão.
Uma proposta de metodologia deve demonstrar:
* **Base científica** — Fundamentação em standards estabelecidos (ex.: metodologias UNFCCC CDM, diretrizes do IPCC)
* **Adicionalidade** — Evidência de que a atividade verificada gera impacto além do cenário de referência (business-as-usual)
* **Ausência de colisão** — Confirmação de que o escopo proposto não se sobrepõe a metodologias existentes (veja [Metodologias Colidentes](/docs/standard/policies/colliding-methodologies))
* **Alinhamento com o [Carrot dMRV Standard](/docs/standard)** — Conformidade com todos os requisitos do Standard
A Comunidade de Especialistas revisa propostas por meio de fases consultivas e deliberativas, avaliando rigor científico, viabilidade prática e relevância de mercado.
## Desenvolvimento [#desenvolvimento]
Após a validação de uma proposta, duas frentes de trabalho paralelas começam:
* **Autoria do MvF** — Um MvF Author elabora a especificação do framework de verificação, definindo escopo, elegibilidade, regras de validação, fórmulas e uma matriz de rastreabilidade. Veja o [Guia do MvF Author](/docs/standard/guides/mvf-author-guide).
* **Desenvolvimento do MvA** — Um MvA Developer implementa o framework como processadores de regras executáveis, incluindo testes abrangentes com documentos-semente. Veja o [Guia do MvA Developer](/docs/standard/guides/mva-developer-guide).
Ambos os entregáveis são revisados em relação ao Carrot dMRV Standard antes que a metodologia possa avançar para produção.
## Homologação [#homologação]
Antes de entrar em produção, o MvF concluído passa por um [processo formal de homologação](/docs/standard/policies/quality-and-accreditation). O MvF é avaliado contra seis dimensões de qualidade — completude, verificabilidade, rastreabilidade, implementabilidade, auditabilidade e adaptabilidade geográfica. O processo permite até dois ciclos de revisão para o autor endereçar quaisquer não conformidades. Uma vez que todas as dimensões estejam conformes, o MvF é homologado e a metodologia pode avançar para a implantação em produção.
## Produção e operação [#produção-e-operação]
Em produção, a metodologia processa ativamente documentos MassID submetidos por [Integradores](/docs/protocol/network-integrators):
* Cada MassID é avaliado contra todas as regras do MvA da metodologia.
* Cada avaliação de regra — aprovada, reprovada ou escalada para revisão — é registrada na trilha de auditoria com os dados exatos que foram verificados.
* Regras que não podem ser resolvidas digitalmente são escaladas para revisão humana. O MassID fica retido enquanto um revisor aprova ou rejeita cada regra sinalizada com justificativa escrita; se a janela de revisão se encerrar com regras ainda sem revisão, elas são rejeitadas automaticamente e o MassID falha na verificação. Veja [MvF](/docs/standard/concepts/mvf) e o [guia de estrutura mínima do MvF](/docs/standard/guides/mvf-minimum-structure) para saber como um framework declara seus gatilhos de escalada.
* Os MassIDs que passam na verificação de metodologia geram [Certificados](/docs/protocol/certificates), e os [Créditos](/docs/protocol/credits) correspondentes são emitidos.
* Quando os créditos emitidos pela metodologia são comprados, os recursos das vendas são distribuídos como [recompensas](/docs/protocol/rewards-distribution) aos participantes da [cadeia de suprimentos](/docs/protocol/supply-chain), conforme a [Política de Distribuição de Recompensas](/docs/standard/policies/rewards-distribution) válida para toda a rede.
## Versionamento [#versionamento]
Metodologias evoluem por meio de versionamento semântico (SemVer):
* **MAJOR** — Mudanças incompatíveis na lógica de verificação que podem afetar integrações existentes
* **MINOR** — Novas regras adicionadas sem alterar o comportamento das regras existentes
* **PATCH** — Correções de bugs e atualizações de documentação
O MvF e o MvA são versionados independentemente, com o MvA acompanhando a versão MAJOR do MvF. Veja a [Política de Versionamento](/docs/standard/policies/versioning) para detalhes completos.
## Descontinuação [#descontinuação]
Uma metodologia pode ser descontinuada quando não é mais cientificamente válida, foi substituída por uma abordagem mais eficaz ou não está mais operacionalmente ativa. Créditos emitidos antes da descontinuação permanecem válidos e negociáveis.
Veja a [Política de Descontinuação](/docs/standard/policies/discontinuation) para os critérios e o processo completo de descontinuação.
## Evolução da governança [#evolução-da-governança]
A governança das metodologias é liderada pela [Carrot Foundation](/docs/network/the-foundation) com expansão progressiva da participação comunitária. À medida que o ecossistema amadurece, a Comunidade de Especialistas assumirá responsabilidade crescente pela aprovação de metodologias, decisões de versionamento e evolução do Standard.
[Conheça o ecossistema de metodologias](/docs/standard/concepts/ecosystem) · [Conheça o Carrot dMRV Standard](/docs/standard)
# MvA — Methodology Verification Application
## O que é um MvA? [#o-que-é-um-mva]
Um Methodology Verification Application (MvA) é o software que implementa um [Methodology Verification Framework (MvF)](/docs/standard/concepts/mvf) como regras de validação executáveis — incluindo verificações usadas em metodologias de carbono e outras categorias ambientais. Ele recebe documentos de Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)), os avalia contra todas as regras definidas no MvF e retorna resultados PASSED, FAILED ou REVIEW\_REQUIRED com explicações. REVIEW\_REQUIRED é o resultado indeterminado: a regra não conseguiu resolver a questão por conta própria, então a execução pausa para uma decisão humana registrada (veja [Execução da Metodologia](/docs/protocol/methodology-execution)).
A distinção principal: o MvF é a **especificação** (o que verificar), o MvA é a **implementação** (o código que verifica).
**Metodologia** (base científica) → **[MvF](/docs/standard/concepts/mvf)** (especificação de verificação) → **MvA** (implementação em software)
## O que um MvA faz [#o-que-um-mva-faz]
Um MvA processa documentos [MassID](/docs/protocol/mass-ids) por meio de seu conjunto de regras:
1. **Valida documentos da cadeia de suprimentos** — Cada regra inspeciona aspectos específicos de um MassID: identidades dos atores, dados de eventos, registros de pesagem, manifestos, geolocalização e mais.
2. **Aplica regras de cálculo** — Certas regras realizam cálculos como quantificação de emissões (reduções de CO2e) ou medições de distância geográfica.
3. **Alimenta o sistema de auditoria** — Cada avaliação de regra produz um resultado rastreável com os dados exatos que foram verificados e por que passou, falhou ou exige revisão.
Cada regra é uma função determinística: dado o mesmo documento de entrada, a mesma versão da regra e o mesmo contexto de avaliação, ela sempre produz a mesma saída. Isso torna o sistema de verificação totalmente auditável e reproduzível.
## Princípios de design [#princípios-de-design]
O MvA é construído sobre quatro princípios que garantem a integridade da verificação automatizada:
* **Fidelidade** — O MvA espelha o MvF exatamente. Cada regra no MvF tem um processador de regra correspondente no MvA, e a lógica de avaliação corresponde à especificação.
* **Rastreabilidade** — Cada resultado — PASSED, FAILED ou REVIEW\_REQUIRED — é vinculado aos dados de origem específicos que foram avaliados, tornando os resultados verificáveis de forma independente.
* **Determinismo** — Sem aleatoriedade. A saída de uma regra é função de suas entradas e da configuração versionada em que ela foi implantada, então qualquer avaliação pode ser reproduzida exatamente ao ser reexecutada contra a mesma versão da regra e a mesma configuração.
* **Conformidade com padrões** — Todos os MvAs seguem os requisitos do [Carrot dMRV Standard](/docs/standard) para estrutura, testes e documentação.
## Arquitetura [#arquitetura]
O MvA é implementado como um monorepo open-source implantado como funções serverless:
* **Repositório**: [github.com/carrot-foundation/methodology-rules](https://github.com/carrot-foundation/methodology-rules)
* **Licença**: LGPL-3.0 — qualquer pessoa pode auditar, fazer fork ou contribuir
O código segue uma arquitetura de duas camadas:
* **Bibliotecas de regras compartilhadas** — Contêm a lógica de verificação real. Processadores de regras compartilhados são reutilizados entre metodologias. Cada regra é um módulo independente com seus próprios testes.
* **Wrappers de aplicação de metodologia** — Camadas finas de implantação que encapsulam bibliotecas compartilhadas como funções serverless. Cada metodologia implanta seu próprio conjunto de regras, incluindo regras específicas da metodologia.
Essa arquitetura significa que uma regra como `weighing` é implementada uma vez na biblioteca compartilhada e implantada em múltiplas metodologias (ex.: [BOLD Recycling](/docs/methodologies/bold-recycling) e [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon)). Regras específicas da metodologia (como `prevented-emissions`) ficam apenas na camada de aplicação daquela metodologia.
Cada regra é implementada como um processador de regras — uma interface padronizada que segue o mesmo padrão de cinco etapas:
1. **`process()`** — Ponto de entrada que orquestra a avaliação.
2. **`generateDocumentQuery()`** — Constrói a consulta para buscar o documento MassID e dados relacionados.
3. **`collectDocuments()`** — Busca os documentos necessários para avaliação.
4. **`getRuleSubject()`** — Extrai os elementos de dados específicos que a regra precisa avaliar.
5. **`evaluateResult()`** — Aplica a lógica de verificação e retorna PASSED, FAILED ou REVIEW\_REQUIRED com uma explicação.
Esse padrão consistente significa que cada regra no sistema segue a mesma estrutura, tornando o código auditável e extensível.
## Regras do framework vs. regras da aplicação [#regras-do-framework-vs-regras-da-aplicação]
O sistema de metodologias da Carrot utiliza uma arquitetura de regras em duas camadas:
* **Regras do framework** definem **o que** deve ser verificado no nível da especificação. São os requisitos do MvF — por exemplo, "o documento deve ter um valor maior que zero" ou "um ator reciclador deve estar presente."
* **Regras da aplicação** definem **como** a verificação é executada como código open-source. Cada regra de aplicação é uma função independente que avalia um documento [MassID](/docs/protocol/mass-ids) e retorna PASSED, FAILED ou REVIEW\_REQUIRED.
O mapeamento entre as duas camadas não é um-para-um. Uma única regra de aplicação pode satisfazer múltiplas regras do framework (ex.: `mass-id-qualifications` verifica valor, unidade, categoria e tipo do documento em uma única passagem). Inversamente, uma regra do framework pode exigir múltiplas regras de aplicação para verificação completa.
Veja as regras do framework e da aplicação para cada metodologia:
* BOLD Carbon (CH₄): [Regras do Framework](/docs/methodologies/ams-iii-f/bold-carbon) · [Regras da Aplicação](/docs/methodologies/ams-iii-f/bold-carbon/application/application-rules)
* BOLD Recycling: [Regras do Framework](/docs/methodologies/bold-recycling/framework) · [Regras da Aplicação](/docs/methodologies/bold-recycling/framework/application/application-rules)
## O papel do MvA Developer [#o-papel-do-mva-developer]
MvA Developers são engenheiros que implementam e mantêm processadores de regras. O papel requer:
* Proficiência com a linguagem de programação e ferramentas do monorepo
* Compreensão do padrão de processador de regras
* Capacidade de traduzir especificações do MvF em código determinístico
* Práticas rigorosas de teste: testes unitários, testes de integração com documentos seed e testes end-to-end
Consulte o [Guia do MvA Developer](/docs/standard/guides/mva-developer-guide) para o processo de implementação passo a passo.
| Aspecto | MvF | MvA |
| ----------------- | ---------------------------------------------------- | ------------------------------------------------------------- |
| **Natureza** | Documento de especificação | Aplicação de software |
| **Criado por** | Cientistas ambientais e especialistas em metodologia | Desenvolvedores de software |
| **Saída** | Regras como critérios escritos | Resultados PASSED / FAILED / REVIEW\_REQUIRED com explicações |
| **Formato** | PDF / documento estruturado | Funções Lambda em um monorepo Nx |
| **Versionamento** | SemVer do framework (ex.: v1.0.0) | SemVer da aplicação (acompanha o MAJOR do framework) |
| **Revisão** | Community of Experts | Code review + testes automatizados |
[Saiba mais sobre MvF](/docs/standard/concepts/mvf)
# MvF — Methodology Verification Framework
## O que é um MvF? [#o-que-é-um-mvf]
Um Methodology Verification Framework (MvF) é o documento de especificação que define **o quê** e **como** medir, reportar e verificar o impacto ambiental — incluindo reduções de emissões e créditos de carbono — para uma determinada metodologia de Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)). Ele traduz a base científica de uma metodologia em requisitos de verificação estruturados e testáveis.
O MvF se posiciona entre a base científica da metodologia e sua implementação em software:
**Metodologia** (base científica) → **MvF** (especificação de verificação) → **[MvA](/docs/standard/concepts/mva)** (implementação em software)
Enquanto a metodologia descreve a alegação ambiental e a ciência por trás dela, o MvF especifica exatamente quais dados devem ser coletados, quais condições devem ser atendidas e quais fórmulas devem ser aplicadas para verificar essa alegação. O [MvA](/docs/standard/concepts/mva) então implementa essas especificações como código executável.
## Componentes de um MvF [#componentes-de-um-mvf]
Um documento MvF contém estes componentes interconectados que, juntos, definem o procedimento completo de verificação:
| Componente | Finalidade |
| ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------- |
| **Definição de escopo** | Define tipos de resíduos elegíveis, métodos de tratamento e limites geográficos |
| **Critérios de elegibilidade** | Especifica quais participantes, instalações e atividades se qualificam |
| **Regras de validação** | Declara cada verificação como uma condição PASSED / FAILED / REVIEW\_REQUIRED com critérios claros |
| **Fórmulas** | Define cálculos de emissões e fórmulas de quantificação de créditos |
| **Templates de dados** | Especifica campos e formatos de dados obrigatórios para documentos e eventos de MassID |
| **Matriz de rastreabilidade** | Mapeia cada requisito de verificação à sua fonte de dados, regra de validação e resultado esperado |
| **Política de evidências** | Declara por evento quais evidências são aceitas digitalmente e quais exigem auditoria ou inspeção, com gatilhos de escalonamento |
| **Gatilhos de escalonamento** | Define condições (inconsistência, ausência, anomalia) que escalonam a verificação de forma automatizada para revisão humana |
## Design para verificação [#design-para-verificação]
O MvF é escrito com um princípio central: **design para verificação**. Cada regra, critério e parâmetro deve ser expresso de modo que alguém — seja o [MvA](/docs/standard/concepts/mva) em execução automatizada ou um auditor em revisão independente — possa determinar, com base em evidências, se o requisito foi atendido.
Isso significa:
* **Sem ambiguidade** — Sem espaço para múltiplas interpretações
* **Estruturado por eventos** — O que precisa ser verificado em cada etapa
* **Orientado a evidências** — O que comprova cada requisito
* **Compatível digitalmente** — O que a plataforma pode validar automaticamente e o que requer auditoria ou inspeção
## Matriz de rastreabilidade [#matriz-de-rastreabilidade]
O MvF deve incluir uma **Matriz de Rastreabilidade** como artefato obrigatório. Essa matriz conecta cada requisito da metodologia validada por terceiros ao elemento operacional correspondente no MvF.
Para cada requisito, a matriz mapeia:
**Requisito externo** (seção da metodologia, versão, cláusula) → **Seção do MvF** → **Eventos de dMRV associados** → **Evidências requeridas** → **Validações planejadas** → **Resultados esperados**
A matriz torna a tradução metodológica transparente e auditável — qualquer revisor pode percorrer o caminho completo da referência externa à implementação operacional. Ela também reduz a fricção para o [Desenvolvedor do MvA](/docs/standard/concepts/mva), pois minimiza a ambiguidade durante a implementação.
Para a especificação completa do que cada seção do MvF deve conter, veja a referência [Estrutura Mínima do MvF](/docs/standard/guides/mvf-minimum-structure).
## Evidências digitais vs. evidências de auditoria [#evidências-digitais-vs-evidências-de-auditoria]
Um dMRV robusto exige clareza sobre como cada requisito é comprovado. O MvF deve declarar explicitamente o regime de evidências, distinguindo:
* **Evidência digital** — Evidência cuja robustez pode ser sustentada por trilhas digitais, metadados e consistência entre eventos, permitindo validação determinística pelo MvA. Exemplo: um registro de pesagem com peso, unidade, timestamp, geolocalização e tipo de balança.
* **Evidência de auditoria/inspeção** — Evidência que, por sua natureza, criticidade ou risco, não pode ser confirmada com confiança apenas por registros digitais. Exemplo: condições físicas de instalações, composição de materiais, calibração de instrumentos.
O MvF especifica, para cada evento, quais metadados mínimos tornam a evidência aceitável, quais validações digitais se aplicam e quais gatilhos escalonam para auditoria. Veja a [Estrutura Mínima do MvF](/docs/standard/guides/mvf-minimum-structure#entradas-evidências-e-política-de-evidências) para a especificação completa da política de evidências.
## Como um MvF se conecta à plataforma [#como-um-mvf-se-conecta-à-plataforma]
O MvF é a especificação autoritativa que a plataforma implementa:
1. Cada regra de validação no MvF se torna um processador de regras independente no MvA — uma função Lambda que avalia documentos [MassID](/docs/protocol/mass-ids).
2. O motor de orquestração direciona os documentos recebidos ao conjunto correto de regras da aplicação (no MvA) com base na metodologia.
3. Cada regra retorna PASSED (com uma explicação do que foi verificado), FAILED (com o motivo específico) ou REVIEW\_REQUIRED (quando a verificação não pode ser resolvida em código e precisa de uma decisão humana registrada).
4. Quando todas as regras passam, os MassIDs que passam na verificação de metodologia geram [certificados](/docs/protocol/certificates), e os [créditos](/docs/protocol/credits) correspondentes são emitidos.
O MvF estabelece o contrato: se o MvA implementar fielmente cada regra do MvF, os resultados de verificação da plataforma são cientificamente válidos e auditáveis.
## O papel do MvF Author [#o-papel-do-mvf-author]
MvF Authors são cientistas ambientais, especialistas em metodologias ou organizações com expertise no domínio da alegação ambiental da metodologia. Escrever um MvF requer:
* Profundo conhecimento da ciência ambiental e das abordagens de medição
* Familiaridade com padrões internacionais relevantes (por exemplo, metodologias CDM da UNFCCC, diretrizes do IPCC)
* Capacidade de traduzir requisitos científicos em regras discretas e testáveis
* Conhecimento dos requisitos do [Carrot dMRV Standard](/docs/standard)
Um MvF Author produz três entregáveis: o documento do framework em si, uma matriz de rastreabilidade vinculando cada requisito à lógica de verificação e diretrizes de verificação para [Integradores](/docs/protocol/network-integrators).
Veja o [Guia do MvF Author](/docs/standard/guides/mvf-author-guide) para o processo passo a passo.
## Exemplo: MvF do BOLD Recycling [#exemplo-mvf-do-bold-recycling]
O MvF (v1.0.1) da metodologia [BOLD Recycling](/docs/methodologies/bold-recycling) demonstra esses componentes na prática:
* **Escopo**: Desvio de resíduos orgânicos de aterros sanitários para compostagem aeróbia no Brasil
* **Elegibilidade**: [Integradores](/docs/protocol/network-integrators), [processadores](/docs/protocol/supply-chain) e [recicladores](/docs/protocol/supply-chain#o-papel-do-reciclador) precisam ter uma homologação aprovada e válida na data da avaliação; a homologação de um [gerador de resíduos](/docs/protocol/supply-chain) é opcional — verificada quando existe; [transportadores](/docs/protocol/supply-chain) não precisam de homologação
* **Regras de validação**: Regras cobrindo validação de documentos, identificação de atores, pesagem, geolocalização, manifestos, homologação e verificações de integridade
* **Fórmulas**: Quantificação de créditos com base na massa compostada verificada
* **Rastreabilidade**: Cada regra vincula-se a uma seção específica do documento do framework
Veja o [catálogo completo de regras do BOLD Recycling](/docs/methodologies/bold-recycling/framework/application/application-rules) e a [especificação do framework](/docs/methodologies/bold-recycling/framework).
## Adaptabilidade geográfica [#adaptabilidade-geográfica]
Uma única metodologia pode ser aplicada a múltiplos territórios — e, na maioria dos casos, será. A base científica e a lógica central de quantificação permanecem as mesmas, mas o contexto regulatório, as classificações de materiais, os requisitos de documentação e os parâmetros técnicos variam por região. O MvF é projetado para acomodar essa variação desde o início, em vez de codificar premissas de uma única jurisdição.
O princípio orientador é o **design for adaptability**: o MvF separa elementos universais (válidos para qualquer território) dos elementos que devem ser parametrizados por geografia, permitindo que o framework mantenha sua integridade estrutural enquanto acomoda as variações necessárias por meio de um artefato complementar: o **[Anexo Geográfico](/docs/glossary#geographic-annex)**.
### Por que a adaptabilidade geográfica importa [#por-que-a-adaptabilidade-geográfica-importa]
A adaptabilidade se manifesta em quatro dimensões:
1. **Regulatória** — Cada território possui seu próprio arcabouço legal que governa a atividade da metodologia. Licenciamento ambiental, alvarás operacionais e obrigações de conformidade diferem por jurisdição. Uma regra que diz "o participante deve possuir licença ambiental válida" não pode ser implementada de forma determinística em escala global, a menos que o MvF especifique que o tipo de licença, a autoridade emissora e os campos de validação são provenientes de uma fonte territorial.
2. **Classificação de materiais** — As taxonomias de resíduos são locais: o Brasil usa a Lista Brasileira de Resíduos Sólidos, a UE usa a Lista Europeia de Resíduos (códigos de 6 dígitos), os EUA usam categorias RCRA. Uma regra de elegibilidade referenciando "classificação oficial de resíduos" é universal na intenção, mas territorial na operacionalização.
3. **Parâmetros técnicos** — Fatores de emissão, coeficientes climáticos, padrões de infraestrutura e valores de referência variam por geografia. Uma metodologia de evitação de metano pode usar fatores de um inventário nacional de GEE ou defaults do IPCC — a escolha impacta diretamente a quantidade de créditos.
4. **Evidências e documentação** — Documentos que sustentam a cadeia de custódia diferem por país. O MTR brasileiro (Manifesto de Transporte de Resíduos) não possui nome ou estrutura equivalente em outras jurisdições. O MvF deve especificar o requisito funcional e delegar a especificação formal do documento ao Anexo Geográfico.
### Elementos universais vs. territoriais [#elementos-universais-vs-territoriais]
Cada elemento do MvF é classificado como:
* **Universal** — Definição e condições de verificação são independentes de jurisdição. Exemplos: "o peso registrado deve ser maior que zero", "cada [MassID](/docs/protocol/mass-ids) deve referenciar exatamente um [reciclador](/docs/protocol/supply-chain#o-papel-do-reciclador)", "o intervalo de compostagem deve estar entre 60 e 180 dias". Derivam da lógica da metodologia, não da legislação local.
* **Territorial** — A intenção é universal, mas a operacionalização depende do contexto local. Exemplos: "o participante deve possuir licença ambiental válida" (o tipo de licença é territorial), "o resíduo deve pertencer à lista de subtipos elegíveis" (os códigos de classificação são territoriais), "o manifesto de transporte deve estar presente" (o formato do documento é territorial).
Quando um elemento é classificado como territorial, o MvF deve fornecer: o **requisito funcional** (o que a regra exige em termos de resultado, independentemente do território) e a indicação de que a **especificação operacional** será detalhada no Anexo Geográfico aplicável. Opcionalmente, um valor default se aplica quando nenhum anexo existe para aquele território.
### Redação para adaptabilidade [#redação-para-adaptabilidade]
Três hábitos produzem MvFs adaptáveis:
1. **Redija regras em termos funcionais primeiro** — Em vez de "o participante deve possuir Licença Ambiental de Operação emitida pelo órgão ambiental estadual competente" (operacional, específico do Brasil), escreva "o participante deve possuir licença ambiental de operação vigente, emitida pela autoridade competente no território de aplicação, conforme especificado no Anexo Geográfico aplicável." A primeira formulação funciona apenas no Brasil; a segunda funciona em qualquer lugar.
2. **Classifique cada elemento nos artefatos tabulares** — A Tabela de Regras de Validação, a Tabela de Cálculos e Parâmetros e a Política de Evidências devem incluir uma coluna de **Escopo Geográfico** (`Universal` ou `Territorial`). Isso indica ao [Developer do MvA](/docs/standard/concepts/mva) quais regras são fixas e quais devem consultar o Anexo Geográfico para valores locais.
3. **Declare pontos de interface com o Anexo Geográfico** — Em cada seção do MvF que contenha elementos territoriais, indique o que o anexo deve fornecer. Por exemplo, na seção de Elegibilidade: "o Anexo Geográfico aplicável deve especificar o tipo de licença ambiental exigida, a autoridade emissora, os campos de validação e o prazo de validade aceitável."
### Anexos Geográficos [#anexos-geográficos]
Um [Anexo Geográfico](/docs/glossary#geographic-annex) contextualiza o MvF para um território específico. É construído separadamente do framework, pode ser adicionado, atualizado ou substituído sem modificar o MvF, e é projetado para ser autocontido — o MvF mais um Anexo Geográfico formam uma especificação completa e implementável para um determinado mercado.
Um anexo típico cobre sete dimensões de adaptação:
1. Mapeamento regulatório e legislativo para a atividade da metodologia
2. Classificação de materiais com tradução entre a taxonomia local e as categorias do MvF
3. Requisitos operacionais de conformidade (licenças, alvarás, obrigações de reporte)
4. Análise de adicionalidade e baseline no contexto territorial
5. Adaptação de parâmetros técnicos (fatores de emissão, coeficientes climáticos, valores de referência locais)
6. Critérios de elegibilidade territoriais (traduzindo os requisitos funcionais do MvF em exigências operacionais locais)
7. Mapeamento de interoperabilidade com sistemas locais (manifestos de transporte, registros ambientais, infraestrutura de reporte)
Por exemplo, uma metodologia de compostagem pode ter:
* Um **anexo para o Brasil** — cobrindo licenciamento do [Ibama](/docs/glossary#ibama), manifestos de transporte MTR e o sistema brasileiro de classificação de resíduos sólidos
* Um **anexo para a UE** — mapeando para a Diretiva-Quadro de Resíduos e a Lista Europeia de Resíduos
* Um **anexo para os EUA** — referenciando regulações da EPA, permissões estaduais e categorias de resíduos RCRA
Cada anexo adapta a mesma lógica central de verificação aos requisitos locais sem modificar o framework em si.
### Impacto nos artefatos [#impacto-nos-artefatos]
A classificação de escopo geográfico impacta os artefatos tabulares do MvF:
| Artefato | Coluna adicionada | Valores | Finalidade |
| ------------------------------- | ---------------------------------- | ----------------------- | -------------------------------------------------------------------------------------- |
| Tabela de Regras de Validação | Escopo Geográfico | Universal / Territorial | Indica se a condição verificada e os valores são fixos ou dependem do Anexo Geográfico |
| Tabela de Cálculos e Parâmetros | Escopo Geográfico | Universal / Territorial | Indica se os valores dos parâmetros são fixos ou variam por território |
| Política de Evidências | Escopo Geográfico | Universal / Territorial | Indica se o tipo de evidência ou documento é fixo ou depende do Anexo Geográfico |
| Checklist de Completude | Seção de Adaptabilidade Geográfica | Sim / Não / N/A | Itens de verificação sobre se o MvF prevê a separação universal/territorial |
Quando um elemento é marcado como "Territorial" na Tabela de Regras, o developer do MvA sabe que a implementação deve consultar uma fonte de dados territorial — em vez de codificar um valor fixo, ele cria uma referência parametrizável. Quando um parâmetro é marcado como "Territorial" na Tabela de Cálculos, o MvF pode fornecer um valor default (tipicamente o valor IPCC ou o mais conservador), mas o MvA deve ser capaz de substituí-lo pelo valor territorial quando disponível.
Para a especificação completa de como a adaptabilidade geográfica é estruturada em cada seção do MvF, consulte a referência de [Estrutura Mínima do MvF](/docs/standard/guides/mvf-minimum-structure).
[Saiba mais sobre o MvA](/docs/standard/concepts/mva) · [Saiba mais sobre o Carrot dMRV Standard](/docs/standard)
### Diagram: mvf-construction-cycle
Este ciclo de construção do MvF agrupa as seções 3.4.1 a 3.4.8 em Enquadramento, Operacionalização e Quantificação e Resultado. Escopo, referência e elegibilidade alimentam eventos, evidências e regras; cálculos levam aos outputs e à matriz de rastreabilidade. A aresta tracejada mostra que a matriz mantém o framework rastreável até a metodologia.
### Diagram: validation-rules-taxonomy
Esta taxonomia parte das Regras de Validação do MvF e as divide em Estrutura, Metodologia e Auditoria. Cada coluna explica o que é verificado, traz exemplos como campos obrigatórios, subtipos elegíveis, distância percorrida, geolocalização e verificação de duplicidade, e mostra a ação típica: rejeição, bloqueio, sinalização ou revisão conforme o tipo de regra.
# Calculadora de Créditos
## Visão geral [#visão-geral]
Use a Calculadora de Créditos para estimar os créditos de carbono [`C-CARB.CH4`](/docs/protocol/credits#tokenized-carbon-credits-tcc) e os créditos de reciclagem [`C-BIOW`](/docs/protocol/credits#tokenized-recycling-credits-trc) gerados pela compostagem de resíduos orgânicos. `C-CARB.CH4` é um Tokenized Carbon Credit (TCC) emitido sob a metodologia [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon); `C-BIOW` é um Tokenized Recycling Credit (TRC) emitido sob a metodologia [BOLD Recycling](/docs/methodologies/bold-recycling). TCC e TRC são as categorias mais amplas, enquanto os símbolos identificam esses créditos específicos.
Selecione um cenário de linha de base, tipo de resíduo e volume para ver as quantidades projetadas de créditos, o cálculo da precificação conjunta, o valor efetivo por `C-BIOW` e uma distribuição ilustrativa dos recursos combinados.
A distribuição ilustrativa de resíduos orgânicos considera um vínculo confirmado com [Gestor de
Resíduos](/docs/protocol/supply-chain#waste-manager). A tabela explica como a parcela de 4% retorna
ao Transportador, ao Processador e ao Reciclador quando não há vínculo confirmado.
## Como funciona a precificação conjunta [#como-funciona-a-precificação-conjunta]
A calculadora modela um pacote comercial: ela precifica a parcela de `C-BIOW` junto a cada `C-CARB.CH4`. A referência combinada de US$ 153,53 é uma projeção de precificação, não uma mudança no [contrato da ordem de compra](/docs/protocol/credit-purchase), que continua identificando o tipo e a quantidade do crédito.
| Componente da precificação | Valor de referência | Base de aplicação |
| ---------------------------- | ------------------: | --------------------------------------------------- |
| `C-CARB.CH4` | US$ 120,00 | Cada `C-CARB.CH4` vendido |
| Parcela de valor do `C-BIOW` | US$ 33,53 | Cada `C-CARB.CH4` vendido, não cada `C-BIOW` físico |
| Combinado | US$ 153,53 | Cada `C-CARB.CH4` vendido com `C-BIOW` proporcional |
O coeficiente de emissão determina quantos `C-BIOW` acompanham cada `C-CARB.CH4`. Portanto, o valor efetivo por `C-BIOW` físico é `US$ 33,53 × coeficiente de emissão`. A tabela comparativa da calculadora aplica essa fórmula a todos os tipos de resíduo compatíveis com o cenário de linha de base selecionado.
## Recursos relacionados [#recursos-relacionados]
* [Parâmetros de cálculo de emissões](/docs/methodologies/ams-iii-f/bold-carbon#parametros-de-calculo-de-emissoes) — metodologia detalhada de cálculo por trás da geração de créditos
* [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) — metodologia para reduções de emissões de metano
* [BOLD Recycling](/docs/methodologies/bold-recycling) — metodologia para desvio de resíduos orgânicos
* [Política de Distribuição de Recompensas](/docs/standard/policies/rewards-distribution) — como os recursos são distribuídos entre os participantes
# Guia do Desenvolvedor de MvA
## Para quem é este guia? [#para-quem-é-este-guia]
Este guia é destinado a desenvolvedores que implementam regras da metodologia para a [Rede Carrot](/docs/network). Ele apresenta como construir uma [Aplicação de Verificação de Metodologia (MvA)](/docs/standard/concepts/mva) — o software que avalia documentos [MassID](/docs/protocol/mass-ids) contra a especificação de um [Framework de Verificação de Metodologia (MvF)](/docs/standard/concepts/mvf).
## Pré-requisitos [#pré-requisitos]
* Proficiência com a linguagem de programação e ferramentas do monorepo
* Compreensão de padrões de funções serverless
* Familiaridade com conceitos de Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)) — incluindo aplicações em metodologias de carbono e outras categorias — e a especificação do MvF que você está implementando
* Conhecimento dos requisitos do [Carrot dMRV Standard](/docs/standard) para desenvolvedores de MvA
## Repositório e ferramentas [#repositório-e-ferramentas]
As [regras da metodologia](/docs/standard/concepts/mvf) são implementadas em um monorepo open-source:
* **Repositório**: [github.com/carrot-foundation/methodology-rules](https://github.com/carrot-foundation/methodology-rules)
* **Licença**: LGPL-3.0
Consulte o README do repositório para instruções de configuração, instalação de dependências e configuração de desenvolvimento local.
## Visão geral da arquitetura [#visão-geral-da-arquitetura]
O código segue uma arquitetura de duas camadas:
* **Bibliotecas de regras compartilhadas** — Contêm a lógica de verificação propriamente dita. Processadores de regras compartilhados são reutilizados em todas as metodologias BOLD. Cada regra é um módulo independente com seus próprios testes.
* **Wrappers de aplicação da metodologia** — Camadas de implantação finas que encapsulam bibliotecas compartilhadas como funções serverless. Cada metodologia implanta seu próprio conjunto de regras, incluindo quaisquer regras específicas da metodologia.
Essa separação significa que regras comuns (como identificação de atores, pesagem ou geolocalização) são implementadas uma vez e reutilizadas, enquanto regras específicas da metodologia (como cálculos de emissões) são isoladas na metodologia alvo.
## Implementando uma regra [#implementando-uma-regra]
### Etapa 1: Criar o projeto [#etapa-1-criar-o-projeto]
Cada regra reside em seu próprio diretório de projeto com uma estrutura de arquivos padrão. Os metadados do projeto incluem tags para descoberta e categorização dentro do monorepo.
### Etapa 2: Implementar o processador [#etapa-2-implementar-o-processador]
Toda regra implementa o padrão de processador de regra — uma interface padronizada com cinco métodos:
1. **`process()`** — Ponto de entrada que orquestra a avaliação.
2. **`generateDocumentQuery()`** — Constrói a consulta para buscar o documento MassID e dados relacionados.
3. **`collectDocuments()`** — Busca os documentos necessários para avaliação.
4. **`getRuleSubject()`** — Extrai os elementos de dados específicos que a regra precisa avaliar.
5. **`evaluateResult()`** — Aplica a lógica de verificação e retorna PASSED, FAILED ou REVIEW\_REQUIRED com uma explicação.
A explicação em `evaluateResult()` é crítica — ela deve declarar o que foi verificado e por que o resultado é PASSED, FAILED ou REVIEW\_REQUIRED. Em um resultado escalado, ela precisa dizer o que a regra não conseguiu resolver, porque é sobre essa explicação que o revisor decide. Essas explicações formam a trilha de auditoria.
### Etapa 3: Escrever testes [#etapa-3-escrever-testes]
Toda regra deve ter cobertura de testes abrangente:
* **Testes unitários** — Testam métodos individuais e casos extremos.
* **Testes de integração com documentos seed** — Testam o fluxo completo de avaliação com documentos MassID realistas.
* **Testes end-to-end** — Testam a função implantada em um ambiente que espelha produção.
### Etapa 4: Criar o wrapper da aplicação [#etapa-4-criar-o-wrapper-da-aplicação]
Para cada metodologia que usa a regra, crie um wrapper de aplicação fino que instancia o processador da biblioteca compartilhada e o exporta como uma função serverless.
## Princípios de design [#princípios-de-design]
Todas as implementações de regras devem seguir estes princípios:
* **Fidelidade** — O código deve implementar fielmente cada regra na especificação do MvF. A lógica em `evaluateResult()` deve corresponder exatamente à especificação.
* **Rastreabilidade** — Todo resultado, seja PASSED, FAILED ou REVIEW\_REQUIRED, deve referenciar os dados específicos que foram avaliados, permitindo verificação de terceiros do resultado.
* **Determinismo** — A mesma entrada deve sempre produzir a mesma saída. Sem aleatoriedade, sem dependência de estado externo que possa mudar entre execuções.
## Requisitos de testes [#requisitos-de-testes]
Antes que uma regra possa ser implantada em produção:
* Todos os testes unitários devem passar
* Testes de integração devem cobrir os cenários principais de PASSED e FAILED, e cada escalada REVIEW\_REQUIRED que o framework define
* Testes end-to-end devem demonstrar que a regra funciona em um ambiente similar à produção
* A regra deve corresponder à entrada correspondente da especificação do MvF na matriz de rastreabilidade
## Implantação [#implantação]
As regras são implantadas como funções serverless através do pipeline de build e implantação do monorepo. Cada metodologia define quais regras estão incluídas em sua configuração de implantação.
Consulte a documentação do repositório para procedimentos de implantação e configuração de ambiente.
[Saiba mais sobre MvA](/docs/standard/concepts/mva) · [Guia do Autor de MvF](/docs/standard/guides/mvf-author-guide)
# Guia do Autor de MvF
## Para quem é este guia? [#para-quem-é-este-guia]
Este guia é destinado a cientistas ambientais, especialistas em metodologia e organizações que propõem novas metodologias de Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)) — incluindo metodologias voltadas a créditos de carbono — para a [Rede Carrot](/docs/network). Ele apresenta o passo a passo para escrever um [Framework de Verificação de Metodologia (MvF)](/docs/standard/concepts/mvf) do zero.
## Pré-requisitos [#pré-requisitos]
Para a especificação completa do que um MvF deve conter — seção por seção — consulte a referência
[Estrutura Mínima do MvF](/docs/standard/guides/mvf-minimum-structure).
Antes de escrever um MvF, você deve ter:
* Expertise no domínio da alegação ambiental que sua metodologia aborda
* Compreensão dos conceitos de dMRV e do [Carrot dMRV Standard](/docs/standard)
* Familiaridade com o [catálogo de metodologias](/docs/methodologies) e metodologias existentes
* Conhecimento de standards internacionais relevantes (ex.: metodologias UNFCCC CDM, diretrizes do IPCC)
## Entregáveis [#entregáveis]
Uma submissão de MvF inclui quatro entregáveis:
1. **Documento do framework** — A especificação completa definindo escopo, elegibilidade, regras de validação, fórmulas e requisitos de dados.
2. **Matriz de rastreabilidade** — Um mapeamento estruturado de cada requisito de verificação à sua fonte de dados e resultado esperado.
3. **Diretrizes de verificação** — Instruções para [Integradores](/docs/protocol/network-integrators) sobre quais dados coletar e como submeter documentos [MassID](/docs/protocol/mass-ids).
4. **Política de evidências** — Uma especificação por evento de evidências obrigatórias, proveniência e retenção, aceitação digital vs. auditoria e gatilhos de escalonamento.
## Etapa 1: Definir o framework [#etapa-1-definir-o-framework]
Comece definindo os limites centrais da sua metodologia:
* **Escopo** — Quais tipos de resíduos, métodos de tratamento e regiões geográficas a metodologia cobre? Seja específico sobre materiais incluídos e excluídos.
* **Critérios de elegibilidade** — Quais participantes, instalações e atividades se qualificam? Defina requisitos para [geradores de resíduos](/docs/protocol/supply-chain), [transportadores](/docs/protocol/supply-chain), [processadores](/docs/protocol/supply-chain) e [recicladores](/docs/protocol/supply-chain).
* **Alegação ambiental** — Qual é o impacto mensurável? (ex.: toneladas de resíduos desviados, reduções de CO2e)
A definição de escopo não deve se sobrepor a metodologias existentes. Consulte a política de [Metodologias Colidentes](/docs/standard/policies/colliding-methodologies).
## Etapa 2: Especificar regras de validação [#etapa-2-especificar-regras-de-validação]
Cada verificação deve ser definida como uma regra com critérios claros de PASSED / FAILED / REVIEW\_REQUIRED:
* **Nome da regra** — Um identificador descritivo (ex.: `weighing`, `driver-identification`)
* **O que verifica** — O elemento de dados ou condição específica sendo verificada
* **Condição PASSED** — Os critérios exatos que devem ser atendidos, sem ambiguidade
* **Condição FAILED** — O que causa a falha da regra, com explicações de erro específicas
* **Condição REVIEW\_REQUIRED** — Quando a regra não pode ser resolvida apenas com os dados submetidos e precisa escalar para uma decisão humana registrada. Declare os critérios explicitamente; uma regra que não define condição de escalada nunca produz um resultado REVIEW\_REQUIRED.
Consulte as regras de framework existentes no [catálogo de metodologias](/docs/methodologies) para referência. Muitas verificações comuns (identificação de atores, pesagem, geolocalização) já possuem definições estabelecidas no nível de framework que podem servir como modelo.
As regras se dividem em três categorias:
* **Regras de estrutura** — Verificam integridade formal e completude dos dados (ex.: campos obrigatórios presentes, unidades corretas). São independentes da metodologia.
* **Regras de metodologia** — Verificam conformidade com os critérios e parâmetros da metodologia (ex.: tipo de resíduo elegível, distância dentro da fronteira do projeto).
* **Regras de auditoria** — Verificam consistência cruzada entre eventos e padrões comportamentais que exigem análise mais profunda (ex.: limites de massa acumulada, verificações de duplicidade).
Para a especificação completa de regra em 12 campos, consulte [Regras de Validação e Controles](/docs/standard/guides/mvf-minimum-structure#regras-de-validação-e-controles).
## Etapa 3: Criar a matriz de rastreabilidade [#etapa-3-criar-a-matriz-de-rastreabilidade]
A matriz de rastreabilidade vincula cada requisito de verificação à sua fonte de dados e resultado esperado:
| Requisito | Fonte de dados | Resultado esperado |
| ---------------------------------- | ------------------------- | ------------------------------------------------------ |
| Gerador de resíduos é identificado | Evento OPEN do MassID | PASSED: origem dos resíduos consistente com os eventos |
| Peso é verificado | Evento WEIGHING do MassID | PASSED: peso líquido validado |
| … | … | … |
Esta matriz garante a completude — cada requisito tem uma fonte de dados correspondente e um resultado verificável. O [MvA](/docs/standard/concepts/mva) implementará posteriormente cada requisito como regras de aplicação executáveis.
## Etapa 4: Escrever as diretrizes de verificação [#etapa-4-escrever-as-diretrizes-de-verificação]
As diretrizes de verificação informam os Integradores sobre quais dados coletar e submeter:
* Quais eventos da [cadeia de suprimentos](/docs/protocol/supply-chain) são obrigatórios (coleta, entrega, pesagem, reciclagem)
* Quais atributos cada evento deve incluir
* Quais documentos e anexos são necessários (manifestos, certificados de homologação)
* Formato de dados e requisitos de submissão via a [API](/docs/integrations/api)
## Etapa 5: Submeter para revisão [#etapa-5-submeter-para-revisão]
Submeta o pacote completo do MvF (documento do framework, matriz de rastreabilidade, diretrizes de verificação e política de evidências) à [Carrot Foundation](/docs/network/the-foundation) para revisão.
O processo de revisão inclui:
1. **Verificação de completude** — Confirmar que todos os entregáveis estão presentes e bem estruturados
2. **Conformidade com o standard** — Garantir alinhamento com o Carrot dMRV Standard
3. **Revisão pela comunidade** — A Comunidade de Especialistas avalia o rigor científico, a viabilidade e possíveis colisões
4. **Aprovação** — A Foundation aprova a metodologia para desenvolvimento do MvA
## Critérios de qualidade [#critérios-de-qualidade]
Uma submissão forte de MvF demonstra:
* **Completude** — Todo aspecto da verificação é especificado, sem lacunas na matriz de rastreabilidade
* **Clareza** — As regras são inequívocas e podem ser implementadas como código determinístico
* **Testabilidade** — Cada regra pode ser validada com casos de teste concretos
* **Sem colisão** — O escopo não se sobrepõe a metodologias existentes
* **Conformidade com o standard** — Todos os requisitos do Carrot dMRV Standard são atendidos
Esses cinco critérios resumem as expectativas principais. Para o framework completo de seis dimensões de qualidade utilizado durante a homologação do MvF — incluindo o processo de avaliação, ciclos de revisão e tipologia de não conformidades — veja [Critérios de Qualidade e Homologação](/docs/standard/policies/quality-and-accreditation).
Feedback e propostas de metodologia: [method@carrot.eco](mailto:method@carrot.eco)
[Saiba mais sobre MvF](/docs/standard/concepts/mvf) · [Guia do Desenvolvedor de MvA](/docs/standard/guides/mva-developer-guide)
# Estrutura Mínima do MvF
## Visão geral [#visão-geral]
Esta página define a estrutura mínima que um [Framework de Verificação de Metodologia (MvF)](/docs/standard/concepts/mvf) deve conter para ser implementável, auditável e governável dentro do ecossistema de Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)) da Carrot — incluindo metodologias voltadas a créditos de carbono e outras categorias. A intenção não é forçar todas as metodologias em um formato rígido, mas garantir que qualquer framework submetido ao ecossistema contenha os blocos essenciais para execução digital consistente, formação de pacote de evidências, validação técnica e padronização.
A estrutura abaixo serve como referência para [Autores de MvF](/docs/standard/concepts/mvf#o-papel-do-mvf-author), como base para avaliação interna pelo time de Operações e Metodologias e — no futuro — para processos de RFP e revisão comunitária. Toda seção segue o princípio de **design for verification**: cada requisito deve ser expresso de forma que a [MvA](/docs/standard/concepts/mva) (em execução automatizada) ou um auditor (em verificação de terceiros) consiga responder, com base em evidências, se o requisito foi atendido.
As oito seções obrigatórias são:
1. [Escopo e conceito](#escopo-e-conceito)
2. [Referência metodológica e registry](#referência-metodológica-e-registry)
3. [Elegibilidade, critérios e exclusões](#elegibilidade-critérios-e-exclusões)
4. [Eventos dMRV e catálogo de eventos](#eventos-dmrv-e-catálogo-de-eventos)
5. [Entradas, evidências e política de evidências](#entradas-evidências-e-política-de-evidências)
6. [Regras de validação e controles](#regras-de-validação-e-controles)
7. [Cálculos, fórmulas e parâmetros](#cálculos-fórmulas-e-parâmetros)
8. [Outputs e pacote de evidências digitais](#outputs-e-pacote-de-evidências-digitais)
***
## Escopo e conceito [#escopo-e-conceito]
O MvF deve começar estabelecendo, de forma transparente, qual problema ambiental ou propósito o dMRV pretende endereçar e qual é o mecanismo de geração de impacto que será quantificado e reportado. Esta seção define o "contrato conceitual" do framework: o que ele mede, em que condições e com quais limites. Sem esse enquadramento, critérios e cálculos posteriores ficam sujeitos a interpretações e se tornam difíceis de verificar.
O autor deve descrever o escopo do dMRV, incluindo:
* **Problema e propósito** — O problema ambiental sendo endereçado e o mecanismo de impacto específico que a metodologia quantifica.
* **Fronteira do sistema** — Quais atividades, etapas do processo ou fluxos estão incluídos na quantificação — e quais são explicitamente excluídos e por quê — em alinhamento com a metodologia validada por terceiros.
* **Unidade de quantificação** — A unidade de medida e o tipo de output esperado no contexto metodológico aplicável (ex.: tCO2e de reduções de emissões, toneladas de material reciclado). O objetivo não é inventar parâmetros, mas indicar claramente o que será contabilizado e como se conecta à referência metodológica.
* **Tipo de output** — Se a metodologia produz [créditos](/docs/protocol/credits), [certificados](/docs/protocol/certificates), ou ambos, e em quais condições.
* **Contexto de aplicabilidade** — Setor, tipo de operação, recorte geográfico, condições operacionais mínimas e quaisquer pressupostos críticos que condicionem a validade do framework. Essa delimitação é essencial para integridade — evita que o dMRV seja aplicado fora do contexto para o qual foi desenhado.
**Saída esperada**: ao final desta seção, qualquer leitor técnico deve conseguir responder claramente: *"O que este dMRV mede, em qual contexto se aplica, qual é sua fronteira e qual output pretende produzir conforme a metodologia validada de referência?"*
***
## Referência metodológica e registry [#referência-metodológica-e-registry]
Após definir escopo e conceito, o MvF deve declarar com precisão **qual metodologia validada por terceiros** fundamenta o dMRV. Isso é crítico para integridade e auditabilidade: o framework não pode "flutuar" sem ancoragem e validação externa, pois é justamente essa referência metodológica que delimita premissas, lógica de quantificação, requisitos de evidência e condições de validade.
O autor deve identificar a metodologia de referência com detalhe suficiente para eliminar ambiguidades, incluindo:
* Nome oficial, versão, data e entidade responsável
* Um identificador permanente ou referência pública estável (ex.: link permanente ou registro equivalente de publicação)
* Anexos, tabelas, apêndices ou versões substitutivas relevantes para os cálculos
Além de apontar a fonte, o MvF deve deixar claro como a metodologia será operacionalizada no framework. Não se trata de repetir o conteúdo da metodologia, mas de explicar a relação entre a referência externa e o MvF: quais seções da metodologia são materialmente relevantes, quais requisitos serão traduzidos em eventos, regras e fórmulas, e quais dependências são assumidas. Esse contexto narrativo prepara o leitor para a Matriz de Rastreabilidade, que faz o mapeamento estruturado requisito a requisito.
Um aspecto importante é registrar os **limites de interoperabilidade**: o que o MvF assume como pré-requisito externo (ex.: validação metodológica, decisões de elegibilidade macro, processos de homologação de participante, regras de registro) versus o que é executado pelo dMRV na plataforma (regras operacionais, validações digitais, evidências e outputs auditáveis). Essa separação mantém a documentação consistente com o posicionamento da Carrot como plataforma de orquestração dMRV.
**Saída esperada**: ao final, deve estar inequívoco qual metodologia externa embasa o dMRV, quais dependências e limites se aplicam, e se existe um registry relacionado — incluindo o papel desse registry e a fronteira entre o que é externo e o que o dMRV executa.
***
## Elegibilidade, critérios e exclusões [#elegibilidade-critérios-e-exclusões]
A definição de critérios de elegibilidade, exclusão e exceção é uma das etapas mais sensíveis na construção de um MvF. Critérios mal formulados geram dois tipos de problema: ou permitem a entrada de participantes e processos que comprometem a integridade dos créditos, ou excluem indevidamente operações legítimas que atendem aos objetivos da metodologia.
O princípio orientador é o **design for verification**: cada critério de elegibilidade deve ser descrito de forma que alguém — seja a [MvA](/docs/standard/concepts/mva) em execução automatizada, seja um auditor em verificação de terceiros — consiga responder, com base em evidências, se o requisito foi atendido, sem margem para interpretação subjetiva.
### Critérios verificáveis vs. narrativos [#critérios-verificáveis-vs-narrativos]
A diferença entre um critério narrativo e um critério verificável é a diferença entre intenção e operacionalidade.
Um **critério narrativo** declara uma condição de forma genérica:
> O participante deve possuir licença ambiental vigente.
Isso comunica a intenção, mas não orienta a verificação: o que significa "vigente"? Qual documento comprova? Que campo ou metadado deve ser validado? Qual é a regra de rejeição? Existe critério de exceção?
Um **critério verificável** descreve a mesma condição em termos que permitem validação objetiva:
> O participante deve submeter documento de licença ambiental emitido por órgão competente, com data de validade igual ou superior à data de início do período de monitoramento. O sistema deve verificar a presença do campo 'data de validade' e comparar com a data de referência do período. Caso a licença esteja vencida ou o campo ausente, o participante é impedido de prosseguir no fluxo de homologação.
Ao escrever cada critério, o Autor do MvF deve se perguntar: *"Se eu entregar apenas esse texto ao developer, ele consegue implementar a validação sem me consultar?"* Se a resposta for não, o critério precisa ser refinado.
### Três camadas de elegibilidade [#três-camadas-de-elegibilidade]
O MvF deve organizar seus critérios em três camadas distintas:
**1. Elegibilidade de participantes** — Requisitos mínimos que cada tipo de participante ([gerador de resíduos](/docs/protocol/supply-chain), [transportador](/docs/protocol/supply-chain), [processador](/docs/protocol/supply-chain), [reciclador](/docs/protocol/supply-chain)) deve atender para ser homologado e operar dentro do dMRV. Tipicamente envolvem:
* Documentação legal e regulatória (licenças, alvarás, registros)
* Capacidade operacional comprovável (capacidade instalada, equipamentos, certificações técnicas)
* Localização geográfica (quando a metodologia tem recorte territorial)
* Vínculos ou impedimentos cadastrais (conflitos de interesse, histórico de não conformidades, restrições regulatórias)
**2. Elegibilidade de materiais e processos** — Quais tipos de resíduos, atividades ou fluxos operacionais o dMRV aceita. Essa definição deve ser precisa o suficiente para evitar ambiguidade. Em vez de "Resíduos Orgânicos", o framework deve especificar as categorias aceitas por código de classificação oficial, condições de aceitação com limites de contaminação, requisitos de separação na fonte e quaisquer restrições aplicáveis (ex.: exclusão de resíduos perigosos ou de origem industrial específica).
**3. Exclusões e exceções** — Exclusões são condições que impedem definitivamente a aprovação, independentemente de outros critérios atendidos. Exceções são situações atípicas, previstas e documentadas, nas quais um critério padrão pode ser flexibilizado sob condições específicas. A distinção é importante: exclusões são absolutas (se o critério de exclusão for atingido, não há caminho alternativo), enquanto exceções devem ser acompanhadas de justificativa, evidência adicional e — quando aplicável — aprovação formal.
### Critérios condicionais e contextuais [#critérios-condicionais-e-contextuais]
Em muitas metodologias, os critérios de elegibilidade não são uniformes — variam conforme o contexto de aplicação. Por exemplo, uma metodologia com abrangência geográfica ampla pode ter requisitos diferentes por país ou região, devido a diferenças regulatórias ou de infraestrutura. O MvF deve declarar explicitamente quais critérios são **universais** (aplicáveis a todos os participantes e contextos) e quais são **condicionais** (aplicáveis apenas sob certas circunstâncias), identificando o gatilho que ativa cada condição.
Da mesma forma, critérios podem ter temporalidade: um requisito que se aplica na homologação inicial pode ser diferente de um requisito de manutenção ou renovação. O framework deve deixar claro em que momento do ciclo cada critério é verificado e com que frequência.
O exemplo de Compostagem Orgânica Municipal (COM) usado ao longo desta página é fictício e
simplificado para fins didáticos. Ele não representa nenhuma metodologia real operada pela
plataforma Carrot e não deve ser usado como referência técnica para desenvolvimento de MvF.
No exemplo fictício COM, a elegibilidade de uma instalação de compostagem seria descrita assim:
As instalações de compostagem são elegíveis para esta metodologia se atenderem cumulativamente aos seguintes critérios: a instalação deve operar com processo de compostagem aeróbica (leiras, composteiras ou reatores aerados); deve possuir licença ambiental de operação vigente emitida pelo órgão ambiental competente; deve estar localizada em território brasileiro; a capacidade operacional declarada na homologação não pode exceder 60.000 toneladas métricas por período de 12 meses; e a instalação deve dispor de balança calibrada e homologada pelo INMETRO para pesagem dos resíduos recebidos.
**Exclusões:**
* Instalações que operem processos de digestão anaeróbica como método primário de tratamento (escopo de outra metodologia)
* Instalações que recebam resíduos classificados como perigosos conforme a norma aplicável
* Instalações cuja distância média ponderada entre o ponto de coleta e o ponto de recebimento exceda 200 km (limite de fronteira do projeto definido pela metodologia de referência)
**Exceção:** Instalações que operem processo misto (compostagem aeróbica com fase inicial de bioestabilização anaeróbica de curta duração, inferior a 72 horas) podem ser aceitas desde que a fase anaeróbica seja documentada, monitorada e considerada nos cálculos de emissão, com evidência técnica de que o processo predominante é aeróbico. Essa exceção deve ser registrada na homologação e sinalizada para auditoria adicional.
**Saída esperada**: ao final desta seção, qualquer leitor técnico — incluindo o developer da MvA e o auditor — deve conseguir responder, para cada tipo de participante e material: *"Este candidato é elegível?", "Sob quais condições?", "O que o impede?"* e *"Há alguma exceção aplicável?"* — sem precisar consultar o autor do framework.
***
## Eventos dMRV e catálogo de eventos [#eventos-dmrv-e-catálogo-de-eventos]
No ecossistema dMRV da Carrot, o **evento** é a unidade fundamental de verificação. Um evento dMRV representa uma ocorrência operacional relevante no fluxo da [cadeia de suprimentos](/docs/protocol/supply-chain) que precisa ser registrada, verificada e rastreada. É no nível do evento que entradas (dados e documentos) ganham significado, validações são aplicadas, evidências são geradas e a trilha de auditoria é construída.
Se o MvF fosse a planta de uma construção, o catálogo de eventos seria a lista detalhada de cada etapa da obra, com materiais necessários, verificações obrigatórias e critérios de aceitação para cada fase. Sem essa lista, o developer da [MvA](/docs/standard/concepts/mva) recebe uma planta sem instruções de execução, e o auditor não sabe quais pontos inspecionar.
### Como identificar eventos relevantes [#como-identificar-eventos-relevantes]
O primeiro passo na construção do catálogo é identificar todos os eventos que compõem o fluxo operacional da metodologia. O autor deve mapear a jornada completa do objeto rastreado (um resíduo, um lote, uma atividade) desde sua origem até sua disposição final ou transformação, considerando todas as movimentações, ações e intervenções que ele pode sofrer.
Cada ponto no fluxo em que ocorre uma das seguintes situações configura, potencialmente, um evento dMRV:
* **Transferência de custódia** — O objeto muda de responsável ou de localização (ex.: coleta, transporte, entrega)
* **Transformação ou processamento** — O objeto sofre alteração física, química ou de classificação (ex.: triagem, compostagem, reciclagem)
* **Mensuração ou registro** — Uma medida é realizada ou um documento é gerado (ex.: pesagem, medição de temperatura, emissão de manifesto ou certificado)
* **Verificação ou auditoria** — Uma regra é aplicada e um resultado é registrado (ex.: auditoria do [MassID](/docs/protocol/mass-ids), emissão de crédito)
* **Decisão ou classificação** — O objeto é classificado, aceito, rejeitado ou reclassificado com base em critérios do framework
### Orientação sobre granularidade [#orientação-sobre-granularidade]
A granularidade dos eventos é uma decisão de design do framework. Eventos muito agregados (ex.: "processamento" como evento único) perdem poder de verificação porque agrupam etapas que poderiam ser validadas separadamente. Eventos excessivamente granulares (ex.: cada minuto de revolvimento de leira como evento separado) geram complexidade operacional sem ganho proporcional de integridade. O equilíbrio ideal é granularidade suficiente para que cada evento represente um **ponto de verificação significativo** — um momento em que algo verificável acontece e uma evidência deve ser registrada.
### Tabela padrão de descrição de eventos [#tabela-padrão-de-descrição-de-eventos]
Para cada evento identificado, o MvF deve fornecer uma descrição estruturada contendo, no mínimo, os seguintes elementos:
| Elemento | Descrição | Finalidade |
| ---------------------------- | --------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| **Identificador** | Código único do evento no catálogo (ex.: EVT-001) | Rastreabilidade e referência cruzada |
| **Nome** | Nome descritivo e padronizado (ex.: Coleta, Pesagem, Entrega) | Comunicação clara entre autor, developer e auditor |
| **Objetivo** | O que este evento comprova ou registra no fluxo | Contextualiza o evento na lógica da metodologia |
| **Etapa do fluxo** | Posição do evento na sequência operacional | Revela dependências e ordem de execução |
| **Participante responsável** | Quem é responsável pela execução ou registro do evento | Define responsabilização e vínculo de custódia |
| **Entradas requeridas** | Dados e documentos que devem ser fornecidos, com metadados mínimos | Base para validação — detalhado em [Entradas, evidências e política de evidências](#entradas-evidências-e-política-de-evidências) |
| **Regras de validação** | Verificações que a MvA deve executar para aceitar/rejeitar o evento | Base para implementação — detalhado em [Regras de validação e controles](#regras-de-validação-e-controles) |
| **Outputs gerados** | O que o evento produz como resultado registrável | Compõe o pacote de evidências digitais |
| **Dependências** | Eventos anteriores que devem estar concluídos ou eventos posteriores que dependem deste | Garante sequência lógica e integridade temporal |
| **Regime de evidência** | Se a verificação é digital (automatizada) ou exige auditoria/inspeção | Orienta o developer e o auditor sobre o nível de verificação |
O exemplo de Compostagem Orgânica Municipal (COM) usado ao longo desta página é fictício e
simplificado para fins didáticos. Ele não representa nenhuma metodologia real operada pela
plataforma Carrot e não deve ser usado como referência técnica para desenvolvimento de MvF.
No exemplo fictício COM, o catálogo de eventos mapeia a jornada completa do resíduo orgânico — desde a coleta no gerador até a conclusão da compostagem e emissão do crédito:
| ID | Evento | Descrição resumida | Participante |
| ------- | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- |
| EVT-001 | Coleta (Pick-up) | Registra o momento em que o resíduo é coletado no gerador pelo transportador. Captura dados do veículo, tipo de resíduo, classificação e geolocalização. | Gerador / Transportador |
| EVT-002 | Manifesto de transporte | Emissão ou registro do documento comprobatório de transporte (MTR ou equivalente). Pode incluir justificativa de isenção quando aplicável. | Gerador / Transportador |
| EVT-003 | Pesagem | Registro da pesagem do resíduo na chegada à instalação de compostagem. Inclui peso bruto, tara, tipo de balança e método de captura. | Processador / Reciclador |
| EVT-004 | Triagem | Registro da etapa de triagem do material recebido, com aplicação do fator de triagem para dedução de contaminantes. Atualiza o peso líquido da massa. | Processador / Reciclador |
| EVT-005 | Entrega (Drop-off) | Registro da entrega efetiva do resíduo na instalação de compostagem, confirmando transferência de custódia. Inclui identificação do operador e destino (leira/pátio). | Processador / Reciclador |
| EVT-006 | Manifesto de reciclagem | Emissão do documento comprobatório de processamento (CDF ou equivalente), confirmando que o resíduo foi efetivamente destinado ao processo de compostagem. | Processador / Reciclador |
| EVT-007 | Compostagem concluída | Registro da conclusão do processo de compostagem, indicando que o resíduo foi transformado em fertilizante orgânico. A data de conclusão é estimada por critério conservador verificado em auditoria. | Processador / Reciclador |
| EVT-008 | Verificação do [MassID](/docs/protocol/mass-ids) | Execução das regras de auditoria sobre o documento de massa, aplicando todas as validações da metodologia para verificar conformidade e integridade. | Regras da metodologia / sistema dMRV da Carrot (verificação); auditores terceirizados (acreditação quando aplicável) |
| EVT-009 | Emissão do crédito | Geração do output metodológico auditável (ex.: GasID para [créditos](/docs/protocol/credits) de carbono, RecycledID para créditos de reciclagem), vinculado ao MassID auditado. | Regras da metodologia / sistema dMRV da Carrot (verificação); auditores terceirizados (acreditação quando aplicável) |
Este catálogo é uma simplificação didática. Em um MvF real, cada evento seria acompanhado de uma ficha detalhada com todos os elementos descritos na tabela padrão (entradas, regras, outputs, dependências). A seção seguinte explica como preencher esses detalhes.
O catálogo de eventos é o principal artefato de handoff entre o Autor do MvF e o Developer da MvA.
Sua completude e clareza determinam diretamente a qualidade da implementação. Um catálogo ambíguo
ou incompleto gera retrabalho, consultas ao autor e risco de divergência entre a intenção do
framework e a execução da aplicação.
***
## Entradas, evidências e política de evidências [#entradas-evidências-e-política-de-evidências]
Se os eventos são a espinha dorsal do dMRV, as entradas e evidências são a substância que os torna verificáveis. Uma **entrada** é o dado ou documento que alimenta um evento; uma **evidência** é o registro que comprova que aquele evento ocorreu em conformidade com as regras do framework. Sem entradas adequadas, o evento não pode ser validado. Sem evidências rastreáveis, o evento não pode ser auditado.
### Especificação de entradas por evento [#especificação-de-entradas-por-evento]
Cada evento do catálogo exige um conjunto de entradas para ser executado. Ao especificar essas entradas, o autor deve ir além de uma lista genérica de "documentos necessários" e fornecer uma descrição operacional completa que permita tanto a implementação na [MvA](/docs/standard/concepts/mva) quanto a verificação por auditores.
Para cada entrada, o MvF deve declarar:
* **Tipo de entrada** — Dado estruturado, documento digitalizado, registro de sistema, declaração assinada, etc.
* **Campos ou metadados obrigatórios** — Ex.: para uma pesagem: peso bruto, tara, peso líquido, tipo de balança, método de captura, data/hora, geolocalização.
* **Formatos e unidades aceitos** — Ex.: peso em quilogramas, datas em formato ISO, valores numéricos com até duas casas decimais.
* **Condições de aceitação** — O que torna a entrada válida (ex.: peso bruto maior que zero, data dentro do período de monitoramento).
* **Condições de rejeição** — O que torna a entrada inválida e impede o prosseguimento do evento.
* **Condições de exceção** — Quais dados são desejáveis vs. obrigatórios, e flexibilidades aceitáveis para projetos iniciais ou tipos específicos de participante.
A diferença entre uma entrada bem especificada e uma entrada vaga separa um framework implementável de um que depende de interpretação.
### Requisitos de metadados [#requisitos-de-metadados]
Toda entrada em dMRV precisa carregar contexto suficiente para sustentar a rastreabilidade. Esse contexto é composto por metadados que respondem às perguntas fundamentais da cadeia de custódia:
* **Quem** submeteu (identificação do participante responsável)
* **Quando** (data e hora do registro)
* **Onde** (geolocalização ou endereço vinculado)
* **Em qual contexto** (evento associado, etapa do fluxo)
* **Sob qual versão** (do MvF e da MvA em execução)
O MvF deve declarar quais metadados são **obrigatórios** (sem os quais a entrada não pode ser aceita) e quais são **opcionais** (enriquecem a rastreabilidade mas não bloqueiam a validação). Em caso de dúvida, a recomendação é tratar o metadado como obrigatório — é mais fácil flexibilizar posteriormente do que criar retroativamente um requisito que não existia.
### Política de evidências por evento [#política-de-evidências-por-evento]
A Política de Evidências consolida, evento por evento, como cada requisito será comprovado. Deve distinguir duas categorias fundamentais: evidências que podem ser aceitas por **verificação digital operacional** (cuja robustez pode ser sustentada pela trilha digital, metadados e consistência entre eventos) e evidências que, pela sua natureza, criticidade ou risco, exigem **auditoria ou inspeção adicional**.
Para cada evento, a política deve registrar:
| Campo | Descrição |
| ----------------------------- | ----------------------------------------------------------------- |
| **Evidência requerida** | Qual evidência deve ser fornecida |
| **Nível de aceitação** | Digital, auditoria, ou ambos |
| **Metadados mínimos** | Quais campos de metadados são obrigatórios |
| **Validações digitais** | Quais verificações automatizadas são realizadas |
| **Gatilhos de escalonamento** | Condições que escalonam o evento para revisão manual ou auditoria |
O exemplo de Compostagem Orgânica Municipal (COM) usado ao longo desta página é fictício e
simplificado para fins didáticos. Ele não representa nenhuma metodologia real operada pela
plataforma Carrot e não deve ser usado como referência técnica para desenvolvimento de MvF.
| Evento | Evidência | Aceitação | Metadados mínimos | Validações digitais | Gatilhos de escalonamento |
| ----------------------------- | --------------------------------------------------------------------------- | -------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- |
| EVT-001 Coleta | Registro digital do pick-up com dados do veículo e classificação do resíduo | Digital | Geolocalização, data/hora, placa do veículo, tipo de resíduo, classificação local, participante responsável | Geolocalização dentro de raio de 2 km do endereço de homologação; classificação dentro da lista de subtipos aceitos | Geolocalização fora do raio; classificação ausente ou inconsistente |
| EVT-003 Pesagem | Registro de pesagem com dados da balança | Digital + Auditoria (homologação da balança) | Peso bruto, tara, peso líquido, tipo de balança, método de captura, data/hora | Peso bruto > 0; unidade = kg; peso líquido = bruto - tara; consistência numérica | Método de captura manual sem justificativa; balança sem homologação vinculada |
| EVT-004 Triagem | Registro de triagem com fator de dedução aplicado | Digital + Auditoria (fator de triagem) | Peso bruto (entrada), peso deduzido, peso líquido (saída), fator de triagem aplicado | Cálculo: peso líquido = peso bruto x (1 - fator de triagem); fator dentro dos limites da homologação | Fator de triagem acima do limite superior; divergência no cálculo |
| EVT-007 Compostagem concluída | Registro de conclusão com data estimada | Digital + Auditoria (validado durante homologação) | Data de conclusão, método de estimativa, participante responsável, referência ao lote/leira | Intervalo entre drop-off e conclusão entre 60 e 180 dias (conforme parâmetro metodológico) | Intervalo fora da faixa; rastreabilidade do lote ausente |
### Categorias de gatilhos de escalonamento [#categorias-de-gatilhos-de-escalonamento]
Gatilhos de escalonamento são condições que, quando detectadas durante a verificação digital, indicam que a evidência disponível não é suficiente para sustentar conformidade e que procedimentos adicionais (auditoria, inspeção, coleta de evidências complementares) são necessários. O Autor do MvF deve definir esses gatilhos de forma explícita e vinculá-los a ações proporcionais ao risco identificado.
Os gatilhos tipicamente se dividem em três categorias:
* **Inconsistência** — Divergência entre dados esperados e fornecidos (ex.: pesagem que resulta em peso líquido negativo, ou geolocalização incompatível com o endereço cadastrado).
* **Ausência** — Falta de metadado obrigatório ou de evidência requerida (ex.: ausência de manifesto de transporte sem justificativa de isenção).
* **Anomalia** — Padrão incomum detectado ao longo do tempo (ex.: volumes sistematicamente superiores à capacidade declarada, ou frequência atípica de isenções).
Para cada gatilho, o MvF deve indicar a ação esperada: **bloqueio do evento** (impedindo a continuidade do fluxo até resolução), **sinalização para revisão operacional** (o evento prossegue, mas é marcado para análise, e a emissão do crédito fica temporariamente bloqueada), ou **escalonamento para auditoria** (o evento é encaminhado para verificação de terceiros). A proporcionalidade entre gatilho e ação é uma decisão de design do framework que deve considerar o risco associado ao evento e a materialidade do impacto na integridade do crédito.
**Saída esperada**: uma Política de Evidências completa, organizada evento por evento, que permita ao developer da MvA implementar todas as validações digitais e ao auditor compreender quais pontos exigem verificação adicional.
***
## Regras de validação e controles [#regras-de-validação-e-controles]
As regras de validação são o mecanismo operacional que garante conformidade entre as entradas fornecidas pelos participantes e os critérios definidos no MvF. Enquanto o [catálogo de eventos](#eventos-dmrv-e-catálogo-de-eventos) define **o que acontece** e a [política de evidências](#entradas-evidências-e-política-de-evidências) define **o que comprova**, as regras de validação definem **como cada entrada é verificada** — qual condição é testada, qual padrão é esperado, o que acontece quando a condição falha e qual evidência é registrada.
Para o developer da [MvA](/docs/standard/concepts/mva), as regras de validação são o elemento mais diretamente implementável de todo o MvF. Cada regra bem especificada se traduz em uma verificação no código — uma condição lógica que produz um resultado binário (aprovado/reprovado) ou um escalonamento (sinalizado para revisão).
### Taxonomia de regras [#taxonomia-de-regras]
A experiência operacional com as metodologias BOLD sugere uma classificação prática de regras em três tipos:
**Regras de Estrutura** verificam a integridade formal e a completude dos dados. Essas regras são independentes da metodologia — asseguram que a "embalagem" da informação está correta antes que o conteúdo seja avaliado. Exemplos:
* Todos os campos obrigatórios estão preenchidos
* A unidade de medida é a esperada (quilogramas)
* O formato numérico é válido
* A categoria do documento corresponde ao esperado
* Metadados de identificação do participante estão presentes e consistentes
**Regras de Metodologia** verificam a conformidade dos dados com os critérios e parâmetros da metodologia científica traduzidos pelo MvF. Essas regras dependem do conteúdo técnico do framework. Exemplos:
* O tipo de resíduo pertence à lista de subtipos elegíveis
* A distância entre coleta e destino não excede o limite da fronteira do projeto
* O intervalo temporal entre eventos está dentro do range aceitável
* O tamanho do projeto não excede o limite de elegibilidade
**Regras de Auditoria** verificam consistência cruzada entre eventos e padrões comportamentais que exigem análise mais profunda e não podem ser resolvidos por verificação determinística simples. Tipicamente envolvem comparação com dados de homologação, cruzamento entre eventos, verificação de duplicidade, controle de limites operacionais e validações que geram sinalizações para revisão humana. Exemplos:
* A somatória de massas de um gerador no mês não excede o teto declarado
* A placa do veículo e a data/hora do drop-off não conflitam com outro [MassID](/docs/protocol/mass-ids)
* O coeficiente de conversão do fertilizante é compatível com os dados de homologação
### Especificação de regra em 12 campos [#especificação-de-regra-em-12-campos]
Para cada regra de validação, o MvF deve fornecer uma especificação que o developer consiga implementar sem interpretação e o auditor consiga verificar de forma independente:
| Elemento | Descrição |
| --------------------------- | ------------------------------------------------------------------------------------------------- |
| **Ordem de execução** | Posição da regra na sequência de verificação do evento (regras podem ter dependências entre si) |
| **Identificador** | Código único da regra (ex.: RV-001) |
| **Nome** | Nome descritivo e padronizado |
| **Evento(s) aplicável(is)** | Em qual(is) evento(s) do catálogo a regra é executada |
| **Condição verificada** | O que a regra testa — descrito em linguagem lógica clara, sem ambiguidade |
| **Critério de aceitação** | O resultado esperado para que a validação seja aprovada |
| **Descrição / Racional** | Explicação do propósito da regra e sua relação com a integridade do dMRV |
| **Tipo de regra** | Estrutura, Metodologia ou Auditoria |
| **Ação em caso de falha** | O que acontece quando a condição não é atendida: rejeição, bloqueio, sinalização ou escalonamento |
| **Caso de exceção** | Se existem situações de exceção, qual gatilho as aciona, e se isso afeta o output |
| **Evidência gerada** | O que fica registrado na trilha de auditoria como resultado da execução da regra |
| **Referência metodológica** | Qual seção da metodologia validada ou do MvF embasa a regra (quando aplicável) |
### Regras com dependência entre eventos [#regras-com-dependência-entre-eventos]
Algumas regras não operam sobre um único evento isolado, mas dependem de informações de múltiplos eventos ou dados históricos. Por exemplo, uma regra de limite de distância (RV-008 no exemplo COM) cruza a geolocalização do evento de coleta (EVT-001) com a do evento de recebimento (EVT-005). Da mesma forma, a regra de teto de massas (RV-009) acumula informações de todos os MassIDs de um mesmo gerador ao longo do mês.
Quando uma regra depende de cruzamento entre eventos, o MvF deve declarar explicitamente: quais eventos são cruzados, quais campos de cada evento são utilizados, qual é a lógica de agregação ou comparação, e em que momento do fluxo a verificação cruzada é executada. Essa clareza é fundamental para implementação determinística e auditoria reproduzível.
O exemplo de Compostagem Orgânica Municipal (COM) usado ao longo desta página é fictício e
simplificado para fins didáticos. Ele não representa nenhuma metodologia real operada pela
plataforma Carrot e não deve ser usado como referência técnica para desenvolvimento de MvF.
| ID | Nome | Condição | Tipo | Ação se falhar |
| ------ | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | ----------- | ---------------------------------------------------------------------------------------- |
| RV-001 | Homologação dos participantes | Todos os participantes vinculados ao MassID devem estar homologados na plataforma, com documentação válida e dentro do prazo. | Auditoria | Bloqueio do MassID até regularização |
| RV-002 | Ausência de crédito prévio | O MassID não pode já ter um crédito do mesmo tipo vinculado (sem TCC duplicado, sem TRC duplicado), evitando dupla contagem. | Metodologia | Rejeição do MassID para emissão |
| RV-003 | Tipo de resíduo elegível | O subtipo do resíduo deve pertencer à lista aprovada pela metodologia (resíduos orgânicos conforme classificação definida). | Metodologia | Rejeição: MassID impedido de gerar créditos |
| RV-004 | Peso do documento > 0 | O valor de peso registrado deve ser maior que zero. | Auditoria | Rejeição |
| RV-005 | Unidade de medida = kg | O campo de unidade deve estar declarado como quilograma. | Estrutura | Rejeição |
| RV-006 | Intervalo temporal de compostagem | A diferença entre o evento Drop-off e o evento Recycled deve estar entre 60 e 180 dias. | Auditoria | Sinalização para revisão operacional |
| RV-007 | Precisão de geolocalização | A geolocalização do pick-up deve estar dentro de um raio de 2 km do endereço cadastrado na homologação. | Auditoria | Sinalização; se GPS indisponível, validação pelo endereço de homologação |
| RV-008 | Limite de distância do projeto | A distância entre o ponto de coleta e o ponto de recebimento não pode exceder 200 km. | Metodologia | Sinalização para revisão; se > 200 km, compensação de emissões de transporte obrigatória |
| RV-009 | Teto de massas do gerador | A somatória de massas do mesmo gerador no mês não pode exceder o teto mensal declarado na homologação (tolerância de até 20%). | Auditoria | Bloqueio para geração de créditos até liberação pelo departamento de operações |
| RV-010 | Verificação de duplicidade | Não devem existir dois MassIDs com mesma data/hora de recebimento, mesmo gerador, mesmo veículo e mesmo pátio de reciclagem. | Auditoria | Rejeição da massa duplicada |
Observe que cada regra tem uma condição testável, um tipo classificado e uma ação clara em caso de falha. Essa é a qualidade mínima esperada na especificação de regras de um MvF. Regras que dizem apenas "verificar se os dados estão corretos" não atendem ao princípio de **design for verification**, porque não definem o que é "correto" nem o que acontece quando não é.
***
## Cálculos, fórmulas e parâmetros [#cálculos-fórmulas-e-parâmetros]
Os cálculos e fórmulas são o núcleo quantitativo do dMRV — traduzem evidências verificadas em resultados numéricos que sustentam a geração de [créditos](/docs/protocol/credits) ambientais. A forma como o MvF especifica suas fórmulas determina não apenas a precisão dos resultados, mas também sua reprodutibilidade, auditabilidade e credibilidade perante o mercado.
O princípio central é a **autocontenção**: o MvF deve fornecer ao developer da [MvA](/docs/standard/concepts/mva) toda a informação necessária para implementar cada cálculo sem precisar consultar a metodologia científica original ou o autor do framework. O MvF mantém rastreabilidade à referência externa, mas o framework em si deve conter todas as informações operacionais necessárias para implementação e auditoria.
### Especificação por fórmula [#especificação-por-fórmula]
Cada fórmula deve ser apresentada com um conjunto mínimo de informações:
**Equação** — Expressa de forma inequívoca, com notação consistente ao longo do framework. Variáveis devem ter nomes descritivos e únicos. Quando a fórmula envolve somatórias, condições (se/então) ou iterações, a lógica deve ser explicitada passo a passo, não condensada em uma única expressão.
**Variáveis** — Para cada variável, o MvF deve declarar:
* Símbolo utilizado
* Nome completo da variável
* Unidade de medida
* Fonte do valor (dado de entrada, parâmetro fixo, resultado de outro cálculo, valor de homologação)
* Condições de aplicação (quando a variável é utilizada e quando não é)
* Limites ou restrições (valores mínimos/máximos, domínio válido)
**Parâmetros fixos** — Fatores de emissão, coeficientes de conversão e constantes devem ser acompanhados de sua fonte primária (artigo, metodologia, base de dados), data de referência e condições sob as quais o valor é válido. Quando um parâmetro varia conforme o contexto (ex.: fator de emissão diferente por tipo de resíduo ou por região), o MvF deve fornecer a tabela completa de valores e a regra de seleção.
**Cenários de teste** — Um conjunto de entradas de referência com o resultado esperado, que permite ao developer verificar se a implementação está correta. Ex.: *"Se peso líquido = 14.949 kg, tipo de resíduo = lodo doméstico, e índice de compensação = 0,85 tCO2e por tonelada, o GasID esperado é 12,71 tCO2e."* Cenários de teste reduzem significativamente o risco de erros de implementação.
O exemplo de Compostagem Orgânica Municipal (COM) usado ao longo desta página é fictício e
simplificado para fins didáticos. Ele não representa nenhuma metodologia real operada pela
plataforma Carrot e não deve ser usado como referência técnica para desenvolvimento de MvF.
No exemplo fictício COM, o cálculo principal quantifica as reduções de emissões de metano alcançadas pelo desvio de resíduos orgânicos de aterros para compostagem aeróbica. Versão simplificada:
**PEcomp,y = PEEC,y + PEFC,y + PECH4,y + PEN2O,y + PERO,y**
Onde cada componente representa, respectivamente: emissões do projeto por consumo de energia (PEEC), por consumo de combustível fóssil (PEFC), emissões de metano da compostagem (PECH4), emissões de óxido nitroso da compostagem (PEN2O) e emissões de metano por efluentes do processo (PERO). Cada componente teria sua própria fórmula detalhada no MvF.
Para uma das variáveis — o índice de compensação utilizado no cálculo do GasID individual de cada [MassID](/docs/protocol/mass-ids) — a especificação no framework seria:
| Elemento | Especificação |
| ------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| **Símbolo** | IC |
| **Nome** | Índice de compensação de emissões de metano |
| **Unidade** | tCO2e / tonelada de resíduo orgânico processado |
| **Fonte** | Derivado dos cálculos da metodologia de referência, conforme tipo de resíduo e parâmetros de compostagem do reciclador |
| **Condição de aplicação** | Aplicado no cálculo do GasID de cada MassID após aprovação na auditoria |
| **Cálculo** | document\_value x IC = GasID (créditos de carbono do MassID) |
| **Regra de verificação** | O IC utilizado deve corresponder ao valor registrado na página de homologação do reciclador para o tipo de resíduo do MassID |
| **Cenário de teste** | Se document\_value = 14.949 kg (14,949 t) e IC = 0,85 tCO2e/t, então GasID = 12,71 tCO2e |
Esse nível de detalhe permite ao developer implementar o cálculo sem ambiguidade e ao auditor verificar se o resultado está correto para qualquer MassID auditado.
### Incerteza e fatores de desconto [#incerteza-e-fatores-de-desconto]
Quando a metodologia de referência prevê margens de incerteza, fatores de desconto conservadores ou buffers de segurança, o MvF deve descrevê-los com a mesma precisão aplicada às fórmulas principais:
* **Fórmula de cálculo da incerteza** (quando quantificável)
* **Fator de desconto aplicado** e sua justificativa técnica
* **Condições de ativação** — Em quais circunstâncias o desconto é aplicado
* **Impacto no resultado final** — Como o desconto afeta a quantidade de créditos gerados
Fatores de desconto são especialmente relevantes para a credibilidade do dMRV porque demonstram uma abordagem conservadora — na dúvida, o framework credita menos, não mais. Essa postura é valorizada por compradores, auditores e pelo mercado, e deve ser explicitada no MvF como parte do design da metodologia.
***
## Outputs e pacote de evidências digitais [#outputs-e-pacote-de-evidências-digitais]
O output metodológico auditável é o resultado final da execução do dMRV: o artefato que justifica, com base em evidências verificadas, que um determinado impacto ambiental foi quantificado em conformidade com a metodologia. Na Rede Carrot, esses outputs são a base para processos subsequentes de emissão, rastreamento e — quando aplicável — aposentadoria de [créditos](/docs/protocol/credits), conforme o desenho institucional adotado.
### Tipos de output [#tipos-de-output]
O MvF deve declarar explicitamente quais tipos de output a metodologia gera e em quais condições:
**Outputs primários** são resultados quantitativos que sustentam a geração de créditos. Ex.: quantidade de reduções de emissões (em tCO2e), quantidade de material reciclado (em toneladas), ou qualquer outra métrica definida pela metodologia. No exemplo fictício COM, os outputs primários seriam o GasID (créditos de carbono por reduções de metano) e o RecycledID (créditos de reciclagem por desvio de aterro).
**Outputs intermediários** são resultados parciais que alimentam cálculos subsequentes ou têm valor informacional para auditoria, mas não geram créditos diretamente. Ex.: o peso líquido após triagem é um output intermediário do evento de triagem que alimenta o cálculo final de créditos.
**Outputs de verificação** são registros gerados pela execução das regras de validação — aprovações, rejeições, sinalizações e resultados de auditoria que compõem a trilha de auditoria do [MassID](/docs/protocol/mass-ids). Esses outputs não geram créditos, mas são essenciais para demonstrar conformidade.
### Composição do pacote de evidências [#composição-do-pacote-de-evidências]
O pacote de evidências digitais é o conjunto organizado de todos os registros, dados, documentos, logs e resultados de validação gerados ao longo da execução do dMRV para um determinado objeto rastreado (tipicamente, um MassID). Ele viabiliza tanto a verificação digital interna quanto a verificação de terceiros por entidades terceiras, quando aplicável.
O MvF deve descrever o que compõe o pacote de evidências para a metodologia, incluindo:
* Dados e documentos submetidos pelos participantes em cada evento (entradas), com seus metadados
* Resultados de cada regra de validação executada (aprovado, reprovado, sinalizado), com a versão do MvF e da MvA utilizada
* Resultados de cada cálculo aplicado, com variáveis e parâmetros de entrada
* Outputs primários gerados, com sua justificativa técnica (como o número foi obtido)
* Registros de qualquer escalonamento, auditoria adicional ou intervenção humana que tenha ocorrido
A completude do pacote de evidências é o que permite a qualquer revisor — interno ou independente — percorrer o caminho completo entre as entradas originais e o output final, verificando cada etapa de forma independente. O MvF deve ser pensado de modo que **nenhum output exista sem uma trilha de evidências que o sustente**.
### Versionamento e rastreabilidade temporal [#versionamento-e-rastreabilidade-temporal]
Cada output gerado pelo dMRV deve carregar informação de versionamento suficiente para permitir sua reprodução futura. No mínimo, o output deve registrar:
* A versão do MvF que definiu as regras aplicadas
* A versão da MvA que executou as regras
* A data de execução
* Referências aos eventos e entradas que o sustentam
Essa rastreabilidade temporal é especialmente importante quando o framework passa por atualizações de versão. Um output gerado sob a versão 1.0 do MvF deve ser avaliado conforme as regras da versão 1.0, mesmo que uma versão 2.0 já esteja em operação. O MvF deve declarar como essa separação é mantida e o que acontece com outputs em trânsito durante uma transição de versão.
### Conexão com processos externos [#conexão-com-processos-externos]
O MvF deve também indicar como os outputs se conectam a processos fora do perímetro da plataforma Carrot, quando aplicável. A plataforma viabiliza a execução de metodologias que suportam a geração de créditos, mas a emissão, o rastreamento e a aposentadoria desses créditos podem envolver infraestruturas externas com formatos e requisitos próprios.
Quando o desenho institucional do dMRV prevê essa interoperabilidade, o MvF deve declarar:
* Quais outputs são entregues a processos externos e em qual formato
* Quais metadados são exigidos pelo registry ou pela infraestrutura de destino
* Quais dependências externas existem (ex.: aprovação do registry necessária antes da emissão formal do crédito)
Essa declaração mantém a separação de responsabilidades clara e permite que a plataforma funcione como infraestrutura de execução sem confundir seu papel com o de certificação ou registro. Veja o [Carrot Registry](/docs/protocol/registry) para como os outputs são apresentados a stakeholders externos.
***
## Artefatos e templates [#artefatos-e-templates]
As seções acima fazem referência a artefatos e templates que devem acompanhar o MvF como anexos padronizados. A tabela abaixo consolida os artefatos recomendados:
| Artefato | Descrição | Seção de referência |
| ------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
| **Matriz de Rastreabilidade** | Conecta requisitos da metodologia validada aos elementos do MvF, mapeando cada requisito para eventos, evidências, validações e outputs. | [Referência metodológica e registry](#referência-metodológica-e-registry) |
| **Catálogo de Eventos dMRV** | Descrição estruturada de todos os eventos do fluxo operacional, com entradas, validações, outputs, dependências e regime de evidência. | [Eventos dMRV e catálogo de eventos](#eventos-dmrv-e-catálogo-de-eventos) |
| **Política de Evidências por Evento** | Tabela que consolida, evento por evento, evidências requeridas, nível de aceitação, metadados mínimos, validações digitais e gatilhos de escalonamento. | [Entradas, evidências e política de evidências](#entradas-evidências-e-política-de-evidências) |
| **Tabela de Regras de Validação** | Lista completa de regras de validação classificadas por tipo (Estrutura, Metodologia, Auditoria), com especificação suficiente para implementação. | [Regras de validação e controles](#regras-de-validação-e-controles) |
| **Tabela de Cálculos e Parâmetros** | Detalhamento de cada fórmula, variável e parâmetro, incluindo fontes, unidades, condições de aplicação e cenários de teste. | [Cálculos, fórmulas e parâmetros](#cálculos-fórmulas-e-parâmetros) |
| **Checklist de Completude do MvF** | Lista de verificação com todos os componentes obrigatórios do MvF conforme a Estrutura Mínima, para autoavaliação pelo autor e avaliação pela curadoria. | Todas as seções |
[Baixe os templates padronizados de artefatos do
MvF](https://drive.google.com/drive/folders/1jvqcUqhTe9FDVhjHsgjUmOjSyez9B6Zd?usp=sharing) —
incluindo a Matriz de Rastreabilidade, Catálogo de Eventos, Política de Evidências, Tabela de
Regras de Validação, Tabela de Cálculos e Parâmetros e Checklist de Completude.
Cada artefato deve ser desenvolvido seguindo o template padronizado para garantir consistência entre os diferentes frameworks submetidos ao ecossistema.
***
[Guia do Autor de MvF](/docs/standard/guides/mvf-author-guide) · [Conceito de MvF](/docs/standard/concepts/mvf) · [Ciclo de Vida da Metodologia](/docs/standard/concepts/lifecycle)
# Guia de Participação em RFPs
Um [RFP](/docs/glossary#rfp) (Request for Proposals) é uma chamada formal em que a [Carrot Foundation](/docs/network/the-foundation) solicita que proponentes qualificados submetam propostas para uma necessidade definida do ecossistema.
Use este guia ao preparar uma proposta. Para entender o processo completo, os tipos de RFP, o ciclo de vida e as regras de participação, comece pelo [Processo de RFP](/docs/standard/policies/rfp-process).
## Como as propostas são avaliadas [#como-as-propostas-são-avaliadas]
A Carrot utiliza uma matriz de avaliação ponderada para garantir que a seleção seja objetiva, documentada e replicável. Cada RFP define seus próprios critérios e pesos, mas a estrutura é sempre a mesma.
### Matriz de avaliação [#matriz-de-avaliação]
Toda proposta é avaliada em até seis dimensões. Cada dimensão recebe uma nota de 1 a 5, multiplicada por um peso que reflete sua importância relativa. A soma ponderada das notas define a pontuação final.
| # | Dimensão | O que é avaliado | Peso típico | Nota |
| :-: | ---------------------------- | -------------------------------------------------------------------------- | :---------: | :--: |
| 1 | **Qualidade técnica** | Rigor, profundidade e viabilidade da abordagem proposta | 25--35% | 1--5 |
| 2 | **Equipe e experiência** | Qualificações, histórico de entregas, capacidade demonstrada | 15--25% | 1--5 |
| 3 | **Viabilidade e cronograma** | Realismo do plano, marcos de entrega, gestão de riscos | 10--20% | 1--5 |
| 4 | **Alinhamento estratégico** | Aderência à missão da Carrot, escalabilidade, governança | 10--20% | 1--5 |
| 5 | **Proposta comercial** | Custo-benefício, estrutura de pagamento, transparência de preço | 5--15% | 1--5 |
| 6 | **Inovação** | Elementos diferenciadores, criatividade, valor agregado além do solicitado | 5--15% | 1--5 |
Os pesos exatos são definidos em cada RFP e sempre somam 100%. Por exemplo, um RFP Tipo A (resolução de problema) pode dar peso maior a qualidade técnica e inovação, enquanto um Tipo B (Projeto via AMC) pode priorizar viabilidade e proposta comercial.
### Escala de pontuação [#escala-de-pontuação]
| Nota | Classificação | Significado |
| :---: | ---------------------- | ------------------------------------------------------------------------------------------------ |
| **5** | Supera as expectativas | Vai além dos requisitos declarados, com abordagem mais robusta, evidências mais claras ou ambos. |
| **4** | Sólido | Atende plenamente aos requisitos e acrescenta pontos fortes relevantes, sem lacunas materiais. |
| **3** | Adequado | Atende aos requisitos com nível aceitável de detalhamento, viabilidade e evidências de suporte. |
| **2** | Limitado | Atende aos requisitos apenas parcialmente, com lacunas que reduzem a confiança na entrega. |
| **1** | Insuficiente | Não atende ao requisito ou apresenta falhas que impedem a proposta de ser aceita. |
### Avaliação em três etapas [#avaliação-em-três-etapas]
**Etapa 1 — Triagem de elegibilidade.** Cada proposta é verificada contra os critérios obrigatórios. Propostas que não atendem aos requisitos são desclassificadas antes da avaliação de mérito, protegendo a objetividade do processo.
**Etapa 2 — Pontuação independente.** Pelo menos dois avaliadores pontuam cada proposta de forma independente usando a matriz de critérios. Nenhum avaliador vê as notas do outro antes de concluir sua avaliação.
**Etapa 3 — Painel de consenso.** Quando há divergência superior a um ponto em qualquer critério, os avaliadores se reúnem para discutir e convergir. O resultado final é a média ponderada consolidada.
A Carrot publica os critérios de avaliação antes do prazo de submissão. Você sabe exatamente como
será avaliado antes de decidir participar.
## Como participar [#como-participar]
### Antes de submeter [#antes-de-submeter]
* **Leia o RFP completo.** Muitas propostas são desclassificadas por não atenderem a requisitos que estavam claramente descritos. Preste atenção especial às seções de elegibilidade, entregáveis e cronograma.
* **Verifique os critérios de elegibilidade.** Se você não atende a algum critério obrigatório, sua proposta será desclassificada na triagem — antes mesmo de ser lida. Certifique-se de que atende a todos.
* **Use o período de perguntas.** Se algo não está claro, pergunte. As respostas são públicas e beneficiam todos os proponentes. Não assuma — pergunte.
* **Consulte a Checklist de Prontidão.** Cada RFP inclui uma checklist dos itens que sua proposta deve conter. Use-a como guia final antes de submeter.
### O que uma boa proposta contém [#o-que-uma-boa-proposta-contém]
Independentemente do tipo de RFP, propostas bem avaliadas geralmente compartilham estas características:
* **Clareza** — A proposta comunica sua abordagem de forma direta, sem jargão desnecessário.
* **Especificidade** — Em vez de promessas genéricas, apresenta detalhes concretos sobre o que será feito, como e quando.
* **Evidências** — Demonstra experiência prévia com exemplos reais, não apenas declarações.
* **Honestidade sobre limitações** — Identifica riscos e propõe mitigações, em vez de ignorar dificuldades.
* **Aderência ao escopo** — Responde ao que foi pedido, sem tangenciar para temas fora do RFP.
### Como submeter [#como-submeter]
Cada RFP especifica o canal de submissão (geralmente [rfp@carrot.eco](mailto:rfp@carrot.eco)), o formato aceito e o prazo final. A submissão deve incluir:
* O documento principal da proposta em PDF, seguindo a estrutura solicitada no RFP
* O Questionário de Submissão preenchido (disponibilizado em formato XLSX junto com o RFP)
* A Checklist de Prontidão preenchida
* Documentos complementares solicitados (CVs, portfólio, certificações, etc.)
Formato do assunto do e-mail: `RFP-CARROT-[YYYY]-[NNN] — [Seu nome ou organização]`
Propostas incompletas ou recebidas após o prazo não serão consideradas. Em caso de dúvida sobre
completude, consulte a Checklist de Prontidão.
## Após o RFP [#após-o-rfp]
### Comunicação de resultados [#comunicação-de-resultados]
Todos os proponentes são notificados sobre o resultado, independentemente de terem sido selecionados. A Carrot comunica:
* A decisão final (selecionado ou não selecionado)
* A pontuação geral da proposta (sem detalhamento por avaliador)
* Feedback resumido sobre pontos fortes e áreas de melhoria, quando aplicável
### Para proponentes selecionados [#para-proponentes-selecionados]
O proponente selecionado entra na fase de contratação, onde são negociados os termos finais — incluindo escopo detalhado, cronograma de entregas, condições para recompensas e termos de uso da plataforma. Após a formalização, inicia-se a fase de execução com acompanhamento periódico pela equipe da Carrot.
**Cláusula de substituição** — Caso o proponente selecionado não possa assumir o compromisso dentro dos termos acordados, ou caso sejam identificadas inconformidades, informações inverídicas ou conflitos de interesse não declarados em qualquer etapa, a Carrot Foundation poderá: (a) convocar o próximo proponente melhor classificado no ranking; ou (b) abrir um novo RFP para o mesmo escopo. A convocação do próximo classificado respeita a ordem de pontuação da avaliação original e está condicionada à manutenção dos critérios de elegibilidade.
### Não foi selecionado? [#não-foi-selecionado]
Participar de um RFP — mesmo sem ser selecionado — tem valor. Você fica visível para a equipe da Carrot, recebe feedback sobre sua proposta e pode usar essa experiência para se fortalecer em chamadas futuras. Muitos dos proponentes mais bem-sucedidos em chamadas subsequentes são aqueles que participaram anteriormente e incorporaram o feedback recebido.
## Biblioteca de RFPs [#biblioteca-de-rfps]
A tabela abaixo é o registro central de todos os RFPs publicados pela Carrot Foundation. Ela é atualizada conforme novas chamadas são abertas ou encerradas.
| Referência | Tipo | Título | Status | Publicação | Prazo |
| --------------------- | :----: | ------------------- | :------: | :--------: | :--------: |
| *RFP-CARROT-2026-001* | *A--F* | *Título da chamada* | *Aberto* | *DD/MM/AA* | *DD/MM/AA* |
**Status possíveis:** Aberto (aceitando propostas), Em Avaliação (prazo encerrado, avaliação em curso), Em Execução (proponente selecionado, trabalho em andamento), Concluído (entregáveis aceitos), Cancelado (chamada cancelada sem seleção).
Entre em contato com [rfp@carrot.eco](mailto:rfp@carrot.eco) para documentos completos de RFPs, indicando a referência da chamada.
## Perguntas frequentes [#perguntas-frequentes]
Sim, desde que atenda aos critérios de elegibilidade de cada chamada e tenha capacidade de
executar caso seja selecionado em mais de um.
Não, salvo quando o RFP explicitamente permitir propostas alternativas. Na dúvida, envie sua
melhor proposta.
Sim. Propostas em consórcio são aceitas, desde que fique claro quem é o proponente líder e quais
são os papéis de cada parceiro.
Sim. A Carrot trata todas as propostas recebidas como confidenciais e não compartilha seu
conteúdo com terceiros ou com outros proponentes.
Envie suas perguntas para [rfp@carrot.eco](mailto:rfp@carrot.eco) durante o período de perguntas indicado no cronograma.
As respostas são publicadas em um FAQ acessível a todos os proponentes.
Não. A Carrot Foundation reserva-se o direito de não selecionar nenhuma proposta, cancelar ou
modificar um RFP a qualquer momento, sem obrigação de justificativa ou compensação.
Novos RFPs são anunciados no site carrot.eco, na Biblioteca de RFPs acima e nos canais oficiais
da comunidade.
[Processo de RFP](/docs/standard/policies/rfp-process) · [Ecossistema de Metodologias](/docs/standard/concepts/ecosystem)
# Colisão de Metodologias
## O que é uma colisão de metodologias? [#o-que-é-uma-colisão-de-metodologias]
Uma colisão de metodologias ocorre quando duas ou mais metodologias de Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)) podem verificar a mesma massa de resíduos, criando um risco de dupla contagem. Por exemplo, se a mesma massa de resíduos pudesse gerar dois créditos de reciclagem (ou dois créditos de carbono) sob metodologias sobrepostas, o impacto ambiental seria contado duas vezes — por isso, um MassID pode ter no máximo um crédito de cada tipo.
A prevenção de colisões é um requisito fundamental do [Carrot dMRV Standard](/docs/standard) e é aplicada em múltiplos níveis: durante a revisão de propostas de metodologias, por meio de regras de validação em tempo de execução e via supervisão de governança.
## Prevenção [#prevenção]
As colisões são prevenidas antes de ocorrerem por meio de salvaguardas estruturais:
* **Registro de escopo** — Cada metodologia declara seus tipos de resíduos elegíveis, métodos de tratamento e limites geográficos. Essas definições de escopo são revisadas quanto a sobreposições antes que uma metodologia entre em produção.
* **Revisão pela comunidade** — A Comunidade de Especialistas avalia novas propostas de metodologias quanto a potenciais sobreposições com metodologias existentes durante a fase de validação do [ciclo de vida da metodologia](/docs/standard/concepts/lifecycle).
* **Salvaguardas técnicas** — Cada massa de resíduos é representada por um [MassID](/docs/protocol/mass-ids) único, garantindo que o mesmo material físico não possa ser submetido sob múltiplas identidades.
## Detecção [#detecção]
Mesmo com medidas preventivas, o sistema inclui regras em tempo de execução que detectam e bloqueiam colisões potenciais:
* **`waste-mass-is-unique`** — Valida que não existem MassIDs duplicados com a mesma combinação de ponto de entrega, ponto de coleta, [reciclador](/docs/protocol/supply-chain#o-papel-do-reciclador), [gerador de resíduos](/docs/protocol/supply-chain) e placa do veículo. Isso evita que a mesma massa de resíduos físicos seja submetida duas vezes.
* **`no-conflicting-certificate-or-credit`** — Valida que um MassID não está vinculado a um [certificado](/docs/protocol/certificates) ou pedido de [crédito](/docs/protocol/credits) válido. Isso evita a dupla contagem no nível de certificação.
Essas regras são executadas automaticamente como parte de cada avaliação do [MvA](/docs/standard/concepts/mva). Um MassID que falhar em qualquer uma das regras não pode receber um certificado.
A Comunidade de Especialistas também monitora padrões de colisão emergentes — casos em que metodologias desenvolvem sobreposição de escopo ao longo do tempo por meio de mudanças de versionamento.
## Processo de resolução [#processo-de-resolução]
Quando uma colisão potencial é identificada, o processo de resolução é conduzido pela governança:
1. **Detecção** — A colisão é identificada por meio de falhas em regras de tempo de execução, monitoramento da Comunidade de Especialistas ou relatórios externos.
2. **Análise** — A [Carrot Foundation](/docs/network/the-foundation) e a Comunidade de Especialistas analisam a sobreposição de escopo e seu impacto.
3. **Determinação de prioridade** — A metodologia verificada primeiro geralmente tem precedência para reivindicações disputadas.
4. **Ajuste de escopo** — A metodologia conflitante deve restringir seu escopo para eliminar a sobreposição.
5. **Implementação** — Atualizações de regras são implantadas para aplicar os escopos ajustados.
À medida que o ecossistema amadurece, a [Carrot Foundation](/docs/network/the-foundation) expandirá progressivamente a participação comunitária nas decisões de resolução de colisões.
## Salvaguardas atuais [#salvaguardas-atuais]
As metodologias BOLD ativas ([BOLD Recycling](/docs/methodologies/bold-recycling) e [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon)) aplicam a prevenção de colisões por meio de suas regras de integridade:
* **`waste-mass-is-unique`** — Compartilhada entre ambas as metodologias, prevenindo submissões duplicadas.
* **`no-conflicting-recycled-id-or-credit`** (BOLD Recycling) — Garante que um MassID não esteja vinculado a um certificado ou crédito [RecycledID](/docs/protocol/certificates#recycledid).
* **`no-conflicting-gas-id-or-credit`** (BOLD Carbon (CH₄)) — Garante que um MassID não esteja vinculado a um certificado ou crédito [GasID](/docs/protocol/certificates#gasid).
Essas regras operam independentemente por metodologia, mas juntas formam um sistema abrangente de prevenção de colisões.
## Cenários de coexistência [#cenários-de-coexistência]
Duas metodologias com base técnica similar podem coexistir se atenderem a propósitos distintos (públicos, escalas ou contextos diferentes — ex.: municipal vs. industrial), e a plataforma garanta que o mesmo participante não possa ser homologado simultaneamente sob ambas as metodologias em colisão.
### Detecção automatizada de colisões [#detecção-automatizada-de-colisões]
* **Monitoramento pelo [Carrot Analytic Engine (CaE)](/docs/glossary#cae)** — O CaE monitora dados de metodologias ativas usando algoritmos de ML que comparam padrões de massa, fluxos, coeficientes e parâmetros de cálculo. Quando correlações incomuns são encontradas (duplicação de massa, equivalência de variáveis, sobreposição estatística), aciona bloqueio preventivo e sinaliza o caso para análise.
* **Contextualização pelo [Carrot Agentic Advisor (CaA)](/docs/glossary#caa)** — O CaA contextualiza anomalias detectadas, classifica o tipo e a severidade do conflito e recomenda ações corretivas (ajustes de parâmetros, suspensão temporária de homologação ou processo de revisão pela comunidade).
### Resolução por governança [#resolução-por-governança]
Quando um conflito persistente ou estrutural é identificado, a [Carrot Foundation](/docs/network/the-foundation) e/ou a Comunidade de Especialistas podem deliberar sobre: manter ambas as metodologias com separação de escopo reforçada, unificar elementos sobrepostos ou descontinuar uma das metodologias.
[Saiba mais sobre regras](/docs/methodologies) · [Saiba mais sobre MvA](/docs/standard/concepts/mva) · [Saiba mais sobre o ciclo de vida da metodologia](/docs/standard/concepts/lifecycle)
# Política de Descontinuação
## Quando uma metodologia é descontinuada? [#quando-uma-metodologia-é-descontinuada]
Uma metodologia de Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)) — incluindo metodologias de carbono e outras categorias — pode ser descontinuada quando não atende mais ao seu propósito original ou quando a continuidade da operação comprometeria a integridade da [Rede Carrot](/docs/network). Os critérios de descontinuação incluem:
1. **Invalidade científica** — A base científica da metodologia foi refutada ou superada por novas pesquisas.
2. **Mudança regulatória** — Alterações na regulamentação ambiental tornam a abordagem de verificação da metodologia não conforme.
3. **Substituição** — Uma metodologia mais recente cobre o mesmo escopo com maior precisão ou eficiência.
4. **Inatividade** — A metodologia não recebeu submissões ativas por um período prolongado, indicando que não é mais relevante para o mercado.
5. **Decisão de governança** — A Comunidade de Especialistas ou a [Carrot Foundation](/docs/network/the-foundation) determina que a descontinuação é do melhor interesse da rede.
## Processo de descontinuação [#processo-de-descontinuação]
A descontinuação segue uma transição em três fases:
### Fase 1: Comunicação e aviso prévio [#fase-1-comunicação-e-aviso-prévio]
A [Carrot Foundation](/docs/network/the-foundation) publica a decisão com aviso prévio, notificando todos os participantes ativos, o autor do MvF, o desenvolvedor do MvA e os compradores de créditos. O aviso inclui: justificativa técnica, cronograma de transição, orientações para operações ativas e metodologia substituta (quando existente). Período típico de aviso: 90–180 dias.
### Fase 2: Operação restrita [#fase-2-operação-restrita]
A metodologia continua operando para [MassIDs](/docs/protocol/mass-ids) que iniciaram processamento antes da data do aviso, mas nenhum novo MassID pode ser criado sob a metodologia. As regras de validação e cálculos permanecem ativos para MassIDs em trânsito, preservando a integridade dos créditos.
### Fase 3: Arquivamento [#fase-3-arquivamento]
A metodologia é formalmente desativada. Nenhum novo evento é aceito. O [MvF](/docs/standard/concepts/mvf), o [MvA](/docs/standard/concepts/mva), artefatos e histórico completo são arquivados com status "descontinuado". [Créditos](/docs/protocol/credits) emitidos antes da descontinuação permanecem válidos e negociáveis.
## Impacto nos créditos existentes [#impacto-nos-créditos-existentes]
[Créditos](/docs/protocol/credits) e [Certificados](/docs/protocol/certificates) emitidos antes da descontinuação permanecem válidos e negociáveis. A descontinuação é prospectiva — impede novas verificações, mas não afeta retroativamente reivindicações previamente verificadas.
O histórico de auditoria de todas as verificações anteriores permanece acessível pelo [Carrot Registry](/docs/protocol/registry) e no registry público de créditos imutável.
## Governança [#governança]
As decisões de descontinuação são tomadas pela [Carrot Foundation](/docs/network/the-foundation) com contribuições da Comunidade de Especialistas. À medida que o ecossistema amadurece, a Foundation expandirá progressivamente a participação comunitária nas decisões de descontinuação.
## Banimento [#banimento]
O banimento é uma medida excepcional reservada para situações de risco imediato ou severo à integridade. Pode ser executado **sem** período de transição.
### Gatilhos de banimento [#gatilhos-de-banimento]
* Fraude ou manipulação deliberada de dados, evidências ou parâmetros.
* Falhas estruturais no MvF/MvA resultando em emissão de créditos sem base técnica válida, não corrigíveis por versionamento.
* Ordens judiciais ou regulatórias que impeçam a continuidade da operação.
### Processo de banimento [#processo-de-banimento]
1. **Suspensão imediata** — Nenhum novo evento e nenhuma nova emissão.
2. **Bloqueio preventivo de créditos** — Créditos são bloqueados para análise.
3. **Notificação imediata** — Todos os participantes, compradores, registros e VVBs são notificados.
4. **Investigação** — O escopo do impacto é determinado.
5. **Relatório público** — Conclusões, justificativa e medidas são publicadas.
### Impacto nos créditos emitidos [#impacto-nos-créditos-emitidos]
| Resultado | Quando se aplica |
| ---------------- | -------------------------------------------------------------------- |
| Confirmação | A falha não afetou créditos previamente emitidos |
| Revisão e ajuste | A falha impactou parcialmente os resultados — recálculo onde afetado |
| Revogação | Créditos baseados em dados ou lógica comprometidos — invalidados |
Quando aplicável, a revisão é conduzida com auditores independentes.
[Saiba mais sobre a política de versionamento](/docs/standard/policies/versioning) · [Saiba mais sobre o ciclo de vida da metodologia](/docs/standard/concepts/lifecycle)
# Critérios de Qualidade e Homologação
## Propósito e escopo [#propósito-e-escopo]
A avaliação de qualidade de um sistema de Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)) — aplicado a metodologias de carbono e outras categorias ambientais — serve a três propósitos simultâneos. Para o ecossistema, ela funciona como **barreira de integridade** — garante que apenas frameworks tecnicamente sólidos, auditáveis e implementáveis entrem em operação, protegendo a credibilidade dos créditos emitidos e a confiança dos participantes e compradores. Para o autor, ela funciona como **guia de expectativas** — ao conhecer antecipadamente os critérios de avaliação, o autor pode construir o [MvF](/docs/standard/concepts/mvf) com foco nos requisitos que serão verificados, reduzindo retrabalho e ciclos de revisão. Para o developer, ela funciona como **garantia de qualidade do insumo** — um MvF homologado é, por definição, implementável sem interpretação, reduzindo risco e fricção no desenvolvimento do [MvA](/docs/standard/concepts/mva).
O escopo desta página abrange a avaliação do MvF (framework), que é o entregável primário do autor e o principal objeto de curadoria no estágio atual do ecossistema. Os critérios de qualidade para o MvA (aplicação), por envolverem requisitos de engenharia de software e integração com a plataforma, são definidos pelo time de Engenharia em documento separado.
Os critérios descritos aqui refletem o modelo de curadoria interna vigente, no qual a validação do
MvF é conduzida pelo time de Operações e Metodologias da Carrot. Conforme o ecossistema amadurece
e a Comunidade de Especialistas avança em suas fases, essas responsabilidades poderão ser
progressivamente transferidas, com salvaguardas e processos definidos pela governança aplicável.
## Princípios de avaliação [#princípios-de-avaliação]
A avaliação de qualidade de um MvF é orientada por seis princípios que refletem os valores do ecossistema dMRV e se aplicam tanto ao processo de curadoria interna atual quanto a futuros processos de revisão comunitária.
1. **Verificabilidade** — Todo requisito descrito no MvF deve ser expresso de forma que alguém — seja o MvA em execução automatizada, seja um auditor em verificação de terceiros — consiga responder, com base em evidências, se o requisito foi atendido. A pergunta orientadora é: "para cada regra, critério e parâmetro, existe uma forma objetiva de testar se foi cumprido?"
2. **Autocontenção** — O MvF deve ser suficientemente completo para que o developer do MvA consiga implementar todas as regras, cálculos e validações sem consultar o autor ou a metodologia científica original. Isso não significa que o MvF substitui a referência externa, mas sim que o framework deve conter todas as informações operacionais necessárias para implementação e auditoria.
3. **Rastreabilidade** — Deve ser possível percorrer o caminho completo entre a metodologia validada por terceiros e qualquer elemento operacional do MvF — regra, cálculo, parâmetro, critério de elegibilidade — demonstrando de onde cada requisito veio e como foi traduzido. A Matriz de Rastreabilidade é o instrumento que materializa esse princípio.
4. **Consistência interna** — As diferentes partes do MvF devem ser coerentes entre si: os critérios de elegibilidade devem ser compatíveis com os eventos do catálogo, as regras de validação devem referenciar entradas que realmente existem nos eventos, os cálculos devem usar variáveis que foram definidas e têm fonte declarada, e os outputs devem ser justificados pela trilha de evidências dos eventos anteriores.
5. **Proporcionalidade** — A avaliação reconhece que diferentes metodologias têm diferentes níveis de complexidade, e que os critérios de qualidade devem ser aplicados com razoabilidade. Um MvF para uma metodologia simples não precisa ter a mesma extensão documental de um MvF para uma metodologia complexa com dezenas de variáveis. O que deve ser constante é a qualidade e a precisão de cada componente, não necessariamente a quantidade.
6. **Adaptabilidade** — O MvF deve ser desenhado para suportar aplicação em múltiplos territórios, separando claramente elementos universais de elementos parametrizáveis por geografia. Um framework que funciona apenas para um país específico — sem prever a interface com Anexos Geográficos — limita a escalabilidade da metodologia e gera retrabalho significativo quando a expansão territorial se torna necessária.
## Dimensões de qualidade [#dimensões-de-qualidade]
Os critérios de qualidade são organizados em seis dimensões. Cada dimensão agrupa um conjunto de requisitos que, em conjunto, determinam se o MvF está pronto para homologação. A avaliação é feita dimensão por dimensão, e o resultado pode ser: **Conforme**, **Conforme com ressalvas** (pontos menores a ajustar que não comprometem a integridade do framework) ou **Não conforme** (lacunas que impedem a homologação e exigem revisão substantiva).
### Completude [#completude]
A dimensão de completude avalia se o MvF contém todos os componentes definidos na Estrutura Mínima do MvF e se os artefatos obrigatórios estão presentes e preenchidos. A Checklist de Completude do MvF é o instrumento de autoavaliação do autor para essa dimensão, mas a curadoria interna pode verificar aspectos adicionais além do checklist.
Na prática, a avaliação de completude verifica se cada seção da Estrutura Mínima está presente e não vazia: escopo e conceito, referência metodológica, elegibilidade e exclusões, catálogo de eventos, política de evidências, regras de validação, cálculos e parâmetros, outputs e adaptabilidade geográfica. Verifica também se os artefatos obrigatórios foram entregues: Matriz de Rastreabilidade, Catálogo de Eventos, Política de Evidências, Tabela de Regras de Validação e Tabela de Especificação de Cálculos e Parâmetros — todos com a coluna de Escopo Geográfico preenchida nas abas aplicáveis.
### Verificabilidade [#verificabilidade]
A dimensão de verificabilidade avalia se as regras, critérios e parâmetros do MvF estão descritos de forma que permitam teste objetivo. É a dimensão mais crítica para a qualidade operacional do framework, porque um MvF que não pode ser verificado não pode ser implementado de forma determinística.
A curadoria avalia verificabilidade por meio de uma análise amostral: seleciona um subconjunto representativo de regras de validação e critérios de elegibilidade e, para cada um, verifica se a descrição é suficiente para responder, sem ambiguidade, se o requisito foi atendido. Regras que contenham termos como "adequado", "razoável", "suficiente" ou "conforme necessário" sem definição operacional são consideradas não verificáveis e devem ser reformuladas.
A avaliação também verifica se os cenários de teste fornecidos (quando presentes) são consistentes com as fórmulas descritas — ou seja, se os resultados esperados são corretos quando se aplicam os inputs informados.
### Rastreabilidade [#rastreabilidade]
A dimensão de rastreabilidade avalia se o MvF mantém conexão clara e documentada com a metodologia validada por terceiros que o fundamenta. O instrumento central dessa avaliação é a Matriz de Rastreabilidade, que deve conectar cada requisito relevante da metodologia externa ao elemento correspondente no MvF.
A curadoria verifica se a Matriz está preenchida de forma que permita a qualquer revisor percorrer o caminho entre a referência externa e a implementação operacional: o requisito original está identificado com precisão (seção, versão, trecho)? O MvF indica claramente onde e como esse requisito é atendido? Os eventos associados existem no catálogo? As evidências e validações são consistentes?
Além da Matriz, a rastreabilidade também é avaliada no corpo do MvF: as fórmulas referenciam suas fontes? Os parâmetros fixos indicam a origem do valor? As exclusões e exceções são justificadas pela metodologia? Quando o MvF faz escolhas de design que vão além do que a metodologia prescreve — por exemplo, definir granularidade de eventos ou fatores de desconto conservadores — essas escolhas devem ser documentadas com racional técnico.
### Implementabilidade [#implementabilidade]
A dimensão de implementabilidade avalia se o MvF fornece ao developer do MvA informação suficiente para codificar todas as regras, validações e cálculos sem precisar interpretar, inferir ou consultar o autor. É o princípio de autocontenção traduzido em critério de avaliação.
Na prática, a curadoria avalia se: as regras de validação especificam a condição testada, o critério de aceitação e a ação em caso de falha; os cálculos descrevem a equação, cada variável (com unidade, fonte e condições), e os parâmetros fixos com referência; os eventos do catálogo declaram entradas requeridas com metadados mínimos e formatos esperados; e os critérios condicionais explicitam o gatilho que ativa cada condição.
Uma forma pragmática de avaliar implementabilidade é a "regra do developer": se a curadoria pegar qualquer seção do MvF e a entregar a um developer que não participou da elaboração do framework, esse developer conseguiria implementar sem fazer perguntas ao autor? Se a resposta for não, a seção precisa ser refinada.
### Auditabilidade [#auditabilidade]
A dimensão de auditabilidade avalia se o MvF, quando executado, gera evidências suficientes para que um auditor independente consiga verificar o processo ponta a ponta — desde as entradas originais até os outputs finais — sem precisar acessar sistemas internos ou depender de explicações verbais.
A curadoria verifica se: a Política de Evidências distingue claramente o que é verificável digitalmente e o que exige auditoria ou inspeção; os gatilhos de escalonamento estão definidos para situações de inconsistência, ausência e anomalia; o pacote de evidências digitais contém os elementos necessários para justificar cada resultado; e o versionamento do MvF e do MvA está previsto nos outputs, permitindo reprodução futura dos resultados.
A auditabilidade é especialmente relevante porque a Rede Carrot envolve processos de validação, emissão e aposentadoria de créditos que exigem trilha auditável completa. Um MvF que não gere evidências auditáveis cria fricção em todo o ciclo e fragiliza a credibilidade dos créditos.
### Adaptabilidade geográfica [#adaptabilidade-geográfica]
A dimensão de adaptabilidade geográfica avalia se o MvF foi desenhado para suportar aplicação em múltiplos territórios, conforme as diretrizes de adaptabilidade geográfica. Essa dimensão reconhece que uma metodologia dMRV com potencial de escala global precisa separar, desde o design, o que é universal — derivado da lógica da metodologia — do que é territorial — dependente de legislação, classificação ou infraestrutura local.
A curadoria avalia se: os elementos do MvF estão classificados como Universais ou Territoriais nos artefatos tabulares (Tabela de Regras, Tabela de Cálculos, Política de Evidências); os elementos classificados como Territoriais possuem um requisito funcional claro (a intenção universal) separado da operacionalização (que depende do território); os parâmetros territoriais indicam um valor default quando o dado local não está disponível; os critérios de elegibilidade territoriais indicam os pontos de conexão com o Anexo Geográfico; e o MvF declara explicitamente quais informações o Anexo Geográfico deve fornecer para cada ponto territorial.
Um MvF que não prevê adaptabilidade geográfica não é necessariamente não conforme nesta dimensão — isso depende do escopo declarado pelo autor. Se a metodologia é explicitamente desenhada para um único território (por exemplo, uma metodologia que só se aplica ao Brasil por depender de legislação brasileira específica), o autor deve declarar essa restrição no escopo e a avaliação considerará a dimensão como "não aplicável". Porém, se a metodologia tem potencial de aplicação multi-territorial e o MvF não prevê a separação universal/territorial, a curadoria sinalizará isso como um ponto de melhoria.
## Processo de homologação [#processo-de-homologação]
O processo de homologação é o fluxo pelo qual um MvF submetido ao ecossistema é avaliado, ajustado (quando necessário) e, quando aprovado, formalmente homologado para operação em produção. No estágio atual, esse processo é conduzido internamente pelo time de Operações e Metodologias da Carrot, com apoio do time de Engenharia para aspectos de viabilidade técnica de implementação.
### Submissão e triagem [#submissão-e-triagem]
O processo se inicia com a submissão formal do MvF pelo autor, acompanhado de todos os artefatos obrigatórios (Matriz de Rastreabilidade, Catálogo de Eventos, Política de Evidências, Tabela de Regras, Tabela de Cálculos) e da Checklist de Completude preenchida. A submissão pode ocorrer via RFP (quando o dMRV responde a uma demanda publicada) ou via parceria/iniciativa direta.
Na triagem inicial, a curadoria verifica se o entregável está completo — ou seja, se todas as seções da Estrutura Mínima estão presentes, se os artefatos obrigatórios foram entregues e se as colunas de Escopo Geográfico estão preenchidas nas abas aplicáveis. Se o entregável estiver incompleto, o autor é notificado sobre os componentes faltantes e tem prazo para complementar antes de a avaliação técnica se iniciar.
### Avaliação técnica [#avaliação-técnica]
Uma vez que o entregável está completo, a curadoria conduz a avaliação técnica — a aplicação sistemática dos critérios de qualidade nas seis dimensões (completude, verificabilidade, rastreabilidade, implementabilidade, auditabilidade e adaptabilidade geográfica). A avaliação produz um parecer técnico que registra, para cada dimensão, o resultado (conforme, conforme com ressalvas, não conforme) e as observações aplicáveis.
Durante a avaliação técnica, a curadoria pode consultar o autor para esclarecer pontos específicos, solicitar documentação adicional ou requisitar ajustes pontuais. Essas interações são registradas como parte do histórico de avaliação do dMRV, preservando rastreabilidade do processo decisório.
Quando o time de Engenharia identifica que algum aspecto do MvF apresenta desafios significativos de implementação — por exemplo, uma regra que depende de informação que a plataforma não consegue acessar, ou um cálculo que exige dados externos não integráveis — a curadoria pode devolver o MvF ao autor com uma nota técnica explicando a limitação e sugerindo alternativas.
### Ciclo de revisão [#ciclo-de-revisão]
Se a avaliação técnica identificar dimensões não conformes ou conformes com ressalvas que exijam ajustes, o MvF entra em ciclo de revisão. O autor recebe o parecer técnico com as observações detalhadas e tem prazo definido para submeter a versão revisada.
O ecossistema permite **no máximo dois ciclos de revisão** para um mesmo MvF. Se após o segundo ciclo ainda houver dimensões não conformes, o MvF é devolvido ao autor com recomendação de reestruturação substantiva, e uma nova submissão será tratada como processo independente. Essa limitação garante que o processo de homologação seja eficiente e que frameworks com problemas estruturais não consumam ciclos indefinidos de revisão.
Em cada ciclo, a curadoria reavalia apenas as dimensões sinalizadas — as dimensões previamente aprovadas não são reanalisadas, salvo se as alterações feitas pelo autor tenham impacto transversal que justifique reavaliação.
### Homologação [#homologação]
Quando todas as seis dimensões são avaliadas como conformes (ou conformes com ressalvas menores que não comprometem integridade), o MvF é considerado aprovado e entra em homologação formal. A homologação inclui:
* Registro da versão aprovada do MvF com timestamp e referência à avaliação técnica
* Publicação do framework no repositório de metodologias homologadas da plataforma
* Vinculação ao processo de desenvolvimento do MvA, que segue sob responsabilidade do time de Engenharia e do developer designado
A homologação do MvF não encerra a responsabilidade do autor. Conforme descrito na [Política de Versionamento](/docs/standard/policies/versioning), o autor pode ser chamado a colaborar em revisões de versão, a responder questionamentos de auditores e a participar de discussões técnicas sobre a evolução do framework.
## Tipologia de não conformidades [#tipologia-de-não-conformidades]
Para orientar autores e padronizar a linguagem de avaliação, esta seção classifica os tipos mais comuns de não conformidade identificados durante a avaliação técnica de um MvF.
| Tipo | Descrição | Exemplos | Impacto | Resolução típica |
| -------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Lacuna de conteúdo | Uma seção obrigatória da Estrutura Mínima está ausente ou substancialmente vazia. | Catálogo de Eventos sem descrição de entradas; Política de Evidências ausente; seção de Cálculos sem variáveis especificadas. | Bloqueia avaliação: não é possível avaliar qualidade sem conteúdo. | Complementar a seção e resubmeter. |
| Ambiguidade de regra | Uma regra de validação ou critério de elegibilidade está descrito de forma que permite múltiplas interpretações. | "O participante deve ter capacidade adequada"; "a pesagem deve ser precisa"; "o intervalo deve ser razoável". | Impede implementação determinística; cria risco de divergência entre MvF e MvA. | Reescrever com condição testável, critério numérico e ação em caso de falha. |
| Inconsistência interna | Duas ou mais partes do MvF se contradizem ou fazem referências cruzadas incorretas. | Uma regra referencia um evento inexistente no catálogo; um cálculo usa uma variável não definida; a Matriz aponta para seções inexistentes. | Compromete confiabilidade do framework como um todo. | Revisar as partes conflitantes e garantir coerência entre seções e artefatos. |
| Rastreabilidade insuficiente | Não é possível conectar um elemento do MvF à sua origem na metodologia validada. | Fórmula sem referência à metodologia externa; parâmetro fixo sem fonte; critério de exclusão sem justificativa metodológica. | Fragiliza a legitimidade técnica do framework. | Adicionar referências e fontes; completar a Matriz de Rastreabilidade. |
| Especificação insuficiente | A descrição existe, mas não tem detalhe suficiente para o developer implementar. | Fórmula com variáveis sem unidade; evento com "dados de pesagem" sem especificação de campos; regra sem ação em caso de falha. | Gera dependência do developer em relação ao autor; aumenta risco de erro. | Detalhar campos, unidades, fontes, condições e ações para cada componente. |
| Gap de auditabilidade | O framework não gera evidências suficientes para verificação de terceiros em um ou mais pontos. | Evento sem regime de evidência definido; ausência de gatilhos de escalonamento; outputs sem versionamento. | Compromete a capacidade de verificação e auditoria do ciclo de créditos. | Definir Política de Evidências completa com regime, metadados e gatilhos. |
| Adaptabilidade geográfica insuficiente | O MvF tem escopo multi-territorial mas não prevê separação entre elementos universais e territoriais. | Regras de elegibilidade com referência a legislação de um único país; classificação de materiais hardcoded para uma taxonomia local; parâmetros sem valor default. | Limita a escalabilidade da metodologia; gera retrabalho na expansão territorial. | Classificar elementos como Universal/Territorial nos artefatos; redigir requisitos funcionais separados de operacionais; prever pontos de conexão com Anexo Geográfico. |
Cada não conformidade identificada no parecer técnico inclui: a dimensão de qualidade afetada, o tipo de não conformidade, a localização no MvF (seção e artefato), a descrição do problema e a recomendação de resolução. Esse registro permite ao autor entender com precisão o que precisa ser corrigido, sem ambiguidade.
## Critérios de qualidade do MvA [#critérios-de-qualidade-do-mva]
A avaliação de qualidade da Methodology Verification Application (MvA) envolve critérios de engenharia de software, integração com a infraestrutura da plataforma Carrot e fidelidade de implementação em relação ao MvF homologado.
Existe uma interface relevante entre a qualidade do MvF e a qualidade do MvA: um framework bem especificado — que atenda aos critérios de verificabilidade, implementabilidade e adaptabilidade geográfica descritos nesta página — reduz significativamente o risco de problemas na implementação. Quando o MvF classifica elementos como territoriais e fornece requisitos funcionais claros, o developer sabe que precisa parametrizar esses pontos no MvA ao invés de hardcodar valores — resultando em código mais robusto e escalável.
A validação do MvA, quando realizada, verifica — entre outros aspectos — a fidelidade ao MvF homologado, a qualidade técnica da implementação (determinismo, reprodutibilidade, tratamento de erros), a rastreabilidade e geração de evidências (logs, trilhas de auditoria, registros de versão), a conformidade com os padrões técnicos da plataforma, e a correta parametrização de elementos territoriais.
Os critérios de qualidade do MvA são definidos e documentados pelo time de Engenharia em documento
separado, mantendo a separação de responsabilidades entre framework e código.
## Evolução para avaliação comunitária [#evolução-para-avaliação-comunitária]
Conforme descrito no [Ciclo de Vida da Metodologia](/docs/standard/concepts/lifecycle), a curadoria de dMRVs é desenhada para evoluir de forma progressiva — partindo da validação exclusivamente interna para um modelo com participação crescente da comunidade técnica.
Os critérios de qualidade descritos nesta página foram desenhados para suportar essa evolução: eles são objetivos, documentados e aplicáveis por qualquer revisor com capacidade técnica adequada. A inclusão da dimensão de adaptabilidade geográfica reforça esse ponto: ela permite que revisores de diferentes territórios avaliem se o MvF está preparado para operar em seus contextos regulatórios locais.
Independentemente do modelo de avaliação vigente, a Carrot mantém um papel de retaguarda para garantir transparência, consistência e continuidade do processo — incluindo preservação do histórico de avaliações, versionamento de critérios e resposta a riscos de integridade.
Os critérios formais de participação da comunidade na avaliação de dMRVs, incluindo papéis, níveis
de permissão e processos decisórios, ainda estão em definição e serão documentados conforme a
estrutura comunitária se consolidar.
***
[Guia do Autor de MvF](/docs/standard/guides/mvf-author-guide) · [Ciclo de Vida da Metodologia](/docs/standard/concepts/lifecycle)
# Política de Distribuição de Recompensas
## Visão geral [#visão-geral]
A Política de Distribuição de Recompensas define como os recursos das compras de [créditos](/docs/protocol/credits) são distribuídos entre os participantes. Quando um comprador adquire uma **quantidade** de créditos (ex: 10 toneladas métricas), essa quantidade é atendida alocando um ou mais [certificados](/docs/protocol/certificates), cada um lastreado por [MassIDs](/docs/protocol/mass-ids). Os recursos são divididos entre os MassIDs subjacentes proporcionalmente ao valor dos créditos retirados de cada um, e depois distribuídos por categoria de participante de acordo com os percentuais abaixo. A política é projetada para maximizar a participação na rede e acelerar as taxas de reciclagem entre diferentes regiões.
A política foi estabelecida pela Carrot Foundation em consulta com participantes do mercado, consultores e cientistas de dados. Com o tempo, a Foundation expandirá progressivamente a participação comunitária nessas decisões.
**Em todos os tipos de resíduo, pelo menos 80% de cada venda de crédito — de reciclagem ou de carbono — é alocado às categorias de participantes da Rede Carrot, antes de qualquer [desconto de recompensa](#descontos-nas-recompensas).** O restante cobre a Distribution Fee e o Registry, que cobrem as operações da rede, mais o componente de Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)) e Integridade, que financia as operações e o crescimento da Foundation. As tabelas abaixo detalham como a parcela dos participantes é dividida por categoria em cada material. Quando um desconto de recompensa se aplica, parte dessa parcela é redirecionada ao [Community Pool](/docs/glossary#community-pool) ou ao [Impact Pool](/docs/glossary#impact-pool) em vez de ser paga — o valor permanece dentro da rede e nunca é apropriado por uma parte privada.
## Moeda de pagamento e saque [#moeda-de-pagamento-e-saque]
As recompensas são pagas em [USDC](/docs/glossary#usdc) (uma moeda digital rastreável atrelada ao dólar americano). Os participantes podem sacar suas recompensas em moeda fiduciária ou stablecoin — pagamentos em moeda fiduciária são realizados por meio de provedores de pagamento integrados, enquanto saques em USDC utilizam diretamente o saldo do participante mantido no registry público. Usar USDC como moeda de liquidação proporciona aos participantes **valor estável** sem exposição à volatilidade de preços de mercado, mantém a liquidação do protocolo consistente em todo o registry público e permite que os participantes escolham como receber valor (moeda fiduciária ou stablecoin) de acordo com suas necessidades. Para a mecânica completa de reivindicação e distribuição com preservação de privacidade, consulte [Distribuição de Recompensas](/docs/protocol/rewards-distribution).
## Categorias de participantes [#categorias-de-participantes]
| Chave | Participante | Descrição |
| ----- | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| G | Gerador de Resíduos | Produz resíduos e realiza separação na fonte |
| WM | Gestor de Resíduos | Coordena e direciona a destinação dos resíduos sem assumir a custódia física |
| BC | Custodiante de Ponto de Coleta | Gerencia o contentor ou ponto de coleta onde os recicláveis são depositados antes de serem coletados |
| H | Transportador(es) | Transporta resíduos entre locais |
| P | Processador(es) | Separa, acumula e pré-processa materiais |
| R | Reciclador | Realiza reciclagem ou compostagem certificada (também atua como Processador quando registra os eventos de triagem) |
| I | Integrador | Provedor de dados para rastreamento da cadeia de suprimentos |
| A | Autor de MvF | Criador do framework de metodologia (MvF) |
| D | Desenvolvedor de MvA | Desenvolvedor do MvA (software que implementa o framework) |
| DF | Distribution Fee | Cobre a gestão de transações e a liquidação e o pagamento das recompensas aos participantes |
| RG | Registry | Cobre a emissão e a manutenção dos registros de emissão de créditos e certificados |
| dMRV | digital MRV and Integrity Component | Alimenta a Foundation Treasury e sustenta o desenvolvimento do protocolo e a integridade da rede |
O [**Custodiante de Ponto de Coleta**](/docs/protocol/supply-chain) gerencia o ponto de coleta onde os recicláveis se acumulam antes de um [Transportador](/docs/protocol/supply-chain) coletá-los para reciclagem. Seu percentual reconhece os custos de viabilizar a coleta na origem — aquisição do contentor, disponibilização e recolhimento, higienização, manutenção, controle de acesso e energia, entre outros. Os contentores podem ser disponibilizados gratuitamente ou mediante contrato, em locais públicos ou privados, ampliando os pontos de captação e a participação na rede. Onde se aplica um percentual ao Custodiante de Ponto de Coleta (atualmente a coleta de PET, conforme a tabela de distribuição abaixo) e não há Custodiante de Ponto de Coleta envolvido no processo do ativo, esse percentual é redirecionado ao Transportador.
O [**Gestor de Resíduos**](/docs/protocol/supply-chain#waste-manager) é contratado pelo Gerador
de Resíduos para coordenar a destinação sem transportar, separar ou tratar o material. Para resíduos
orgânicos, sua parcela de 4% se aplica somente quando o Gestor de Resíduos e o Gerador de Resíduos
concluíram o onboarding e confirmaram o vínculo. Uma declaração unilateral não produz efeito. Se
houver mais de um Gestor de Resíduos confirmado, eles dividem a parcela da categoria.
Quando um Gerador de Resíduos troca de Gestor de Resíduos, ele notifica a Carrot Foundation pelo
[operations@carrot.eco](mailto:operations@carrot.eco) para que o registro do vínculo seja atualizado.
[**Responsáveis pelo Programa**](/docs/protocol/credit-ecosystem-roles#program-owner) e
[**Desenvolvedores de Rede**](/docs/protocol/credit-ecosystem-roles#network-developer) são papéis
do ecossistema, não categorias de recompensa. Eles não recebem recompensas do protocolo nem aparecem
nos percentuais abaixo; qualquer remuneração por seus serviços é contratual e fica fora desta
política.
## Distribuição por tipo de resíduo [#distribuição-por-tipo-de-resíduo]
Cada tipo de resíduo tem seus próprios percentuais de distribuição, refletindo a contribuição relativa de cada participante na cadeia de suprimentos daquele material.
**Compostagem de resíduos orgânicos mistos:**
G (30%), WM (4%), H (9%), P (9%), R (18%), I (8%), A (1%), D (1%), DF (2,5%), RG (1%), dMRV (16,5%)
**Compostagem de lodo de estações de tratamento de resíduos:**
G (25%), WM (4%), H (4%), P (9%), R (28%), I (8%), A (1%), D (1%), DF (2,5%), RG (1%), dMRV (16,5%)
**Compostagem de resíduos da indústria do tabaco:**
G (25%), WM (4%), H (4%), P (9%), R (28%), I (8%), A (1%), D (1%), DF (2,5%), RG (1%), dMRV (16,5%)
Os 4% do Gestor de Resíduos saem das categorias Transportador (1%),
[Processador](/docs/protocol/supply-chain) (1%) e
[Reciclador](/docs/protocol/supply-chain#o-papel-do-reciclador) (2%); o total permanece 100%. Se
não houver Gestor de Resíduos confirmado no processo do ativo, esses percentuais retornam às
categorias de origem.
G (20%), H (20%), P (15%), R (15%), I (8%), A (1%), D (1%), DF (2,5%), RG (1%), dMRV (16,5%)
G (20%), H (20%), P (15%), R (15%), I (8%), A (1%), D (1%), DF (2,5%), RG (1%), dMRV (16,5%)
G (25%), H (10%), P (20%), R (15%), I (8%), A (1%), D (1%), DF (2,5%), RG (1%), dMRV (16,5%)
G (25%), BC (3%), H (12%), P (15%), R (15%), I (8%), A (1%), D (1%), DF (2,5%), RG (1%), dMRV (16,5%)
Os 3% do Custodiante de Ponto de Coleta saem da parcela do Transportador (15% → 12%); o total permanece 100%. Quando não há Custodiante de Ponto de Coleta envolvido, esses 3% são redirecionados ao Transportador.
Use a [Calculadora de Créditos](/docs/standard/guides/credit-calculator) para ver uma estimativa
ilustrativa da distribuição para um determinado tipo e volume de resíduo.
## Descontos nas recompensas [#descontos-nas-recompensas]
A distribuição de recompensas é calculada no momento da venda. Dois descontos podem ser aplicados, e ambos alimentam os [fundos de destino](#fundos-de-destino) da rede, em vez de qualquer parte privada.
### Incentivo à digitalização da cadeia de suprimentos [#incentivo-à-digitalização-da-cadeia-de-suprimentos]
Quando o [Gerador de Resíduos](/docs/protocol/supply-chain) não é identificado na cadeia de custódia, um desconto de digitalização é aplicado e direcionado ao [Community Pool](/docs/glossary#community-pool):
* A parcela de **100% do Gerador de Resíduos** é redirecionada ao Community Pool.
* Todos os demais prestadores de serviços logísticos (Transportadores, [Processadores](/docs/protocol/supply-chain), [Recicladores](/docs/protocol/supply-chain) e o [Integrador](/docs/protocol/network-integrators) — e o Custodiante de Ponto de Coleta, quando aplicável) recebem um **desconto de 25%** sobre seu pagamento, também direcionado ao Community Pool.
Um Gerador de Resíduos não identificado não pode ser associado a um vínculo confirmado com Gestor
de Resíduos para o ativo. Nesse caso, nenhuma parcela é distribuída ao Gestor de Resíduos; seus 4%
retornam às categorias Transportador, Processador e Reciclador, conforme descrito acima.
Isso se aplica a todos os tipos de resíduos e regiões, servindo como incentivo para maior digitalização da cadeia de suprimentos. Consulte [Distribuição de Recompensas](/docs/protocol/rewards-distribution) para a mecânica completa.
### Descontos do Gerador de Resíduos [#descontos-do-gerador-de-resíduos]
Um **desconto de 50%** sobre a parcela do Gerador de Resíduos se aplica em dois casos:
1. **Grande Empresa** — Geradores de Resíduos classificados como Grandes Empresas (receita superior a USD 4 milhões no ano-calendário anterior) recebem 50% de sua parcela alocada; os 50% restantes são direcionados ao [Impact Pool](/docs/glossary#impact-pool). Isso calibra os incentivos proporcionalmente, preservando a motivação para participação.
2. **Cadastro ainda não concluído** — como a distribuição é calculada no momento da venda, um Gerador de Resíduos que não concluiu o cadastro não pode ser classificado como Grande Empresa ou não, então o desconto de 50% é aplicado automaticamente. A metade descontada é direcionada ao [Impact Pool](/docs/glossary#impact-pool), e os 50% restantes do gerador ficam retidos, resgatáveis apenas após o gerador concluir o cadastro. As recompensas retidas seguem a janela padrão de expiração de recompensas: se o gerador concluir o cadastro e resgatar dentro do prazo, recebe sua parcela; se as recompensas expirarem sem resgate, essa metade é direcionada ao [Community Pool](/docs/glossary#community-pool). Isso mantém a política uniforme enquanto a verificação de registro permanece pendente e incentiva a conclusão do cadastro.
## Fundos de destino [#fundos-de-destino]
Além da Distribution Fee e do Registry, que cobrem as operações da rede, o que não é pago diretamente aos participantes é direcionado a um de três fundos com propósito definido, conforme o mecanismo de origem — de modo que fique sempre claro para que serve cada unidade de valor. Esses fundos são financiados de forma transparente por desenho, e não de forma discricionária pelo operador.
* **[Foundation Treasury](/docs/glossary#foundation-treasury)** — os recursos operacionais da Carrot Foundation, financiados pelo digital MRV and Integrity Component de cada venda.
* **[Community Pool](/docs/glossary#community-pool)** — um fundo discricionário para o crescimento da rede aberta (cadastro, expansão, marketing, eventos, grants competitivos, apoio ao ecossistema). **Não é um fundo de doação**; o valor que de outra forma ficaria ocioso é reciclado para o crescimento do ecossistema.
* **[Impact Pool](/docs/glossary#impact-pool)** — um fundo de doação pura a projetos socioambientais e de economia circular no país onde a reciclagem ocorreu.
### O que alimenta o Community Pool [#o-que-alimenta-o-community-pool]
Além do desconto de digitalização acima, o Community Pool é alimentado pelos próprios mecanismos de integridade e incentivo da rede:
* **Recompensas não resgatadas** — recompensas não resgatadas em até **90 dias corridos** da data da venda, reinvestidas no crescimento da rede em vez de permanecerem ociosas.
* **Penalidades de self-policing** — recompensas retidas quando a Carrot Foundation identifica o envio de dados ruins ou fraudulentos. A retenção não é automática: para erros de qualidade de boa-fé, aplica-se um processo de três etapas — (1) informação e reconhecimento, (2) um aviso formal descrevendo as falhas e as mudanças necessárias e (3) um aviso de penalidade retendo as recompensas se as falhas não forem corrigidas. Em casos de fraude (dados deliberadamente falsos), a penalidade é absoluta e aplicada diretamente, sem as etapas acima.
* **Colateral retido** — quando estruturado, o colateral retido de participantes que cometam infrações pode ser direcionado ao Community Pool.
### O que alimenta o Impact Pool [#o-que-alimenta-o-impact-pool]
A principal fonte do Impact Pool é a parcela redirecionada de Geradores de Resíduos classificados como **Grande Empresa** (receita superior a USD 4 milhões) e a metade descontada de geradores com cadastro incompleto. Isso garante que compradores de crédito não estejam financiando recompensas a grandes corporações e canaliza esse valor para o impacto local.
[Saiba mais sobre distribuição de recompensas](/docs/protocol/rewards-distribution) · [Saiba mais sobre a cadeia de suprimentos](/docs/protocol/supply-chain)
# Chamadas de Propostas (RFP)
## O que é um RFP? [#o-que-é-um-rfp]
Um Request for Proposals (RFP) é uma chamada formal na qual a [Carrot Foundation](/docs/network/the-foundation) convida especialistas, desenvolvedores e organizações a submeterem propostas para um desafio específico, construir uma solução ou contribuir com o ecossistema da plataforma. Pense em um RFP como uma ponte entre uma necessidade identificada pela Carrot (ou pelo mercado) e o talento disponível na comunidade.
O mecanismo de RFP é central para a missão da Carrot porque reflete três princípios:
* **Transparência** — Critérios públicos e um processo documentado garantem que todos os participantes tenham as mesmas informações.
* **Seleção documentada** — Propostas são pontuadas com base em critérios publicados, e a seleção segue o processo de avaliação documentado.
* **Engajamento comunitário** — A comunidade participa ativamente na construção da plataforma.
Qualquer pessoa ou organização pode participar de um RFP da Carrot, desde que atenda aos critérios
de elegibilidade definidos em cada chamada.
Para preservar a imparcialidade, membros da comunidade aptos a participar de processos deliberativos de governança não podem atuar como avaliadores em RFPs para os quais tenham submetido proposta.
## Tipos de RFP [#tipos-de-rfp]
Nem todos os RFPs são iguais. Cada tipo é desenhado para um tipo específico de contribuição — o tipo determina o que é esperado do proponente, quais documentos submeter e como a proposta será avaliada.
| Tipo | Nome | Descrição |
| :---: | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **A** | **Resolução de problema** | A Carrot identifica um problema ou pergunta e convida a comunidade a propor abordagens, análises ou soluções conceituais. O foco é na qualidade da ideia, não na execução imediata. |
| **B** | **Projeto via AMC** | Um Advance Market Commitment organizado por compradores ou financiadores externos — não operado pela Carrot — financia a construção de infraestrutura: instalações de tratamento biológico, sistemas de coleta ou cadeias de reciclagem. O proponente apresenta um plano completo de implementação e entrega. |
| **C** | **Construção de MvF** | Chamada para traduzir uma metodologia científica validada em um Methodology Verification Framework operacional. O proponente deve demonstrar domínio da metodologia e capacidade de estruturar os artefatos que a plataforma Carrot utiliza para executá-la. |
| **D** | **Construção de MvA** | Chamada para implementar um MvF aprovado em código. O entregável é o MvA (Methodology Verification Application) — o software que executa a verificação digital na plataforma. Requer um MvF concluído como pré-requisito. |
| **E** | **Solução de tecnologia** | Desenvolvimento de uma feature, ferramenta ou integração para a plataforma Carrot. O entregável é código funcional, testado e documentado. |
| **F** | **Aberto** | Reservado para chamadas que não se encaixam nos demais tipos. Novas categorias podem surgir conforme as necessidades do ecossistema evoluem. |
Novos tipos de RFP podem ser criados conforme novas necessidades surgem no ecossistema. A Carrot
se reserva o direito de criar ou revogar tipos a qualquer momento, sempre respeitando processos já
em andamento.
## Dependências entre tipos [#dependências-entre-tipos]
Alguns tipos de RFP possuem dependências naturais. Por exemplo, um Tipo D (Construção de [Aplicação de Verificação de Metodologia (MvA)](/docs/standard/concepts/mva)) só pode ser aberto após a conclusão de um Tipo C (Construção de [Framework de Verificação de Metodologia (MvF)](/docs/standard/concepts/mvf)), porque o código precisa de um framework aprovado como referência. Da mesma forma, um Tipo B (Projeto via AMC) pode gerar demandas subsequentes de Tipos C, D e E — quando um projeto de infraestrutura requer uma nova metodologia operacionalizada e ferramentas tecnológicas para funcionar na plataforma.
Ao consultar um RFP, verifique se ele indica dependências com chamadas anteriores ou simultâneas.
## Ciclo de vida [#ciclo-de-vida]
Todo RFP da Carrot segue um ciclo de vida padronizado com 10 fases, garantindo que cada chamada passe pelas mesmas etapas de preparação, engajamento, avaliação e execução, independentemente do tipo.
1. **Concepção** — A Carrot (ou o mercado) identifica a necessidade que origina o RFP e define seus contornos iniciais.
2. **Estruturação** — O RFP é redigido com escopo, critérios de elegibilidade, entregáveis esperados, cronograma e matriz de avaliação.
3. **Publicação** — O RFP é publicado e a comunidade é notificada. A partir deste momento, o documento é público.
4. **Submissão** — Proponentes preparam e enviam suas propostas dentro do prazo estabelecido.
5. **Triagem** — Propostas são verificadas contra os critérios de elegibilidade. Quem não atende aos requisitos mínimos é desclassificado.
6. **Avaliação** — Propostas elegíveis são pontuadas individualmente por avaliadores independentes usando a matriz de critérios ponderados.
7. **Seleção** — As propostas são ranqueadas pela pontuação final e o comitê avaliador toma a decisão.
8. **Contratação** — O proponente selecionado negocia os termos finais e formaliza o acordo com a Carrot Foundation.
9. **Execução** — O trabalho é realizado conforme o cronograma acordado, com acompanhamento periódico pela Carrot.
10. **Encerramento** — Os entregáveis são verificados, o trabalho é aceito formalmente e os aprendizados alimentam futuras chamadas.
## Períodos importantes [#períodos-importantes]
Cada RFP define seu próprio cronograma, mas dois períodos merecem atenção especial:
**Período de perguntas e esclarecimentos** — Entre a publicação e o prazo de submissão, há uma janela para enviar dúvidas. As respostas são consolidadas em um FAQ público disponível para todos os proponentes. Nenhuma informação privilegiada é fornecida individualmente.
**Prazo de submissão** — Inegociável. Propostas recebidas após o prazo não serão consideradas em hipótese alguma. Recomendamos submeter com pelo menos 24 horas de antecedência.
## Canais alternativos de entrada [#canais-alternativos-de-entrada]
Embora o RFP seja o mecanismo preferencial, o ecossistema também aceita metodologias via parcerias estratégicas e iniciativa direta. Nesses casos, o proponente submete a proposta diretamente à Carrot, que avalia a pertinência e a qualidade usando os mesmos critérios aplicáveis a um RFP — preservando as exigências de integridade, auditabilidade e alinhamento com o ecossistema. A diferença é que parcerias e submissões diretas são avaliadas pelo mérito individual, sem competição entre propostas.
Para orientação prática sobre participação em RFPs, consulte o [Guia de Participação em RFPs](/docs/standard/guides/rfp-participation-guide).
[Guia de Participação em RFPs](/docs/standard/guides/rfp-participation-guide) · [Ciclo de Vida da Metodologia](/docs/standard/concepts/lifecycle) · [Ecossistema de Metodologias](/docs/standard/concepts/ecosystem)
# Política de Versionamento
## Convenções SemVer [#convenções-semver]
Todas as metodologias de Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)) na [Rede Carrot](/docs/network) — incluindo metodologias de carbono e outras categorias de créditos — seguem o [Versionamento Semântico (SemVer)](https://semver.org/) para comunicar a natureza e o impacto das mudanças:
| Nível | Significado | Exemplo |
| --------- | --------------------------------------------------------------------------------------------------------------- | --------------- |
| **MAJOR** | Mudanças incompatíveis na lógica de verificação que podem afetar integrações existentes ou alterar resultados | v1.0.0 → v2.0.0 |
| **MINOR** | Novas regras adicionadas ou melhorias não incompatíveis em regras existentes | v1.0.0 → v1.1.0 |
| **PATCH** | Correções de bugs, atualizações de documentação ou correções menores que não alteram o comportamento das regras | v1.0.0 → v1.0.1 |
## Versionamento do framework [#versionamento-do-framework]
Os documentos do [Methodology Verification Framework (MvF)](/docs/standard/concepts/mvf) são versionados independentemente. Cada versão representa um estado específico da especificação de verificação:
* **Mudanças MAJOR** exigem uma nova versão do framework e podem incluir um guia de migração para [Integradores](/docs/protocol/network-integrators) cujos padrões de envio de dados precisam ser adaptados.
* **Mudanças MINOR** adicionam novos requisitos de verificação sem alterar os existentes.
* **Mudanças PATCH** esclarecem especificações ambíguas ou corrigem a documentação.
## Versionamento da aplicação [#versionamento-da-aplicação]
As releases do [Methodology Verification Application (MvA)](/docs/standard/concepts/mva) acompanham a versão MAJOR do MvF para manter o alinhamento entre especificação e implementação:
* Uma nova versão MAJOR do MvF aciona uma nova versão MAJOR do MvA.
* Novas implementações de regras dentro da mesma versão MAJOR do MvF são releases MINOR do MvA.
* Correções de bugs nos processadores de regras são releases PATCH do MvA.
## Ciclo de vida da versão [#ciclo-de-vida-da-versão]
Cada versão passa por estágios definidos:
1. **Rascunho** — Em desenvolvimento; ainda não disponível para uso em produção.
2. **Revisão** — Em revisão pela Comunidade de Especialistas; pode mudar antes da publicação.
3. **Publicado** — Ativo em produção; documentos [MassID](/docs/protocol/mass-ids) são avaliados contra esta versão.
4. **Descontinuado** — Substituído por uma versão mais recente; um período de transição permite que os integradores se adaptem.
## Política de transição [#política-de-transição]
Quando uma versão é descontinuada:
* **Período de transição** — [Integradores](/docs/protocol/network-integrators) e participantes da [cadeia de suprimentos](/docs/protocol/supply-chain) recebem aviso prévio para se adaptar à nova versão.
* **[Créditos](/docs/protocol/credits) existentes** — Créditos emitidos sob uma versão descontinuada permanecem válidos e negociáveis. A descontinuação não afeta retroativamente reivindicações previamente verificadas.
* **Novas submissões** — Após o período de transição, novas submissões de MassID devem estar em conformidade com a versão publicada atual.
## Princípios de atualização [#princípios-de-atualização]
Todas as atualizações de metodologias são regidas por três princípios invioláveis:
1. **Preservação da rastreabilidade histórica** — Nenhuma atualização pode apagar ou tornar inacessível uma versão anterior. Resultados gerados sob uma versão devem permanecer auditáveis segundo as regras daquela versão. O ecossistema mantém um repositório versionado com histórico completo de mudanças.
2. **Continuidade operacional** — Atualizações não podem causar interrupção abrupta em metodologias ativas. Quando mudanças afetam regras de validação, cálculos ou elegibilidade, um período de transição permite a coexistência.
3. **Governança transparente** — Toda mudança deve ser justificada, documentada e comunicada. A documentação registra: o que mudou, por quê, quem propôs, quem aprovou e quando entra em vigor.
## Categorias de alteração [#categorias-de-alteração]
| Categoria | Impacto | Incremento de versão | Aprovação |
| ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | -------------------- | ------------------------------------------------------------------------------ |
| Correções menores | Sem alteração de lógica/cálculo/elegibilidade. Erros de digitação, formatação, referências, esclarecimentos de redação. | PATCH | Curadoria interna com registro de alteração |
| Atualizações operacionais | Afetam a execução, mas não a base científica. Adição/ajuste de regras, refinamento de elegibilidade, novos eventos, atualizações de metadados. | MINOR | Análise técnica pela curadoria, consulta à Engenharia quando o MvA é impactado |
| Revisões substantivas | Modificam a base de cálculo, parâmetros-chave, lógica de quantificação ou fundamentos. | MAJOR | Ciclo completo de homologação |
### Quem pode propor alterações [#quem-pode-propor-alterações]
Mudanças podem ser propostas por: autor original do MvF, equipe de Operações & Metodologias, equipe de Engenharia, VVBs independentes e membros da Comunidade de Especialistas. Cada proposta deve incluir: descrição, justificativa técnica, impacto esperado e categoria proposta.
## Coexistência de versões [#coexistência-de-versões]
Quando uma nova versão do MvF é publicada, a anterior não é desativada imediatamente. Ambas coexistem durante um período de transição para MassIDs em trânsito.
A regra governante é a **versão de entrada**: cada [MassID](/docs/protocol/mass-ids) é avaliado sob a versão do MvF ativa no momento de seu primeiro evento (tipicamente a coleta). Novos MassIDs após a data de vigência seguem as regras atualizadas.
Períodos de transição típicos: 30–90 dias para atualizações operacionais, mais longos para revisões substantivas (caso a caso).
[Saiba mais sobre o ciclo de vida da metodologia](/docs/standard/concepts/lifecycle) · [Saiba mais sobre a política de descontinuação](/docs/standard/policies/discontinuation)
# BOLD Carbon (CH₄) Framework
## Resumo do framework [#resumo-do-framework]
| Propriedade | Valor |
| ---------------------- | -------------------------------------------------------------------------------------------------------- |
| **Metodologia** | [AMS-III.F](/docs/methodologies/ams-iii-f) |
| **Versão** | 1.0.2 |
| **Status** | Publicado |
| **Tipo de credito** | Credito de Carbono |
| **Token** | [TCC](/docs/protocol/credits#tokenized-carbon-credits-tcc) (`C-CARB.CH4`) — emitido por esta metodologia |
| **Referencia externa** | UNFCCC AMS-III.F v12.0 |
## Escopo [#escopo]
O [MvF](/docs/standard/concepts/mvf) BOLD Carbon (CH₄) define procedimentos de verificação para reduções de emissões de metano por meio da compostagem de resíduos orgânicos que, de outra forma, se decomporiam anaerobicamente em aterros sanitarios:
* **Tipos de resíduos**: Resíduos alimentares, resíduos verdes (jardins, quintais e podas de parques), lodo de estações de tratamento de efluentes, resíduos da industria do tabaco e outros subtipos orgânicos classificados sob códigos de resíduos CDM
* **Tratamento**: Compostagem aerobia em instalações profissionais
* **Geografia**: Atualmente operacional no Brasil, com o framework projetado para ser expansível a outras regiões
* **Alegação ambiental**: Reduções de emissões (CO2e) por meio de compostagem
## Criterios de elegibilidade [#criterios-de-elegibilidade]
Os participantes devem atender aos mesmos requisitos de credenciamento do [BOLD Recycling](/docs/methodologies/bold-recycling/framework):
* **[Geradores de resíduos](/docs/protocol/supply-chain)** — Devem ser identificados com documentação valida.
* **Transportadores** — Obrigatórios para transporte por caminhão e barco; opcionais para coleta por tubulação de lodo e carrinho.
* **Processadores** — Exatamente um processador deve ser identificado por [MassID](/docs/protocol/mass-ids).
* **[Recicladores](/docs/protocol/supply-chain)** — Exatamente um reciclador (instalação de compostagem) deve ser identificado com datas de credenciamento validas.
* **[Integradores de Rede](/docs/protocol/network-integrators)** — Devem ter datas de credenciamento validas.
## Requisitos de verificação [#requisitos-de-verificação]
O BOLD Carbon (CH₄) inclui todas as verificações presentes no BOLD Recycling, além de verificações adicionais especificas para quantificação de emissoes:
* **Todas as verificações compartilhadas** — Validação de documentos, identificação de atores, validação de eventos, geolocalização, manifestos, conformidade e integridade (consulte o [Framework BOLD Recycling](/docs/methodologies/bold-recycling/framework))
* **Calculo de emissoes** — A regra `prevented-emissions` quantifica as reduções de emissões (CO2e) utilizando a metodologia UNFCCC AMS-III.F
* **Limite do projeto** — A regra `project-boundary` valida a distancia geográfica entre os locais de coleta e entrega
## Cenario de linha de base e fatores de emissão [#cenario-de-linha-de-base-e-fatores-de-emissão]
O BOLD Carbon (CH₄) referencia a metodologia UNFCCC AMS-III.F v12.0 para cálculos de emissão:
* **Cenario de linha de base** — Resíduos orgânicos se decompondo anaerobicamente em um aterro sanitario, gerando metano (CH4)
* **Cenario do projeto** — Os mesmos resíduos orgânicos compostados aerobicamente, prevenindo a geração de metano
* **Fatores de emissão** — Fatores estáticos sao utilizados para a maioria dos subtipos de resíduos orgânicos. Para resíduos classificados sob o código CDM 8.7D ("Outros, se orgânico"), fatores dinamicos sao aplicados com base nos códigos de classificação de resíduos do Ibama.
A regra `prevented-emissions` aplica a formula: as reduções de emissões (CO2e) equivalem a massa de resíduos compostados multiplicada pelo fator de reduções de emissões por tonelada, menos a massa multiplicada pelo coeficiente de emissão excedente.
## Base cientifica [#base-cientifica]
Os seguintes padroes fornecem a fundamentação cientifica para os cálculos de emissão e classificação de resíduos no BOLD Carbon (CH₄):
### Mecanismo de Desenvolvimento Limpo da UNFCCC [#mecanismo-de-desenvolvimento-limpo-da-unfccc]
| Referencia | Versão | Descrição |
| --------------- | ------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **AMS-III.F** | v12.0 | "Avoidance of methane emissions through composting" (título oficial do CDM, em inglês) — base para a regra `prevented-emissions`. Define fatores de emissão e procedimentos de calculo para quantificar reduções de CH₄ pela compostagem de resíduos orgânicos. |
| **CDM Tool 04** | v8.0 | "Emissoes de locais de disposição de resíduos solidos" — fornece metodologias para estimar emissoes de metano da disposição em aterros, utilizado como cenario de linha de base nos cálculos de reduções de emissoes. |
| **CDM Tool 13** | v2.0 | "Emissoes do projeto e fugas da compostagem" — define procedimentos para estimar emissoes do projeto e fugas das atividades de compostagem. |
### IPCC [#ipcc]
| Referencia | Ano | Descrição |
| ------------ | ---- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **IPCC AR5** | 2013 | Quinto Relatorio de Avaliação — fornece valores de Potencial de Aquecimento Global (GWP) utilizados nos cálculos de emissão. O GWP do metano (CH₄) e usado para converter reduções de emissoes de metano em CO₂e. |
### Padroes regionais [#padroes-regionais]
| Referencia | Jurisdição | Descrição |
| ------------------------------------------------- | ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Lista Brasileira de Resíduos Solidos do Ibama** | Brasil | Sistema oficial de classificação de resíduos utilizado pela regra `regional-waste-classification`. Mapeia tipos de resíduos para códigos CDM para seleção de fatores de emissão. |
## Parametros de calculo de emissoes [#parametros-de-calculo-de-emissoes]
### Emissoes de linha de base — CDM Tool 04 v8.0 [#emissoes-de-linha-de-base--cdm-tool-04-v80]
Para calcular emissoes de metano de aterros sanitarios e lixões, o BOLD Carbon (CH₄) utiliza o [UNFCCC CDM Tool 04 v8.0](https://cdm.unfccc.int/methodologies/PAmethodologies/tools/am-tool-04-v8.0.pdf) — "Emissoes de Locais de Disposição de Resíduos Solidos."
| Parametro | Valor | Descrição |
| -------------- | --------------------------------------- | -------------------------------------------------------------------------------------------------------- |
| φ | 0.85 | Fator de correção do modelo para incertezas do modelo |
| f | 0.00 (cenarios 1, 3) / 0.45 (cenario 2) | Fração de metano capturado e queimado |
| GWP\_CH₄ | 28 | Potencial de Aquecimento Global do metano ([IPCC AR5, 2013](https://www.ipcc.ch/assessment-report/ar5/)) |
| OX | 0.1 | Fator de oxidação (metano oxidado na cobertura de solo) |
| F | 0.5 | Fração de metano no gas de aterro (volume) |
| DOC\_f | 0.5 | Fração de carbono orgânico degradável que se decompõe |
| MCF | 1.0 (cenarios 1, 2) / 0.8 (cenario 3) | Fator de correção de metano |
| DOC\_j (food) | 0.15 | Fração de carbono orgânico degradável — resíduos alimentares |
| DOC\_j (green) | 0.20 | Fração de carbono orgânico degradável — resíduos verdes |
| K\_j (food) | 0.40 | Taxa de decaimento — resíduos alimentares (1/ano, clima tropical úmido) |
| K\_j (green) | 0.17 | Taxa de decaimento — resíduos verdes (1/ano, clima tropical úmido) |
Tres cenarios de linha de base sao suportados:
1. **Aterro sanitario sem queima de metano** — Maiores emissoes (f = 0)
2. **Aterro sanitario com queima de metano** — Emissoes moderadas (f = 0.45, \~50% de captura com 90% de eficiência de queima)
3. **Lixão** — Emissoes intermediarias (MCF = 0.8)
### Emissoes reais — CDM Tool 13 v2.0 [#emissoes-reais--cdm-tool-13-v20]
Para calcular emissoes durante a compostagem, o BOLD Carbon (CH₄) utiliza o [UNFCCC CDM Tool 13 v2.0](https://cdm.unfccc.int/methodologies/PAmethodologies/tools/am-tool-13-v2.pdf) — "Emissoes do Projeto e Fugas da Compostagem."
| Parametro | Valor | Descrição |
| --------- | -------------- | --------------------------------------------------------------------------------------------------------------- |
| EF\_CH₄ | 2.0 g/kg waste | Fator de emissão de metano por kg compostado |
| EF\_N₂O | 0.2 g/kg waste | Fator de emissão de oxido nitroso por kg compostado |
| GWP\_CH₄ | 28 | Potencial de Aquecimento Global do metano ([IPCC AR5, 2013](https://www.ipcc.ch/assessment-report/ar5/)) |
| GWP\_N₂O | 265 | Potencial de Aquecimento Global do oxido nitroso ([IPCC AR5, 2013](https://www.ipcc.ch/assessment-report/ar5/)) |
Os fatores de emissão padrão sao para "Peso Fresco" (peso bruto incluindo teor de água). Fatores adicionais para consumo de combustível fossil e eletricidade se aplicam, mas nao sao mostrados na formula simplificada.
## Exemplo de calculo [#exemplo-de-calculo]
Para uma instalação de compostagem utilizando uma proporção de 50/50 de resíduos alimentares e resíduos verdes, comparando compostagem com aterro sanitario sem captura de metano:
| Métrica | Valor |
| ---------------------------------- | ------------------- |
| Emissoes de Linha de Base (BE) | 2.451 tons CO₂e |
| Emissoes Reais da compostagem (RE) | 0.218 tons CO₂e |
| **Reduções de Emissões (ER)** | **2.233 tons CO₂e** |
Isso significa que compostar 1 tonelada de resíduos alimentares + 1 tonelada de resíduos verdes entrega aproximadamente 2,2 toneladas de CO₂e em reduções de emissões ao longo de um periodo de 20 anos em comparação com a disposição em aterro sanitario.
### Comparação entre metodos de disposição [#comparação-entre-metodos-de-disposição]
| Método de disposição | Emissoes totais em 20 anos | Reduções por compostagem |
| -------------------- | -------------------------- | ------------------------ |
| Aterro sem queima | 2.451 tons CO₂e | 2.233 tons CO₂e |
| Lixão | 1.961 tons CO₂e | 1.743 tons CO₂e |
| Aterro com queima | 1.348 tons CO₂e | 1.130 tons CO₂e |
| **Compostagem** | **0.218 tons CO₂e** | — |
Em todos os cenarios, compostar 1 tonelada de resíduos orgânicos entrega mais de 1 tonelada de CO₂e em reduções de emissões.
## Códigos de resíduos suportados [#códigos-de-resíduos-suportados]
O BOLD Carbon valida materiais residuais em relação a [Lista Brasileira de Resíduos Solidos](https://www.gov.br/ibama/pt-br/assuntos/emissoes-e-resíduos/resíduos/arquivos/ibama-lista-brasileira-de-resíduos-solidos.doc) publicada pelo [Ibama](/docs/glossary#ibama) (IN nº 13, 18 de dezembro de 2012) e mapeia cada código do Ibama para uma categoria de resíduos [CDM](/docs/glossary#cdm) do CDM Tool 04 v08.1. Este mapeamento e aplicado no momento da submissão pela regra `regional-waste-classification` — consulte o [Catalogo de regras](/docs/methodologies/ams-iii-f/bold-carbon/application/application-rules) e a referencia de [Classificação de Resíduos](/docs/integrations/reference/waste-classification) para contexto adicional.
### Categorias de resíduos CDM [#categorias-de-resíduos-cdm]
A metodologia suporta **216 códigos do Ibama** nas seguintes categorias CDM:
| Código CDM | Categoria | Códigos suportados |
| ---------- | --------------------------------------------------------------- | ------------------ |
| 8.1 | Madeira e produtos de madeira | 8 |
| 8.2 | Celulose, papel e cartão (exceto lodo) | 8 |
| 8.3 | Alimentos, resíduos alimentares, bebidas e tabaco (exceto lodo) | 12 |
| 8.4 | Têxteis | 5 |
| 8.5 | Resíduos de jardins, quintais e parques | 1 |
| 8.6 | Vidro, plástico, metal, outros resíduos inertes | 47 |
| 8.7B | Lodo Industrial | 14 |
| 8.7C | Lodo Domestico | 26 |
| 8.7D | Outros (se orgânico) | 95 |
### Referencia de códigos do Ibama [#referencia-de-códigos-do-ibama]
Expanda cada categoria abaixo para ver os códigos do Ibama aceitos. O **Código do Ibama** é o valor a ser enviado como `Local Waste Classification ID`; a **Descrição** é validada em relação a `Local Waste Classification Description`.
| Código do Ibama | Descrição |
| --------------- | ---------------------------------------------------------------------------------------------------- |
| `02 01 07` | Resíduos silvícolas |
| `03 01 01` | Resíduos do descasque da madeira |
| `03 01 05` | Serragem, aparas, fitas de aplainamento, madeira, aglomerados e folheados nao abrangidos em 03 01 04 |
| `03 03 01` | Resíduos do descasque de madeira e resíduos de madeira |
| `15 01 03` | Embalagens de madeira |
| `17 02 01` | Madeira |
| `19 12 07` | Madeira nao abrangida em 19 12 06 |
| `20 01 38` | Madeira nao abrangida em 20 01 37 |
| Código do Ibama | Descrição |
| --------------- | ------------------------------------------------------------------------------------------------- |
| `03 03 07` | Rejeitos mecanicamente separados da fabricação de pasta a partir de papel e papelao usado |
| `03 03 08` | Resíduos da triagem de papel e papelao destinado a reciclagem |
| `03 03 10` | Rejeitos de fibras e lodos de fibras, fillers e revestimentos, provenientes da separação mecanica |
| `04 02 21` | Resíduos de fibras têxteis nao processadas |
| `04 02 22` | Resíduos de fibras têxteis processadas |
| `15 01 01` | Embalagens de papel e cartão |
| `19 12 01` | Papel e cartão |
| `20 01 01` | Papel e cartão |
| Código do Ibama | Descrição |
| --------------- | ----------------------------------------------------------------------------------------------------- |
| `02 01 02` | Resíduos de tecidos animais |
| `02 01 03` | Resíduos de tecidos vegetais |
| `02 02` | Resíduos da preparação e processamento de carne, peixe e outros produtos alimentares de origem animal |
| `02 02 02` | Resíduos de tecidos animais e orgânico de processo (sebo, soro, ossos, sangue, etc.) |
| `02 02 03` | Materiais impróprios para consumo ou processamento |
| `02 03 04` | Materiais impróprios para consumo ou processamento |
| `02 05 01` | Materiais impróprios para consumo ou processamento |
| `02 06 01` | Materiais impróprios para consumo ou processamento |
| `02 07 04` | Materiais impróprios para consumo ou processamento |
| `20 01 08` | Resíduos biodegradaveis de cozinhas e cantinas |
| `20 01 25` | Oleos e gorduras alimentares |
| `20 03 02` | Resíduos de mercados públicos e feiras |
| Código do Ibama | Descrição |
| --------------- | ----------------------------------------------------------------------------- |
| `04 02 09` | Resíduos de materiais têxteis (têxteis impregnados, elastomeros, plastomeros) |
| `15 01 09` | Embalagens têxteis |
| `19 12 08` | Têxteis |
| `20 01 10` | Roupas |
| `20 01 11` | Têxteis |
| Código do Ibama | Descrição |
| --------------- | --------------------------------------------------------------------------------------------------------------- |
| `20 02 01` | Resíduos de varrição, limpeza de logradouros e vias publicas e outros servicos de limpeza urbana biodegradaveis |
| Código do Ibama | Descrição |
| --------------- | -------------------------------------------------------------------------------------------------------------------------- |
| `02 01 04` | Resíduos de plásticos (excluindo embalagens) |
| `15 01 02` | Embalagens de plástico |
| `15 01 04` | Embalagens de metal |
| `15 01 05` | Embalagens longa-vida |
| `15 01 06` | Misturas de embalagens |
| `15 01 07` | Embalagens de vidro |
| `16 01 17` | Sucatas metalicas ferrosas |
| `16 01 18` | Sucatas metalicas nao ferrosas |
| `16 01 19` | Plástico |
| `16 01 20` | Vidro |
| `17 02 02` | Vidro |
| `17 02 03` | Plástico |
| `17 04 01` | Cobre, bronze e latão |
| `17 04 02` | Alumínio |
| `17 04 03` | Chumbo |
| `17 04 04` | Zinco |
| `17 04 05` | Ferro e aco |
| `17 04 06` | Estanho |
| `17 04 07` | Mistura de sucatas |
| `17 04 12` | Magnésio |
| `17 04 13` | Níquel |
| `17 05 04` | Solos e rochas nao abrangidos em 17 05 03 |
| `17 05 08` | Britas de linhas ferroviarias nao abrangidos em 17 05 07 |
| `17 06 04` | Materiais de isolamento nao abrangidos em 17 06 01 e 17 06 03 |
| `17 09 04` | Mistura de resíduos de construção e demolição nao abrangidos em 17 09 01, 17 09 02 e 17 09 03 |
| `19 01 02` | Materiais ferrosos removidos das cinzas |
| `19 01 12` | Cinzas e escorias nao abrangidas em 19 01 11 |
| `19 01 18` | Resíduos de pirolise nao abrangidos em 19 01 17 |
| `19 01 19` | Areias de leitos fluidizados |
| `19 03 05` | Resíduos estabilizados nao abrangidos em 19 03 04 |
| `19 03 07` | Resíduos solidificados nao abrangidos em 19 03 06 |
| `19 04 01` | Resíduos vitrificados |
| `19 08 02` | Resíduos do desarenamento |
| `19 09 04` | Carvão ativado usado |
| `19 09 05` | Resinas de troca iônica, saturadas ou usadas |
| `19 10 01` | Resíduos de ferro ou aco |
| `19 12 02` | Metais ferrosos |
| `19 12 03` | Metais nao ferrosos |
| `19 12 04` | Plásticos |
| `19 12 05` | Vidro |
| `19 12 09` | Substancias minerais (por exemplo, areia, rochas) |
| `19 12 11` | Borrachas |
| `20 01 02` | Vidro |
| `20 01 39` | Plásticos |
| `20 01 40` | Metais |
| `20 02 02` | Terras e pedras |
| `20 02 03` | Outros resíduos de varrição, limpeza de logradouros e vias publicas e outros servicos de limpeza urbana nao biodegradaveis |
| Código do Ibama | Descrição |
| --------------- | -------------------------------------------------------------------------------------------------- |
| `02 01 01` | Lodos provenientes da lavagem e limpeza |
| `02 02 01` | Lodos provenientes da lavagem e limpeza |
| `02 03 01` | Lodos de lavagem, limpeza, descasque, centrifugação e separação |
| `03 03 02` | Lodos da lixivia verde (provenientes da valorização da lixivia de cozimento ou licor negro) |
| `03 03 05` | Lodos de branqueamento, provenientes da reciclagem de papel |
| `03 03 09` | Resíduos de lodos de cal |
| `04 01 06` | Lodos, em especial do tratamento local de efluentes, contendo cromo |
| `04 01 07` | Lodos, em especial do tratamento local de efluentes, sem cromo |
| `04 01 10` | Lodo do caleiro |
| `10 01 23` | Lodos aquosas provenientes da limpeza de caldeiras nao abrangidas em 10 01 22 |
| `19 06 05` | Lodo do tratamento anaeróbio de resíduos animais e vegetais |
| `19 06 06` | Lamas e lodos de digestores de tratamento anaeróbio de resíduos animais e vegetais |
| `19 06 99` | Outros resíduos nao anteriormente especificados |
| `19 08 09` | Misturas de gorduras e oleos, da separação oleo/água, contendo apenas oleos e gorduras alimentares |
| Código do Ibama | Descrição |
| --------------- | ------------------------------------------------------------------------------------- |
| `02 02 04` | Lodos do tratamento local de efluentes |
| `02 03 05` | Lodos do tratamento local de efluentes |
| `02 04 03` | Lodos do tratamento local de efluentes |
| `02 05 02` | Lodos do tratamento local de efluentes |
| `02 06 03` | Lodos do tratamento local de efluentes |
| `02 07 05` | Lodos do tratamento local de efluentes |
| `03 03 11` | Lodos do tratamento local de efluentes nao abrangidas em 03 03 10 |
| `04 02 20` | Lodos do tratamento local de efluentes nao abrangidas em 04 02 19 |
| `05 01 10` | Lodos do tratamento local de efluentes nao abrangidas em 05 01 09 |
| `06 05 03` | Lodos do tratamento local de efluentes nao abrangidas em 06 05 02 |
| `07 01 12` | Lodos do tratamento local de efluentes nao abrangidas em 07 01 11 |
| `07 02 12` | Lodos do tratamento local de efluentes nao abrangidas em 07 02 11 |
| `07 03 12` | Lodos do tratamento local de efluentes nao abrangidas em 07 03 11 |
| `07 04 12` | Lodos do tratamento local de efluentes nao abrangidas em 07 04 11 |
| `07 05 12` | Lodos do tratamento local de efluentes nao abrangidas em 07 05 11 |
| `07 06 12` | Lodos do tratamento local de efluentes nao abrangidas em 07 06 11 |
| `07 07 12` | Lodos do tratamento local de efluentes nao abrangidas em 07 07 11 |
| `10 01 21` | Lodos do tratamento local de efluentes nao abrangidas em 10 01 20 |
| `10 11 20` | Resíduos solidos do tratamento local de efluentes nao abrangidos em 10 11 19 |
| `10 12 13` | Lodos do tratamento local de efluentes |
| `19 06 03` | Lodo do tratamento anaeróbio de resíduos urbanos e equiparados |
| `19 06 04` | Lamas e lodos de digestores de tratamento anaeróbio de resíduos urbanos e equiparados |
| `19 08 05` | Lodos do tratamento de efluentes urbanos |
| `19 11 06` | Lodos do tratamento local de efluentes nao abrangidas em 19 11 05 |
| `20 03 04` | Lodos de fossas sépticas |
| `20 03 06` | Resíduos da limpeza de esgotos, bueiros e bocas-de-lobo |
| Código do Ibama | Descrição | % Carbono (base úmida) |
| --------------- | -------------------------------------------------------------------------------------------------------------------- | ---------------------- |
| `02 01 06` | Fezes, urina e estrume de animais (incluindo palha suja), efluentes recolhidos separadamente e tratados noutro local | 15 |
| `02 02 99` | Outros resíduos nao anteriormente especificados | — |
| `02 03 99` | Outros resíduos nao anteriormente especificados | — |
| `02 04 04` | Vinhaça | 1.4 |
| `02 04 05` | Bagaço de cana-de-açúcar | 33 |
| `02 04 99` | Outros resíduos nao anteriormente especificados | — |
| `02 05 99` | Outros resíduos nao anteriormente especificados | — |
| `02 07 02` | Resíduos da destilação de álcool | 8.6 |
| `02 07 99` | Outros resíduos nao anteriormente especificados | — |
| `03 01 99` | Outros resíduos nao anteriormente especificados | — |
| `03 03 99` | Outros resíduos nao anteriormente especificados | — |
| `04 01 01` | Resíduos das operacoes de descarne e divisão de tripa | 18 |
| `04 01 04` | Licores de curtimenta contendo cromo | — |
| `04 01 05` | Licores de curtimenta sem cromo | — |
| `04 01 08` | Aparas, serragem e pos de couro provenientes de couros curtidos ao cromo | 33 |
| `04 01 09` | Resíduos da confecção e acabamentos | — |
| `04 01 99` | Outros resíduos nao anteriormente especificados | — |
| `04 02 10` | Materia orgânica de produtos naturais (por exemplo, gordura, cera) | 18 |
| `04 02 15` | Resíduos dos acabamentos nao abrangidos em 04 02 14 | 18 |
| `04 02 99` | Outros resíduos nao anteriormente especificados | — |
| `05 06 99` | Outros resíduos nao anteriormente especificados | — |
| `05 07 99` | Outros resíduos nao anteriormente especificados | — |
| `06 02 99` | Outros resíduos nao anteriormente especificados | — |
| `06 03 99` | Outros resíduos nao anteriormente especificados | — |
| `06 04 99` | Outros resíduos nao anteriormente especificados | — |
| `06 07 99` | Outros resíduos nao anteriormente especificados | — |
| `06 09 99` | Outros resíduos nao anteriormente especificados | — |
| `06 11 99` | Outros resíduos nao anteriormente especificados | — |
| `07 01 99` | Outros resíduos nao anteriormente especificados | — |
| `07 02 99` | Outros resíduos nao anteriormente especificados | — |
| `07 03 99` | Outros resíduos nao anteriormente especificados | — |
| `07 04 99` | Outros resíduos nao anteriormente especificados | — |
| `07 05 14` | Resíduos solidos nao abrangidos em 07 05 13 | — |
| `07 05 99` | Outros resíduos nao anteriormente especificados | — |
| `07 06 99` | Outros resíduos nao anteriormente especificados | — |
| `07 07 99` | Outros resíduos nao anteriormente especificados | — |
| `08 01 99` | Outros resíduos nao anteriormente especificados | — |
| `08 02 99` | Outros resíduos nao anteriormente especificados | — |
| `08 03 99` | Outros resíduos nao anteriormente especificados | — |
| `08 04 99` | Outros resíduos nao anteriormente especificados | — |
| `09 01 99` | Outros resíduos nao anteriormente especificados | — |
| `10 01 99` | Outros resíduos nao anteriormente especificados | — |
| `10 02 08` | Resíduos solidos do tratamento de gases nao abrangidos em 10 02 07 | — |
| `10 02 15` | Outras lodos e tortas de filtro | 9 |
| `10 02 99` | Outros resíduos nao anteriormente especificados | — |
| `10 03 99` | Outros resíduos nao anteriormente especificados | — |
| `10 04 99` | Outros resíduos nao anteriormente especificados | — |
| `10 05 99` | Outros resíduos nao anteriormente especificados | — |
| `10 06 99` | Outros resíduos nao anteriormente especificados | — |
| `10 08 99` | Outros resíduos nao anteriormente especificados | — |
| `10 09 99` | Outros resíduos nao anteriormente especificados | — |
| `10 10 99` | Outros resíduos nao anteriormente especificados | — |
| `10 11 99` | Outros resíduos nao anteriormente especificados | — |
| `10 12 99` | Outros resíduos nao anteriormente especificados | — |
| `10 13 99` | Outros resíduos nao anteriormente especificados | — |
| `11 01 10` | Lodos e tortas de filtro nao abrangidos em 11 01 09 | 9 |
| `11 01 99` | Outros resíduos nao anteriormente especificados | — |
| `11 02 99` | Outros resíduos nao anteriormente especificados | — |
| `11 05 99` | Outros resíduos nao anteriormente especificados | — |
| `12 01 99` | Outros resíduos nao anteriormente especificados | — |
| `16 01 99` | Outros resíduos nao anteriormente especificados | — |
| `16 03 06` | Resíduos orgânicos nao abrangidos em 16 03 05 | 5 |
| `16 07 99` | Outros resíduos nao anteriormente especificados | — |
| `17 05 06` | Lodos de dragagem nao abrangidas em 17 05 05 | 5 |
| `19 01 99` | Outros resíduos nao anteriormente especificados | — |
| `19 02 03` | Misturas de resíduos contendo apenas resíduos nao perigosos | 5 |
| `19 02 06` | Lodos de tratamento físico-quimico nao abrangidas em 19 02 05 | 5 |
| `19 02 99` | Outros resíduos nao anteriormente especificados | — |
| `19 05 01` | Fração nao compostada de resíduos urbanos e equiparados | 15 |
| `19 05 02` | Fração nao compostada de resíduos animais e vegetais | 15 |
| `19 05 03` | Composto fora de especificação | 5 |
| `19 05 99` | Outros resíduos nao anteriormente especificados | — |
| `19 07 02` | Lixiviados ou líquidos percolados de aterros contendo substancias perigosas | — |
| `19 07 03` | Lixiviados ou líquidos percolados de aterros nao abrangidos em 19 07 02 | 9 |
| `19 08` | Resíduos de estações de tratamento de efluentes (ETE) nao anteriormente especificados | 9 |
| `19 08 01` | Resíduos retirados da fase de gradeamento | 5 |
| `19 08 12` | Lodos do tratamento biologico de efluentes industriais nao abrangidas em 19 08 11 | 9 |
| `19 08 14` | Lodos de outros tratamentos de efluentes industriais nao abrangidas em 19 08 13 | 9 |
| `19 08 99` | Outros resíduos nao anteriormente especificados | — |
| `19 09 01` | Resíduos retirados da fase de gradeamento | 5 |
| `19 09 06` | Soluções e lodos da regeneração de colunas de troca iônica | — |
| `19 09 99` | Outros resíduos nao anteriormente especificados | — |
| `19 10 02` | Resíduos nao ferrosos | — |
| `19 10 06` | Outras frações nao abrangidas em 19 10 05 | — |
| `19 11 99` | Outros resíduos nao anteriormente especificados | — |
| `19 12 10` | Resíduos combustíveis (combustíveis derivados de resíduos) | — |
| `19 12 13` | Outros resíduos (incluindo misturas de materiais) do tratamento mecanico de resíduos nao abrangidos em 19 12 12 | — |
| `19 13 02` | Resíduos solidos da descontaminação de solos nao abrangidos em 19 13 01 | — |
| `19 13 04` | Lodos da descontaminação de solos nao abrangidas em 19 13 03 | — |
| `19 13 06` | Lodos da descontaminação de águas freáticas nao abrangidas em 19 13 05 | — |
| `19 13 08` | Resíduos líquidos aquosos e concentrados aquosos da descontaminação de águas freáticas nao abrangidos em 19 13 07 | — |
| `20 01 99` | Outras frações nao anteriormente especificadas | — |
| `20 03 01` | Outros resíduos urbanos e equiparados, incluindo misturas de resíduos | 5 |
| `20 03 03` | Resíduos da limpeza de ruas e de galerias de drenagem pluvial | 20 |
| `20 03 99` | Resíduos urbanos e equiparados nao anteriormente especificados | 5 |
Para códigos sob CDM 8.7D onde o % de Carbono nao esta listado, o reciclador deve especificar o tipo de resíduo e/ou fornecer um laudo laboratorial. A fração de carbono e utilizada pela regra `prevented-emissions` (regra 21) para calcular fatores de emissão dinamicos — consulte [Cenario de linha de base e fatores de emissão](#cenario-de-linha-de-base-e-fatores-de-emissão).
## Parametros-chave [#parametros-chave]
| Parametro | Valor |
| --------------------------------- | --------------------------------------------------------------------------- |
| **Prazo do ciclo de compostagem** | Validado entre os eventos DROP\_OFF e RECYCLED |
| **Tolerância de geolocalização** | Enderecos dos participantes validados em relação aos enderecos credenciados |
| **Limite do projeto** | Distancia entre o primeiro PICK\_UP e o ultimo DROP\_OFF validada |
| **Unidade do documento** | Quilogramas (kg) |
| **Tipo de documento** | Orgânico |
| **Periodo do projeto** | O evento RECYCLED deve ocorrer em ou apos 1º de janeiro do ano anterior |
## Regras de validação [#regras-de-validação]
Consulte o catalogo de [Regras do BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon/application/application-rules) para a lista completa de regras de validação, agrupadas por categoria com descricoes.
## Downloads [#downloads]
Feedback: [method@carrot.eco](mailto:method@carrot.eco)
***
## Regras do framework [#regras-do-framework]
As regras do framework definem **o que** deve ser verificado na metodologia BOLD Carbon (CH₄). Cada regra do framework especifica um requisito de validação no nível de especificação.
Essas regras são implementadas por uma ou mais [regras de aplicação](/docs/methodologies/ams-iii-f/bold-carbon/application/application-rules) que contêm a lógica de validação executável. O mapeamento não é um-para-um: uma única regra de aplicação pode satisfazer múltiplas regras do framework, e uma regra do framework pode exigir múltiplas regras de aplicação para verificação completa.
[Ver regras de aplicação](/docs/methodologies/ams-iii-f/bold-carbon/application/application-rules) · [Saiba mais sobre AMS-III.F](/docs/methodologies/ams-iii-f)
# Framework BOLD Recycling Credit
## Resumo do framework [#resumo-do-framework]
| Propriedade | Valor |
| -------------------------- | ------------------------------------------------------------------------------------------------------- |
| **Metodologia** | [BOLD Recycling](/docs/methodologies/bold-recycling) |
| **Versão** | 1.0.1 |
| **Status** | Publicado |
| **Tipo de crédito** | Crédito de Reciclagem |
| **Token** | [TRC](/docs/protocol/credits#tokenized-recycling-credits-trc) (`C-BIOW`) — emitido por esta metodologia |
| **Documento do framework** | [PDF](https://drive.google.com/file/d/1Qdod8Qy3zT4lBkUp1TIyuxguHIYTevJJ/view) |
## Escopo [#escopo]
O [MvF](/docs/standard/concepts/mvf) BOLD Recycling define procedimentos de verificação para o desvio de resíduos orgânicos de aterros sanitários para instalações de compostagem:
* **Tipos de resíduos**: Resíduos alimentares, resíduos verdes (podas de jardins, quintais e parques), lodo de estações de tratamento de resíduos, resíduos da indústria do tabaco e outros subtipos orgânicos classificados sob códigos de resíduos do CDM
* **Tratamento**: Compostagem aeróbica em instalações profissionais
* **Geografia**: Atualmente operacional no Brasil, com o framework projetado para ser expansível a outras regiões com sistemas de classificação de resíduos compatíveis
## Critérios de elegibilidade [#critérios-de-elegibilidade]
Os participantes devem atender aos requisitos de homologação:
* **[Geradores de resíduos](/docs/protocol/supply-chain)** — Devem ser identificados com documentação válida. Datas de homologação são opcionais.
* **Transportadores** — Obrigatórios para transporte por caminhão e barco; opcionais para coleta por tubulação de lodo e carrinho.
* **Processadores** — Exatamente um processador deve ser identificado por [MassID](/docs/protocol/mass-ids).
* **[Recicladores](/docs/protocol/supply-chain#o-papel-do-reciclador)** — Exatamente um reciclador (instalação de compostagem) deve ser identificado com datas de homologação válidas.
* **[Integradores](/docs/protocol/network-integrators)** — Devem ter datas de homologação válidas.
## Requisitos de verificação [#requisitos-de-verificação]
O framework especifica verificações em toda a cadeia de suprimentos:
* **Validação de documentos** — Estrutura, tipo, unidade e valor do MassID
* **Identificação de atores** — Presença e identidade de todos os participantes obrigatórios
* **Validação de eventos** — Dados de pesagem, triagem, entrega e ciclo de compostagem
* **Geolocalização** — Correspondência de endereços entre eventos e locais homologados
* **Manifestos** — Documentação obrigatória de transporte e reciclagem
* **Conformidade** — Classificação regional de resíduos e validade do período do projeto
* **Integridade** — Verificações de unicidade para prevenir contagem dupla
## Parâmetros-chave [#parâmetros-chave]
| Parâmetro | Valor |
| ----------------------------------- | ---------------------------------------------------------------------- |
| **Período do ciclo de compostagem** | Validado entre os eventos Drop Off e Recycled |
| **Tolerância de geolocalização** | Endereços dos participantes validados contra endereços homologados |
| **Unidade do documento** | Quilogramas (kg) |
| **Tipo do documento** | Orgânico |
| **Período do projeto** | O evento Recycled deve ocorrer em ou após 1 de janeiro do ano anterior |
## Regras de validação [#regras-de-validação]
Consulte o catálogo de [regras do BOLD Recycling](/docs/methodologies/bold-recycling/framework/application/application-rules) para a lista completa de regras de validação, agrupadas por categoria com descrições.
## Downloads [#downloads]
* [Framework de Metodologia BOLD Recycling v1.0.1 (PDF)](https://drive.google.com/file/d/1Qdod8Qy3zT4lBkUp1TIyuxguHIYTevJJ/view)
Feedback: [method@carrot.eco](mailto:method@carrot.eco)
***
## Regras do framework [#regras-do-framework]
As regras de framework definem **o que** deve ser verificado na metodologia BOLD Recycling. Cada regra de framework especifica um requisito de validação em nível de especificação.
Essas regras são implementadas por uma ou mais [regras de aplicação](/docs/methodologies/bold-recycling/framework/application/application-rules) que contêm a lógica de validação executável. O mapeamento não é um-para-um: uma única regra de aplicação pode satisfazer múltiplas regras de framework, e uma regra de framework pode exigir múltiplas regras de aplicação para verificação completa.
[Ver regras de aplicação](/docs/methodologies/bold-recycling/framework/application/application-rules) · [Saiba mais sobre o BOLD Recycling](/docs/methodologies/bold-recycling)
# Categorias de Contratos
## Visão geral [#visão-geral]
Os contratos inteligentes da Rede Carrot são organizados em cinco categorias, cada uma com uma responsabilidade distinta. Esse design modular mantém os contratos individuais focados e auditáveis, enquanto o [ContractRegistry](#registros) os conecta em tempo de execução.
| Categoria | Contratos | Responsabilidade |
| ----------------- | ----------------------------------------------------------------------- | ------------------------------------- |
| **Controladores** | InventoryManager, CreditPurchaseManager, CreditRetirementManager | Lógica de negócio e orquestração |
| **Custodiantes** | Vault, RewardsVault | Custódia de ativos e distribuição |
| **NFTs** | MassID, Certificate, `CreditPurchaseReceipt`, `CreditRetirementReceipt` | Tokens de prova soulbound (ERC-721) |
| **Tokens** | Credit | Tokens de crédito fungíveis (ERC-20) |
| **Registros** | ContractRegistry, CertificateRegistry | Descoberta e rastreamento de relações |
## Controladores [#controladores]
Os controladores são os pontos de entrada para todas as operações principais. Eles orquestram fluxos de trabalho que abrangem múltiplos contratos, garantindo que cada operação seja executada atomicamente — ou todos os passos são bem-sucedidos ou nenhum deles é.
### InventoryManager [#inventorymanager]
Cria os ativos on-chain fundamentais. Quando os dados verificados estão prontos para minting, o InventoryManager minta NFTs de [MassID](/docs/protocol/mass-ids) e, em uma segunda transação, NFTs de [Certificado](/docs/protocol/certificates) e tokens de [Crédito](/docs/protocol/credits), no momento em que o crédito é emitido a partir do lote verificado. Ele também registra os relacionamentos entre esses ativos por meio do CertificateRegistry. Todos os ativos mintados são depositados no Vault.
### CreditPurchaseManager [#creditpurchasemanager]
Executa [compras de créditos](/docs/protocol/credit-purchase) atômicas. Em uma única transação, o CreditPurchaseManager:
* Valida a ordem de compra usando uma assinatura de dados tipados EIP-712
* Processa o pagamento em USDC
* Atualiza os registros de certificados de lastro
* Transfere os tokens de crédito para o comprador — para compras que não são integralmente aposentadas na mesma transação
* Minta um `CreditPurchaseReceipt` como prova permanente
* Registra as alocações de recompensas para os participantes
O CreditPurchaseManager suporta **aposentadoria integrada** — comprar e aposentar créditos em uma única transação — e esse é o caminho em uso hoje: toda compra é atualmente aposentada integralmente no momento da venda, de modo que os créditos são queimados em vez de entregues ao comprador. Os contratos também suportam aposentadoria parcial, com o restante transferido ao comprador, o que ainda não é usado em produção.
### CreditRetirementManager [#creditretirementmanager]
Realiza a [aposentadoria de créditos](/docs/protocol/credit-retirement) standalone para detentores que desejam remover permanentemente créditos de circulação. O CreditRetirementManager queima os tokens de crédito, atualiza o rastreamento de certificados de lastro e minta um `CreditRetirementReceipt` como prova permanente da aposentadoria.
## Custodiantes [#custodiantes]
Os custodiantes mantêm e gerenciam ativos em nome do ecossistema. Eles aplicam controles de acesso rigorosos — apenas contratos autorizados (controladores) podem transferir ou queimar ativos sob custódia.
### Vault [#vault]
O custodiante central para todos os NFTs soulbound (MassIDs, Certificados, NFTs de `CreditPurchaseReceipt` e `CreditRetirementReceipt`) e saldos de tokens de crédito antes da compra. O Vault é o lar permanente de todos os tokens não transferíveis do sistema, garantindo que permaneçam permanentes e rastreáveis, exceto quando revogados. Os tokens de crédito também são mantidos aqui como inventário disponível até que um comprador os adquira.
### RewardsVault [#rewardsvault]
Gerencia o sistema de [distribuição de recompensas](/docs/protocol/rewards-distribution) com preservação de privacidade. Durante as compras de créditos, os pagamentos em USDC são depositados no RewardsVault, e compromissos criptográficos (Merkle roots) representando a distribuição de recompensas são registrados on-chain. Isso mantém as identidades dos participantes pseudônimas — apenas um hash com escopo de compra é armazenado on-chain, e os hashes, sozinhos, não podem ser correlacionados entre compras. A carteira que reivindica e o valor tornam-se visíveis on-chain quando a recompensa é sacada, então reutilizar uma mesma carteira vincula os saques de um participante entre si. Os participantes reivindicam suas recompensas fornecendo Merkle proofs que são verificadas contra as roots armazenadas. O RewardsVault mantém USDC alocado para recompensas até que os participantes os reivindiquem.
## NFTs (Soulbound ERC-721) [#nfts-soulbound-erc-721]
Todos os NFTs na Rede Carrot são **soulbound** — não transferíveis e mantidos permanentemente pelo Vault. Nenhum NFT pode ser transferido, vendido ou negociado. A única exceção é a [revogação](/docs/protocol/smart-contracts/on-chain-flows#revogação) — um operador pode queimar um MassID ou Certificate e apontar seus metadados para um registro de revogação quando os dados subjacentes se mostram incorretos; os metadados originais e o motivo permanecem recuperáveis on-chain.
### MassID [#massid]
Representa um lote verificado de material residual. Cada MassID registra o tipo de material, peso e a cadeia completa de custódia desde a geração do resíduo até a coleta e triagem. Os MassIDs são a base do [ciclo de vida dos créditos](/docs/protocol/credit-lifecycle) — cada certificado pode ser rastreado até um único MassID.
### Certificate [#certificate]
Representa um resultado ambiental verificado — seja reciclagem (RecycledID) ou reduções de emissões de carbono (GasID). Os Certificados são vinculados ao seu MassID de origem por meio do CertificateRegistry e rastreiam seu ciclo de vida por meio de quatro quantidades: o **montante total** (definido no minting), o **montante comprado** (atualizado a cada venda), o **montante aposentado** (atualizado a cada aposentadoria) e o **montante disponível** — derivado no momento da leitura como o total menos o comprado; o montante aposentado não o afeta. Esse modelo contábil é central para a prevenção de dupla contagem — o contrato garante que créditos não possam ser vendidos além do saldo disponível, nem aposentados além do montante efetivamente comprado.
### CreditPurchaseReceipt [#creditpurchasereceipt]
Prova auditável de que uma compra de crédito ocorreu. Cada recibo registra quais certificados estavam envolvidos, o endereço do comprador, o montante comprado e os detalhes do pagamento. Os recibos de compra são visíveis no [Carrot Registry](/docs/protocol/registry) e fornecem um registro permanente para conformidade e relatórios.
### CreditRetirementReceipt [#creditretirementreceipt]
Prova permanente de que créditos foram aposentados (queimados). Os recibos de aposentadoria registram os certificados envolvidos, o montante aposentado e a parte que realizou a aposentadoria. São utilizados para relatórios ESG e conformidade regulatória, e podem ser visualizados no [Carrot Registry](/docs/protocol/registry) ou em qualquer explorador de blockchain (ex.: [PolygonScan](https://polygonscan.com/)).
## Tokens (Fungíveis ERC-20) [#tokens-fungíveis-erc-20]
### Credit [#credit]
Tokens de crédito ambiental fungíveis. A Rede Carrot emite dois tipos de crédito:
| Símbolo | Nome | Representa |
| ------------ | -------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------- |
| `C-BIOW` | Tokenized Recycling Credit (TRC), ex.: do [BOLD Recycling](/docs/methodologies/bold-recycling) | 1 tonelada métrica de material reciclado certificado |
| `C-CARB.CH4` | Tokenized Carbon Credit (TCC), ex.: do [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) (metano) | 1 tonelada métrica de CO₂ equivalente em reduções |
Os créditos são os **únicos tokens transferíveis** do sistema. São projetados para atividade de mercado — compra, custódia e aposentadoria de compensações ambientais. Todos os outros tokens (MassIDs, certificados, recibos) são soulbound e não podem ser transferidos. O sistema de créditos é projetado para suportar tipos de crédito adicionais além dos atuais `C-BIOW` e `C-CARB.CH4` conforme novas metodologias ambientais forem validadas.
## Registros [#registros]
Os registros fornecem a infraestrutura para coordenação de contratos e rastreamento de relacionamentos. Eles não contêm lógica de negócio, mas são essenciais para a capacidade de atualização e a rastreabilidade do sistema.
### ContractRegistry [#contractregistry]
O registro central que mapeia nomes lógicos de contratos para seus endereços implantados on-chain. Em vez de codificar endereços diretamente, os contratos consultam o ContractRegistry para descobrir uns aos outros em tempo de execução. Isso desacopla os contratos dos endereços uns dos outros. Uma atualização de lógica comum não exige nenhuma alteração no registro — o endereço do proxy é estável, então os dependentes continuam resolvendo a mesma entrada. O registro importa quando um contrato é totalmente **substituído** por um novo proxy: isso exige uma escrita no registro mais migração explícita de estado, em vez de reimplantar cada contrato dependente.
### CertificateRegistry [#certificateregistry]
Rastreia o relacionamento pai-filho entre tokens [MassID](/docs/protocol/mass-ids) e seus [certificados](/docs/protocol/certificates) vinculados. Cada certificado pode ser rastreado, por meio deste registro, até o lote específico de resíduos que ele representa. O CertificateRegistry é o que torna a rastreabilidade de ponta a ponta possível — de um crédito aposentado, passando por seu certificado, até o resíduo físico.
## Relacionamentos entre tokens [#relacionamentos-entre-tokens]
Os ativos on-chain formam um grafo direcionado de relacionamentos:
* **MassID → Certificate** — Vinculados por meio do CertificateRegistry. Um único MassID pode lastrear vários certificados; cada certificado é lastreado por exatamente um MassID.
* **Certificate → Credit** — Os tokens de crédito são gerados no momento do minting em quantidades correspondentes aos seus certificados de lastro.
* **`CreditPurchaseReceipt`** e **`CreditRetirementReceipt`** — Registram transações contra certificados específicos, fornecendo a trilha de auditoria para cada compra e aposentadoria.
Essa estrutura garante que cada crédito em circulação possa ser rastreado, por meio de seu certificado, até o lote específico de resíduos que o produziu.
## Próximos passos [#próximos-passos]
* [Fluxos On-Chain](/docs/protocol/smart-contracts/on-chain-flows) — Passo a passo de como esses contratos interagem durante o minting, compra e aposentadoria.
* [Segurança](/docs/protocol/smart-contracts/security) — Controle de acesso, pausabilidade e proteções de governança.
* [Ciclo de Vida dos Créditos](/docs/protocol/credit-lifecycle) — O ciclo de vida MassID → Certificate → Credit.
# Visão Geral da Arquitetura de Contratos
## Por que o registry público de créditos opera em uma blockchain pública [#por-que-o-registry-público-de-créditos-opera-em-uma-blockchain-pública]
A Rede Carrot registra cada [crédito ambiental](/docs/protocol/credits) em uma blockchain pública para garantir três propriedades que bancos de dados tradicionais não conseguem oferecer:
* **Imutabilidade** — Cada emissão, compra e aposentadoria é permanentemente registrada on-chain, e os metadados de proveniência são endereçados por conteúdo no IPFS, onde a disponibilidade contínua depende de pinning ativo. O ponteiro de metadados de um token pode ser corrigido pela governança, e MassIDs e certificados podem ser revogados — em ambos os casos, a alteração é ela própria registrada on-chain. A lógica contratual no nível do protocolo (verificações de uso único e destruição permanente na aposentadoria) previne a dupla contagem.
* **Transparência** — Todas as transações são publicamente verificáveis na blockchain. Qualquer pessoa pode inspecionar o histórico completo de um crédito via [Carrot Registry](/docs/protocol/registry) ou qualquer explorador de blockchain (ex.: [PolygonScan](https://polygonscan.com/)), sem necessidade de acesso ou credenciais especiais. Confiança e verificação não dependem da infraestrutura da Carrot.
* **Auditabilidade** — Registros do Registry e cada evento do ciclo de vida do crédito (emissão, compra, aposentadoria) existem on-chain. Junto com os dados da plataforma no [Carrot Registry](/docs/protocol/registry), toda a cadeia — do resíduo físico ao crédito aposentado — é rastreável. Auditores, reguladores e stakeholders podem verificar independentemente o ciclo de vida sem depender dos registros de uma única entidade.
## Implantação [#implantação]
Os smart contracts da Rede Carrot são implementados em Solidity e compatíveis com qualquer blockchain compatível com EVM. Atualmente estão implantados na [Polygon PoS](https://polygon.technology/), selecionada por seus baixos custos de transação e total compatibilidade com EVM, permitindo que a rede processe altos volumes de operações de emissão, compra e aposentadoria sem taxas de gas proibitivas, mantendo compatibilidade com o ecossistema Ethereum mais amplo. A plataforma é agnóstica em relação à rede blockchain e poderia ser implantada em outras redes compatíveis com EVM no futuro.
## Visão geral da arquitetura [#visão-geral-da-arquitetura]
O ecossistema de smart contracts segue uma **arquitetura modular** organizada em cinco categorias de contratos. Cada categoria tem uma responsabilidade bem definida, e os contratos interagem através de interfaces bem definidas em vez de lógica monolítica.
| Categoria | Contratos | Função |
| --------------- | ------------------------------------------------------------------- | -------------------------------------------------------- |
| **Controllers** | InventoryManager, CreditPurchaseManager, CreditRetirementManager | Orquestram operações multi-contrato |
| **Custodians** | Vault, RewardsVault | Mantêm e gerenciam ativos (créditos, NFTs, USDC) |
| **NFTs** | MassID, Certificate, CreditPurchaseReceipt, CreditRetirementReceipt | Tokens soulbound ERC-721 representando ativos e provas |
| **Tokens** | Credit | Tokens fungíveis ERC-20 de crédito ambiental |
| **Registries** | ContractRegistry, CertificateRegistry | Descoberta de serviços e rastreamento de relacionamentos |
Essa separação mantém cada contrato focado e auditável. Controllers contêm a lógica de negócio, custodians gerenciam a custódia de ativos, e NFTs e tokens representam os próprios ativos. Registries fornecem a infraestrutura que conecta tudo.
## Princípios de design [#princípios-de-design]
### Atualizabilidade (UUPS) [#atualizabilidade-uups]
Todos os contratos utilizam o **Universal Upgradeable Proxy Standard (UUPS)**, permitindo que o protocolo evolua sem perder estado ou exigir reimplantação. Quando um contrato é atualizado, seu endereço permanece o mesmo e os dados armazenados são preservados — a lógica muda, e a chamada de atualização também pode executar uma migração sobre esse armazenamento existente. Isso permite que a equipe corrija bugs, adicione funcionalidades e melhore a eficiência, preservando a integridade do registro on-chain.
### Descoberta baseada em registry [#descoberta-baseada-em-registry]
Os contratos localizam uns aos outros através do **ContractRegistry** usando chaves lógicas em vez de endereços hardcoded. Isso desacopla os contratos entre si e permite atualizações independentes. Uma atualização de lógica mantém o endereço do proxy, então nenhuma alteração no Registry é necessária e todos os pares continuam resolvendo a mesma entrada. O Registry importa quando um contrato é substituído por um novo proxy: atualizar essa única entrada reaponta todos os pares sem reimplantar nenhum deles. De qualquer forma, contratos individuais podem ser melhorados, corrigidos ou estendidos sem uma reimplantação de todo o sistema.
### NFTs soulbound [#nfts-soulbound]
Todos os NFTs na Rede Carrot são [**soulbound**](/docs/protocol/credit-lifecycle) — **não transferíveis** e permanentemente mantidos pelo contrato Vault. Isso preserva a integridade da trilha de auditoria ambiental — tokens não podem ser movidos, vendidos ou ocultados. Um MassID ou [certificado](/docs/protocol/certificates) pode ser queimado por [revogação](/docs/protocol/smart-contracts/on-chain-flows#revogação); cada emissão, tentativa de transferência e revogação permanece no log de eventos on-chain, de modo que a cadeia de evidências sobrevive ao token.
### Meta-transações [#meta-transações]
Compradores nunca precisam possuir o token de gas nativo da rede ou pagar taxas de transação da blockchain — a Carrot envia as transações de compra e aposentadoria em nome deles, removendo uma barreira significativa para adoção por compradores novos em blockchain. Os contratos de compra e aposentadoria de créditos implementam o padrão de meta-transações **ERC-2771**, de modo que isso também pode ser delegado a um relayer confiável.
### Controle de acesso baseado em funções [#controle-de-acesso-baseado-em-funções]
Cada contrato implementa **RBAC** com funções definidas para operações cotidianas, atualizações e ações emergenciais. Os cinco papéis são atribuídos a cinco endereços distintos, de modo que a operação rotineira exige mais de uma chave. Consulte [Segurança](/docs/protocol/smart-contracts/security) para o que essa separação garante e o que não garante.
### Pausabilidade [#pausabilidade]
Operações críticas podem ser pausadas em emergências, interrompendo toda movimentação de saldo do contrato enquanto uma vulnerabilidade ou incidente é investigado. Pausas emergenciais **têm expiração de 48 horas**, após a qual qualquer conta pode encerrá-las. Pausas padrão, mantidas por uma função de pauser separada, persistem até serem explicitamente encerradas. Consulte [Segurança](/docs/protocol/smart-contracts/security) para o modelo completo de controle de acesso e pausabilidade, incluindo como um incidente em curso é mantido aberto além dessa janela.
## Próximos passos [#próximos-passos]
* [Categorias de Contratos](/docs/protocol/smart-contracts/contract-categories) — Detalhamento de cada contrato e seu papel no sistema.
* [Fluxos On-Chain](/docs/protocol/smart-contracts/on-chain-flows) — Passo a passo de emissão, compra, recompensas e aposentadoria.
* [Segurança](/docs/protocol/smart-contracts/security) — Controle de acesso, segurança de governança e mecanismos anti-manipulação.
# Fluxos On-Chain
## Visão geral [#visão-geral]
Os [smart contracts](/docs/protocol/smart-contracts) da Rede Carrot executam cinco fluxos on-chain principais. Toda transação é **atômica** — ou todos os passos são concluídos com sucesso ou nenhum deles é, prevenindo alterações parciais de estado. O minting ocupa duas transações por desenho, porque elas acontecem em momentos diferentes: o MassID é mintado quando o lote de resíduos é verificado, e o certificado é mintado quando o crédito é emitido a partir dele.
Todas as transações são registradas on-chain e visíveis por meio de qualquer explorador de blockchain (por exemplo, [PolygonScan](https://polygonscan.com/)). As principais operações também são exibidas no [Carrot Registry](/docs/protocol/registry) com contexto ambiental e dados de rastreabilidade.
## Minting [#minting]
Quando dados verificados estão prontos para minting, o **InventoryManager** cria os ativos on-chain fundamentais em duas etapas, cada uma em sua própria transação.
### Passo 1 — Minting de MassID [#passo-1--minting-de-massid]
NFTs [MassID](/docs/protocol/mass-ids) são mintados para o [Vault](/docs/protocol/smart-contracts), cada um com uma URI de metadados no [IPFS](https://ipfs.tech/) contendo dados de proveniência: tipo de material, peso, origem geográfica e a cadeia de custódia completa, desde a geração do resíduo até a coleta e triagem.
### Passo 2 — Minting de certificado e crédito [#passo-2--minting-de-certificado-e-crédito]
NFTs de [certificado](/docs/protocol/certificates) são mintados e vinculados aos MassIDs correspondentes por meio do CertificateRegistry. Tokens de [crédito](/docs/protocol/credits) fungíveis (ERC-20) são mintados em quantidades equivalentes e depositados no Vault.
Após a minting, todos os ativos ficam mantidos pelo Vault e prontos para compra de créditos. O CertificateRegistry registra qual MassID respalda cada certificado, estabelecendo a cadeia de rastreabilidade que persiste por toda a vida útil desses ativos.
## Compra de créditos [#compra-de-créditos]
Uma **transação atômica** executada pelo CreditPurchaseManager que realiza toda a [compra](/docs/protocol/credit-purchase) em uma única operação. Se qualquer passo falhar, toda a transação é revertida.
### Passo 1 — Validação da assinatura de compra [#passo-1--validação-da-assinatura-de-compra]
A ordem de compra é verificada usando uma assinatura de dados tipados **EIP-712** de um signatário autorizado. Essa validação criptográfica garante que apenas ordens de compra legítimas e pré-aprovadas sejam executadas on-chain.
### Passo 2 — Pagamento [#passo-2--pagamento]
USDC é transferido do pagador para o RewardsVault, onde fica disponível para [distribuição de recompensas](/docs/protocol/rewards-distribution) aos participantes.
### Passo 3 — Atualização do certificado [#passo-3--atualização-do-certificado]
O valor comprado é registrado em cada certificado de respaldo, reduzindo o inventário disponível. Isso garante que os mesmos créditos não possam ser vendidos duas vezes.
### Passo 4 — Entrega ou aposentadoria de créditos [#passo-4--entrega-ou-aposentadoria-de-créditos]
Hoje, todo crédito comprado é aposentado na mesma transação, de modo que nenhum token de crédito é entregue à carteira do comprador. Os contratos também suportam aposentadoria parcial, com tokens de crédito (por exemplo, `C-BIOW`, `C-CARB.CH4`) transferidos do Vault para a carteira do comprador no restante — uma capacidade que ainda não é usada em produção.
### Passo 5 — Minting do recibo [#passo-5--minting-do-recibo]
Um NFT **`CreditPurchaseReceipt`** é mintado para o Vault como prova permanente e auditável da transação. O recibo registra os certificados envolvidos, o comprador, o valor e os detalhes do pagamento.
### Passo 6 — Registro de recompensas [#passo-6--registro-de-recompensas]
Uma raiz Merkle representando a distribuição completa de recompensas é registrada no RewardsVault. Isso permite que os participantes reivindiquem sua parcela do pagamento sem revelar detalhes de identidade on-chain.
### Aposentadoria integrada [#aposentadoria-integrada]
Com a **aposentadoria integrada**, os créditos são queimados (em vez de transferidos ao comprador) na mesma transação, e um `CreditRetirementReceipt` também é mintado. É assim que toda compra funciona hoje: compradores adquirem e aposentam créditos em um único passo, e reivindicam a compensação ambiental imediatamente.
## Distribuição de recompensas [#distribuição-de-recompensas]
A distribuição de recompensas utiliza um **mecanismo de preservação de privacidade** que mantém as identidades individuais dos participantes off-chain, enquanto preserva a verificabilidade on-chain.
### Registro [#registro]
Durante cada compra de créditos, uma **raiz Merkle** é registrada on-chain no RewardsVault. Essa raiz representa a distribuição completa de recompensas para aquela transação. As identidades dos participantes permanecem pseudônimas — apenas compromissos com hash são armazenados publicamente on-chain. Os dados de distribuição subjacentes são mantidos off-chain pelo backend.
### Reivindicação [#reivindicação]
Os participantes podem reivindicar suas recompensas fornecendo **provas Merkle** que verificam seu direito contra a raiz on-chain. O RewardsVault valida a prova e libera o USDC alocado ao requerente. Cada alocação só pode ser reivindicada uma vez — o contrato rastreia o status de reivindicação para prevenir reivindicações duplicadas.
### Auditabilidade [#auditabilidade]
Embora as identidades individuais dos participantes não sejam visíveis on-chain, auditores autorizados podem acessar os dados de distribuição subjacentes para identificar participantes para fins de conformidade. As raízes Merkle on-chain servem como compromissos criptográficos de que os dados off-chain não foram adulterados.
## Aposentadoria de crédito (independente) [#aposentadoria-de-crédito-independente]
Para detentores de créditos que desejam [aposentar](/docs/protocol/credit-retirement) créditos que já possuem, o **CreditRetirementManager** executa um fluxo de aposentadoria independente.
### Passo 1 — Validação da assinatura de aposentadoria [#passo-1--validação-da-assinatura-de-aposentadoria]
A ordem de aposentadoria é verificada usando uma assinatura de dados tipados **EIP-712**, garantindo que apenas solicitações de aposentadoria autorizadas sejam processadas.
### Passo 2 — Queima de créditos [#passo-2--queima-de-créditos]
Tokens de crédito são **queimados** (destruídos permanentemente) do saldo do próprio Vault, não diretamente da carteira do detentor. O detentor, portanto, transfere os créditos para o Vault antes, como uma transferência comum de token.
Esse depósito é uma transação separada, fora da aposentadoria atômica descrita aqui: se a ordem de aposentadoria falhar depois, o depósito não é revertido junto, e os contratos não expõem caminho de retorno — apenas controladores autorizados podem movimentar ativos para fora do Vault. Nesse caso, reenvie a ordem de aposentadoria em vez de considerar os créditos perdidos.
Tokens queimados nunca podem ser recuperados ou reemitidos — a compensação ambiental é permanentemente reivindicada.
### Passo 3 — Rastreamento de certificado [#passo-3--rastreamento-de-certificado]
Os valores aposentados são registrados nos certificados de respaldo, atualizando seus totais de aposentadoria. Isso mantém a contabilidade precisa em toda a camada de certificados.
### Passo 4 — Minting do recibo [#passo-4--minting-do-recibo]
Um NFT **`CreditRetirementReceipt`** é mintado para o Vault como prova permanente da aposentadoria. Este recibo é a evidência definitiva on-chain de que os créditos foram aposentados.
Créditos aposentados são registrados na blockchain e visíveis por meio do Carrot Registry, fornecendo evidência transparente e auditável de que a compensação ambiental foi reivindicada e não pode ser contada duas vezes.
## Revogação [#revogação]
Ativos podem ser revogados quando os dados subjacentes são considerados incorretos ou fraudulentos. A revogação é um mecanismo de proteção que preserva a credibilidade das reivindicações ambientais da Rede Carrot.
### Revogação de MassID [#revogação-de-massid]
Revogar um MassID **não** aciona revogação em cascata nos seus certificados:
* Certificados vinculados não são revogados automaticamente. Cada certificado precisa ser revogado por conta própria, antes do MassID, para não deixar certificados ativos vinculados a um MassID revogado.
* **Proteção**: Um MassID não pode ser revogado enquanto qualquer certificado ainda vinculado tiver créditos comprados — revogá-lo valida que cada certificado vinculado seria ele próprio revogável. Isso impede a invalidação retroativa de créditos que compradores já adquiriram de boa-fé. Certificados que já foram revogados são desvinculados do MassID pela sua própria revogação, então não o bloqueiam mais.
### Revogação de certificado [#revogação-de-certificado]
Certificados individuais podem ser revogados **independentemente** sem afetar o MassID correspondente ou certificados relacionados. Isso permite correções direcionadas quando apenas reivindicações ambientais específicas precisam ser invalidadas.
* Assim como na revogação de MassID, a revogação de certificado é bloqueada se créditos daquele certificado já tiverem sido vendidos.
### Preservação da trilha de auditoria [#preservação-da-trilha-de-auditoria]
Revogar um ativo o marca como revogado, substitui sua URI de metadados por um registro de revogação e queima o NFT — e, no caso de certificados, o desvincula do seu MassID de origem no CertificateRegistry. A marca de revogado permanece legível on-chain de forma permanente, e o motivo da revogação, junto com a URI de metadados original, permanecem permanentemente legíveis no log de eventos da transação. Auditores e reguladores ainda conseguem reconstruir o histórico completo, mesmo que o token em si não exista mais.
## Próximos passos [#próximos-passos]
* [Categorias de Contratos](/docs/protocol/smart-contracts/contract-categories) — Detalhamento de cada contrato envolvido nesses fluxos.
* [Segurança](/docs/protocol/smart-contracts/security) — Como controle de acesso, pausabilidade e governança protegem essas operações.
* [Comprando Créditos](/docs/protocol/credit-purchase) — A perspectiva do comprador sobre compras de créditos.
* [Aposentando Créditos](/docs/protocol/credit-retirement) — Como e por que créditos são permanentemente aposentados.
# Segurança
## Visão geral [#visão-geral]
A segurança na Rede Carrot opera em dois níveis: **segurança de smart contracts** protegendo ativos on-chain, e **segurança de governança** protegendo a rede contra manipulação e ações hostis.
## Segurança de smart contracts [#segurança-de-smart-contracts]
Os smart contracts da Rede Carrot implementam múltiplas camadas de segurança:
### Controle de Acesso Baseado em Funções (RBAC) [#controle-de-acesso-baseado-em-funções-rbac]
Funções privilegiadas são restritas por papel, e a separação de responsabilidades é validada na inicialização de cada contrato, de modo que os cinco papéis começam em cinco endereços distintos. Essa verificação roda apenas na inicialização: o `DEFAULT_ADMIN_ROLE` pode conceder qualquer papel depois, então mantê-los separados é disciplina de governança, não algo que o contrato reimponha. Pontos de entrada públicos como `purchase` e `retire` são abertos a qualquer chamador, mas só executam contra uma ordem assinada por um signatário autorizado do backend (veja [EIP-712](#assinaturas-de-dados-tipados-eip-712) abaixo). O sistema define cinco funções padrão:
* **`DEFAULT_ADMIN_ROLE`** — Propriedade do contrato e gestão de funções. Esta função pode conceder ou revogar qualquer outra função.
* **`UPGRADER_ROLE`** — Pode atualizar implementações de contratos via proxy UUPS. Separada da função admin para limitar o raio de impacto.
* **`OPERATOR_ROLE`** — Operações cotidianas como minting de MassIDs, emissão de certificados e execução de revogações.
* **`PAUSER_ROLE`** — Mecanismo de pausa padrão para interrupções operacionais ordenadas.
* **`EMERGENCY_PAUSER_ROLE`** — Disjuntor para falhas críticas. Uma pausa emergencial tem expiração de 48 horas, mas ela não se encerra sozinha: passada a expiração, qualquer conta — não apenas um detentor de papel — pode chamar `checkAndUnpause()` para encerrá-la. Uma conta emergencial comprometida pode pausar de novo assim que uma pausa é encerrada, então a contenção é revogar o `EMERGENCY_PAUSER_ROLE`, não esperar a janela passar.
A governança é distribuída entre esses papéis distintos, cada um hoje com detentores separados, de modo que a operação cotidiana exige mais de uma parte. Operações críticas — atualização de contrato e mudança de parâmetro crítico — exigem aprovação multipartes antes de serem executadas.
### Pausabilidade [#pausabilidade]
Os contratos podem ser pausados em modo padrão ou emergencial, interrompendo operações se uma vulnerabilidade ou ataque for detectado. Pausas padrão requerem o `PAUSER_ROLE` e persistem até serem explicitamente despausadas. Pausas emergenciais, acionadas pelo `EMERGENCY_PAUSER_ROLE`, expiram após 48 horas, de modo que um respondente de emergência agindo sozinho não consegue manter uma pausa aberta indefinidamente. Enquanto uma pausa emergencial está ativa, o `PAUSER_ROLE` pode estendê-la para uma pausa indefinida (`extendPause`), que é como um incidente real é mantido aberto além dessa janela.
### Atualizabilidade UUPS [#atualizabilidade-uups]
Os contratos utilizam o Universal Upgradeable Proxy Standard, permitindo correções de bugs e melhorias mantendo os mesmos endereços de contrato e estado. O `ContractRegistry` fornece descoberta centralizada de serviços para que as atualizações se propaguem de forma limpa pelo sistema.
### Assinaturas de dados tipados EIP-712 [#assinaturas-de-dados-tipados-eip-712]
Operações críticas como compras e aposentadorias de créditos requerem dados estruturados assinados criptograficamente antes de serem executadas on-chain. Isso significa que cada ordem deve ser assinada digitalmente por uma parte autorizada — o smart contract verifica essa assinatura antes do processamento, rejeitando qualquer transação que não tenha sido devidamente autorizada. Isso impede que partes não autorizadas executem operações e garante que ordens assinadas não possam ser reproduzidas (usadas mais de uma vez).
Especificamente:
* **CreditPurchaseManager** e **CreditRetirementManager** usam assinaturas de dados tipados EIP-712 para autorizar ordens de compra e aposentadoria.
* **RewardsVault** usa EIP-712 para autorização de retiradas, garantindo que as distribuições de recompensas sejam explicitamente aprovadas.
### Custódia soulbound [#custódia-soulbound]
Todos os NFTs ([MassIDs](/docs/protocol/mass-ids), [certificados](/docs/protocol/certificates), recibos) são soulbound e mantidos pelo smart contract [Vault](/docs/protocol/smart-contracts/contract-categories#custodiantes). Não podem ser transferidos, negociados ou roubados. Este design é intencional pelas seguintes razões:
* **Integridade da proveniência** — A cadeia desde a coleta de resíduos, passando pela certificação até a emissão de créditos, permanece permanente e verificável on-chain.
* **Sem negociação especulativa** — Os registros de auditoria ambiental devem refletir trabalho real de reciclagem, não especulação de mercado.
* **Modelo de segurança simplificado** — Eliminar transferências remove uma classe inteira de vetores de ataque relacionados a interações de marketplace, exploits de aprovação e movimentação não autorizada de tokens.
### Proteção contra reentrância [#proteção-contra-reentrância]
Um ataque de reentrância ocorre quando um contrato malicioso interrompe uma operação no meio da execução — por exemplo, acionando uma retirada repetidamente antes que o saldo seja atualizado, drenando fundos que não deveriam mais estar disponíveis. Todas as operações que movimentam valor na Rede Carrot são protegidas contra esta classe de ataque usando o `ReentrancyGuard` da OpenZeppelin, que garante que cada operação seja concluída completamente antes que qualquer nova chamada possa começar.
## Segurança de governança [#segurança-de-governança]
A [Carrot Foundation](/docs/network/the-foundation) implementa mecanismos sistemáticos de recompensa e punição que escalam o custo do comportamento malicioso mais rápido do que qualquer receita que ele poderia gerar:
* **Rastreamento de reputação de participantes (planejado)** — Um mecanismo futuro para rastrear o comportamento dos participantes em toda a rede, identificando padrões que indicam maus atores, para que operações sensíveis possam ser restringidas por limites de reputação. Não está implementado hoje.
* **Verificação de carteira** — Etapas adicionais de verificação podem ser implementadas conforme necessário para aumentar a segurança, o que pode trocar facilidade de onboarding por proteções mais fortes.
* **Moderação** — A equipe de supervisão da Foundation pode sinalizar comportamentos que violam as diretrizes da comunidade e limitar o acesso para reduzir riscos. Moderadores também trabalham para detectar e penalizar tentativas de manipulação automatizada (anti-botting).
* **Medidas punitivas** — Quando violações são confirmadas, penalidades são emitidas por meio de decisões de governança. A Foundation pode revogar a associação de um participante à plataforma, removendo o acesso ao dashboard e à API; o papel de operador pode revogar um MassID ou certificado já emitido. Não existe congelamento por carteira nem blocklist em nenhum contrato — uma pausa interrompe toda movimentação de saldo do contrato de uma vez, nunca o saldo de um detentor isoladamente.
## Filosofia de design [#filosofia-de-design]
A estratégia de segurança segue um princípio: fazer com que o custo de atacar a rede sempre exceda a recompensa potencial. À medida que o ecossistema cresce e mais participantes constroem reputação genuína, a barreira para manipulação coordenada escala proporcionalmente — protegendo a integridade da rede conforme ela se torna mais valiosa.
[Saiba mais sobre smart contracts](/docs/protocol/smart-contracts) · [Saiba mais sobre governança](/docs/network/governance)
# Referência de Regras BOLD Carbon (CH₄)
## Visão geral [#visão-geral]
Estas são as **regras da aplicação** — a lógica de validação executável que roda contra cada documento [MassID](/docs/protocol/mass-ids). Cada regra avalia um documento e retorna **PASSED**, **FAILED** ou **REVIEW\_REQUIRED** com uma explicação.
Cada regra da aplicação satisfaz uma ou mais [regras do framework](/docs/methodologies/ams-iii-f/bold-carbon) do [framework de metodologia](/docs/standard/concepts/mvf) BOLD Carbon (CH₄). Veja a seção "Implements framework rules" nos detalhes de cada regra para o mapeamento.
O framework BOLD Carbon (CH₄) define um conjunto de regras open-source para verificar que resíduos orgânicos foram devidamente desviados de aterros sanitários e compostados, prevenindo emissões de metano.
O BOLD Carbon (CH₄) compartilha a maioria das regras com o [BOLD Recycling](/docs/methodologies/bold-recycling/framework/application/application-rules) e adiciona regras específicas da metodologia para cálculo de emissões. A validação de limite geográfico é tratada no nível do framework.
As regras são executadas em uma ordem definida sobre documentos MassID. Passar em todas elas é o que dispara a emissão do [certificado GasID](/docs/protocol/certificates#gasid).
Todas as regras são licenciadas sob LGPL-3.0: [github.com/carrot-foundation/methodology-rules](https://github.com/carrot-foundation/methodology-rules)
[Ver no Carrot Registry](https://registry.carrot.eco/document/9498dd79-97ca-4efb-b47d-a8b61cf1f995)
## Regras de MassID [#regras-de-massid]
Estas regras validam documentos [MassID](/docs/protocol/mass-ids) individuais. Elas são executadas na ordem mostrada. As regras 1–19 são compartilhadas com o BOLD Recycling; a regra 20 é exclusiva do Carbon.
Veja a [Política de Distribuição de Recompensas](/docs/standard/policies/rewards-distribution) para o detalhamento completo de percentuais por tipo de ator e categoria de resíduo.
[Saiba mais sobre o BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) · [Saiba mais sobre as regras do BOLD Recycling](/docs/methodologies/bold-recycling/framework/application/application-rules)
# BOLD Carbon — Referência de Eventos do MassID
## Como ler esta página [#como-ler-esta-página]
Cada evento abaixo mostra o payload JSON canônico que os [integradores](/docs/protocol/network-integrators) enviam à Documents API.
Os flags `isPublic` em cada exemplo representam a visibilidade recomendada pela Carrot — veja
[Privacidade e Mascaramento](/docs/integrations/guides/privacy-and-masking) para o modelo.
Cada payload referencia seu participante e endereço por `participantId` e `addressId`. Resolva cada um
primeiro — busque por chave ou crie — pela [API de Participantes](/docs/integrations/api/participants);
enviar objetos `participant` e `address` completos inline também é suportado e faz find-or-create do registro.
Envie exatamente uma das formas de cada par — as duas, ou nenhuma, falha com `400 VALIDATION_ERROR`. A regra é a mesma nos endpoints de evento individual e de lote.
> Dicionários de atributos por evento (definições, tipos, flags de sensibilidade, regras condicionais)
> são a próxima adição planejada para esta página.
## Criar documento MassID [#criar-documento-massid]
A chamada inicial `POST /documents` que cria um MassID. Não é um evento na linha do tempo
do documento — incluída aqui como ponto de partida dos fluxos de integração. O
[Waste Generator](/docs/protocol/supply-chain) é o criador; eventos são adicionados a
este documento em seguida.
## ACTOR — Waste Generator [#actor--waste-generator]
## ACTOR — Recycler [#actor--recycler]
## ACTOR — Processor [#actor--processor]
## ACTOR — Hauler [#actor--hauler]
## ACTOR — Integrator [#actor--integrator]
## Pick-up [#pick-up]
## Transport Manifest [#transport-manifest]
## Weighing [#weighing]
## Drop-off [#drop-off]
## Sorting [#sorting]
## Recycled [#recycled]
## Recycling Manifest [#recycling-manifest]
# Visão Geral da Aplicação BOLD Carbon (CH₄) v1.0.0
## Resumo da aplicação [#resumo-da-aplicação]
| Propriedade | Valor |
| --------------- | -------------------------------------------------------------------------------------------------------- |
| **Metodologia** | [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) |
| **Versão** | 1.0.0 |
| **Licença** | LGPL-3.0 |
| **Repositório** | [github.com/carrot-foundation/methodology-rules](https://github.com/carrot-foundation/methodology-rules) |
## Arquitetura [#arquitetura]
A [MvA](/docs/standard/concepts/mva) do BOLD Carbon (CH₄) é implementada no monorepo open-source methodology-rules. Ela segue a arquitetura de duas camadas compartilhada por todas as metodologias BOLD:
* **Bibliotecas de regras compartilhadas** — Lógica de verificação comum reutilizada em todas as metodologias BOLD. Localizada no diretório de processadores de regras compartilhados.
* **Wrappers da aplicação BOLD Carbon (CH₄)** — Camadas de deploy que encapsulam as bibliotecas compartilhadas como funções serverless, localizadas no diretório da aplicação BOLD Carbon (CH₄). Isso inclui regras exclusivas do Carbon (`prevented-emissions`, `project-boundary`) que não existem na camada compartilhada.
Cada regra é uma função serverless independente que avalia documentos [MassID](/docs/protocol/mass-ids) e retorna PASSED, FAILED ou REVIEW\_REQUIRED com uma explicação.
Para o catálogo completo de regras com ordem de execução, veja [Regras da Aplicação v1.0.0](/docs/methodologies/ams-iii-f/bold-carbon/application/application-rules).
## Código-fonte [#código-fonte]
O repositório é organizado da seguinte forma:
* **Bibliotecas de regras compartilhadas** — [libs/methodologies/bold/rule-processors/](https://github.com/carrot-foundation/methodology-rules/tree/main/libs/methodologies/bold/rule-processors/) contém as implementações de regras compartilhadas usadas por todas as metodologias BOLD.
* **Deploys do BOLD Carbon (CH₄)** — [apps/methodologies/bold-carbon/rule-processors/](https://github.com/carrot-foundation/methodology-rules/tree/main/apps/methodologies/bold-carbon/rule-processors/) contém os wrappers de deploy para esta metodologia, incluindo as regras exclusivas do Carbon.
Consulte o README do repositório para orientações de navegação e instruções de contribuição.
[Saiba mais sobre o BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) · [Saiba mais sobre o framework](/docs/methodologies/ams-iii-f/bold-carbon) · [Ver catálogo de regras](/docs/methodologies/ams-iii-f/bold-carbon/application/application-rules) · [Guia de integração](/docs/methodologies/ams-iii-f/bold-carbon/application/integration)
# Guia de Integração BOLD Carbon (CH₄)
Este guia explica como enviar documentos [MassID](/docs/protocol/mass-ids) que satisfazem as regras do
[BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon). O BOLD Carbon compartilha a maioria das regras com o
[BOLD Recycling](/docs/methodologies/bold-recycling) e adiciona uma regra exclusiva do Carbon para
cálculo de emissões. A validação de limite geográfico é tratada no nível do framework.
Para o fluxo base da API, veja [Enviando um MassID](/docs/integrations/guides/submitting-a-mass-id). Para o
catálogo completo de regras, veja [Regras do BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon/application/application-rules).
## Pré-requisitos [#pré-requisitos]
* Ter completado o fluxo de [Quick Start](/docs/integrations/getting-started/quick-start).
* Familiaridade com os [Conceitos Básicos](/docs/integrations/getting-started/core-concepts) (modelo de documento, ordenação de eventos, idempotência).
* Documento de [homologação](/docs/protocol/network-integrators) registrado para o [Integrador](/docs/protocol/network-integrators), o [Processador](/docs/protocol/supply-chain) e o [Reciclador](/docs/protocol/supply-chain#o-papel-do-reciclador) — a validade do Processador e do Reciclador é verificada quando a metodologia roda. A regra 4 verifica apenas esses três: um [Transportador](/docs/protocol/supply-chain) não precisa de homologação, e a do [Gerador de Resíduos](/docs/protocol/supply-chain) não é exigida por essa regra.
* A homologação do Reciclador inclui o **coeficiente de emissão excedente** necessário para o cálculo de emissões.
## Regras compartilhadas com o BOLD Recycling [#regras-compartilhadas-com-o-bold-recycling]
As regras 1–19 do BOLD Carbon são idênticas às do BOLD Recycling. A criação de documentos, sequência de eventos e
requisitos de campos para essas regras são os mesmos. Veja o
[Guia de Integração do BOLD Recycling](/docs/methodologies/bold-recycling/framework/application/integration)
para o detalhamento completo evento a evento cobrindo:
* Criação de documento (categoria, tipo, subtipo, unidade de medida)
* Eventos ACTOR para todos os participantes
* Eventos Pick-up, Transport Manifest, Weighing, Drop-off, Sorting, Recycled e Recycling Manifest
* Validações de geolocalização, unicidade, período de tratamento biológico e códigos Ibama (veja [Códigos de resíduos suportados](/docs/methodologies/ams-iii-f/bold-carbon#códigos-de-resíduos-suportados) para valores aceitos)
Tudo naquele guia se aplica aqui. Esta página cobre apenas a **adição exclusiva do Carbon**.
## Mapeamento de eventos e regras [#mapeamento-de-eventos-e-regras]
## Regras exclusivas do Carbon [#regras-exclusivas-do-carbon]
### Regra 20 — Reduções de Emissões [#regra-20--reduções-de-emissões]
Calcula as reduções de emissões de CO₂ equivalente com base na metodologia UNFCCC AMS-III.F. O cálculo
utiliza:
| Entrada | Fonte |
| ---------------------------------- | ----------------------------------------------- |
| Coeficiente de emissão excedente | Documento de homologação do Reciclador. |
| Baselines por subtipo de resíduo | Documento de homologação do Reciclador. |
| Tipo de Gás de Efeito Estufa (GHG) | Atributo de metadado do MassID. |
| Subtipo de resíduo | Campo `subtype` do documento MassID. |
| Valor do MassID | Campo `value` do documento MassID (peso em kg). |
**O que sua integração deve garantir:**
* O documento de homologação do reciclador inclui um coeficiente de emissão excedente válido e baselines para cada subtipo de resíduo.
* O subtipo e o valor do documento MassID estão corretamente definidos.
* O atributo de metadado GHG está presente e válido.
A regra retorna as reduções de emissões calculadas em CO₂e.
A regra `methodology-distance-limit` no nível do framework valida a distância entre os locais de
Pick-up e Drop-off. Distâncias superiores a 200 km são sinalizadas para revisão. Esta é uma
verificação do framework, não uma regra da aplicação — não afeta a contagem de regras.
## Pós-validação [#pós-validação]
Quando todas as 20 regras passam:
1. Emite um [certificado GasID](/docs/protocol/certificates#gasid) vinculado ao MassID (em vez de um RecycledID).
2. Emite os tokens de crédito [C-CARB.CH4](/docs/protocol/credits#tokenized-carbon-credits-tcc) (Tokenized Carbon Credits ([TCC](/docs/protocol/credits#tokenized-carbon-credits-tcc))) na mesma transação do certificado.
3. As [recompensas](/docs/protocol/rewards-distribution) dos participantes da [cadeia de suprimentos](/docs/protocol/supply-chain) são calculadas e registradas on-chain depois, quando um crédito daquele certificado é vendido.
## Diferenças em relação ao BOLD Recycling [#diferenças-em-relação-ao-bold-recycling]
| Aspecto | BOLD Recycling | BOLD Carbon (CH₄) |
| -------------------- | ------------------------------------------------------------- | ------------------------------------------------------------- |
| Quantidade de regras | 19 regras de MassID | 20 regras de MassID (19 compartilhadas + 1 exclusiva) |
| Tipo de certificado | [RecycledID](/docs/protocol/certificates#recycledid) | [GasID](/docs/protocol/certificates#gasid) |
| Token de crédito | `C-BIOW` (TRC) | `C-CARB.CH4` (TCC) |
| Cálculo de emissões | Não aplicável | Reduções de CO₂e via UNFCCC AMS-III.F (regra 20) |
| Limite geográfico | Distância Pick-up → Drop-off sinalizada no nível do framework | Mesma verificação no nível do framework (limite de 200 km) |
| Dados de homologação | Campos padrão de homologação | Deve incluir coeficiente de emissão excedente para reciclador |
## Problemas comuns [#problemas-comuns]
Todos os [problemas comuns do BOLD Recycling](/docs/methodologies/bold-recycling/framework/application/integration#problemas-comuns) se aplicam, além de:
* **Coeficiente de emissão ausente** — A homologação do reciclador deve incluir o coeficiente de emissão excedente. Sem ele, a regra 20 não consegue calcular as reduções de emissões.
* **Sinalização de distância** — Os endereços de Pick-up e Drop-off devem ser geograficamente razoáveis. Distâncias superiores a 200 km são sinalizadas para revisão. Garanta que as coordenadas GPS estejam precisas em ambos os eventos.
* **Baselines ausentes** — A homologação do reciclador deve incluir baselines para cada subtipo de resíduo utilizado no cálculo de emissões.
[Ver catálogo de regras](/docs/methodologies/ams-iii-f/bold-carbon/application/application-rules) · [Ver referência da aplicação](/docs/methodologies/ams-iii-f/bold-carbon/application) · [Guia de integração do BOLD Recycling](/docs/methodologies/bold-recycling/framework/application/integration)
# Referência de Regras BOLD Recycling Credit
## Visão geral [#visão-geral]
Estas são as **regras da aplicação** — a lógica de validação executável que é aplicada a cada documento [MassID](/docs/protocol/mass-ids). Cada regra avalia um documento e retorna **PASSED**, **FAILED** ou **REVIEW\_REQUIRED** com uma explicação.
Cada regra da aplicação satisfaz uma ou mais [regras do framework](/docs/methodologies/bold-recycling/framework) da especificação do [BOLD Recycling](/docs/methodologies/bold-recycling). Consulte a seção "Implementa regras do framework" nos detalhes de cada regra para o mapeamento.
O framework BOLD Recycling define um conjunto de regras open-source para verificar que resíduos orgânicos foram devidamente triados, coletados, transportados e compostados.
As regras são executadas em uma ordem definida sobre documentos MassID. Passar em todas elas é o que dispara a emissão do [certificado RecycledID](/docs/protocol/certificates#recycledid).
Todas as regras são licenciadas sob LGPL-3.0: [github.com/carrot-foundation/methodology-rules](https://github.com/carrot-foundation/methodology-rules)
[Ver no Carrot Registry](https://registry.carrot.eco/document/31f1ff32-fdc5-469a-9d30-caf0be89b50a)
## Regras de MassID [#regras-de-massid]
Estas regras validam documentos [MassID](/docs/protocol/mass-ids) individuais. Elas são executadas na ordem apresentada.
Consulte a [Política de Distribuição de Recompensas](/docs/standard/policies/rewards-distribution) para o detalhamento completo de porcentagens por tipo de ator e categoria de resíduo.
[Saiba mais sobre o BOLD Recycling](/docs/methodologies/bold-recycling) · [Conheça as regras do BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon/application/application-rules)
# BOLD Recycling — Referência de Eventos do MassID
## Como ler esta página [#como-ler-esta-página]
Cada evento abaixo mostra o payload JSON canônico que os [integradores](/docs/protocol/network-integrators) enviam à Documents API.
Os flags `isPublic` em cada exemplo representam a visibilidade recomendada pela Carrot — veja
[Privacidade e Mascaramento](/docs/integrations/guides/privacy-and-masking) para o modelo.
Cada payload referencia seu participante e endereço por `participantId` e `addressId`. Resolva cada um
primeiro — busque por chave ou crie — pela [API de Participantes](/docs/integrations/api/participants);
enviar objetos `participant` e `address` completos inline também é suportado e faz find-or-create do registro.
Envie exatamente uma das formas de cada par — as duas, ou nenhuma, falha com `400 VALIDATION_ERROR`. A regra é a mesma nos endpoints de evento individual e de lote.
> Dicionários de atributos por evento (definições, tipos, flags de sensibilidade, regras condicionais)
> são a próxima adição planejada para esta página.
## Criar documento MassID [#criar-documento-massid]
A chamada inicial `POST /documents` que cria um MassID. Não é um evento na linha do tempo
do documento — incluída aqui como ponto de partida dos fluxos de integração. O
[Waste Generator](/docs/protocol/supply-chain) é o criador; eventos são adicionados a
este documento em seguida.
## ACTOR — Waste Generator [#actor--waste-generator]
## ACTOR — Recycler [#actor--recycler]
## ACTOR — Processor [#actor--processor]
## ACTOR — Hauler [#actor--hauler]
## ACTOR — Integrator [#actor--integrator]
## Pick-up [#pick-up]
## Transport Manifest [#transport-manifest]
## Weighing [#weighing]
## Drop-off [#drop-off]
## Sorting [#sorting]
## Recycled [#recycled]
## Recycling Manifest [#recycling-manifest]
# Visão Geral da Aplicação BOLD Recycling Credit v1.0.0
## Resumo da aplicação [#resumo-da-aplicação]
| Propriedade | Valor |
| --------------- | -------------------------------------------------------------------------------------------------------- |
| **Metodologia** | [BOLD Recycling](/docs/methodologies/bold-recycling) |
| **Versão** | 1.0.0 |
| **Licença** | LGPL-3.0 |
| **Repositório** | [github.com/carrot-foundation/methodology-rules](https://github.com/carrot-foundation/methodology-rules) |
## Arquitetura [#arquitetura]
A [MvA](/docs/standard/concepts/mva) do [BOLD Recycling](/docs/methodologies/bold-recycling) é implementada no monorepo open-source methodology-rules. Ela segue a arquitetura de duas camadas compartilhada por todas as metodologias BOLD:
* **Bibliotecas de regras compartilhadas** — Lógica de verificação comum reutilizada em todas as metodologias BOLD. Localizada no diretório de processadores de regras compartilhados.
* **Wrappers da aplicação BOLD Recycling** — Camadas de deployment que encapsulam as bibliotecas compartilhadas como funções serverless, localizadas no diretório da aplicação BOLD Recycling.
Cada regra é uma função serverless independente que avalia documentos [MassID](/docs/protocol/mass-ids) e retorna PASSED, FAILED ou REVIEW\_REQUIRED com uma explicação.
Para o catálogo completo de regras com ordem de execução, consulte [Regras da Aplicação v1.0.0](/docs/methodologies/bold-recycling/framework/application/application-rules).
## Código-fonte [#código-fonte]
O repositório está organizado da seguinte forma:
* **Bibliotecas de regras compartilhadas** — [libs/methodologies/bold/rule-processors/](https://github.com/carrot-foundation/methodology-rules/tree/main/libs/methodologies/bold/rule-processors/) contém as implementações de regras compartilhadas usadas por todas as metodologias BOLD.
* **Deployments do BOLD Recycling** — [apps/methodologies/bold-recycling/rule-processors/](https://github.com/carrot-foundation/methodology-rules/tree/main/apps/methodologies/bold-recycling/rule-processors/) contém os wrappers de deployment para esta metodologia.
Consulte o README do repositório para orientações de navegação e instruções de contribuição.
[Saiba mais sobre o BOLD Recycling](/docs/methodologies/bold-recycling) · [Saiba mais sobre o framework](/docs/methodologies/bold-recycling/framework) · [Catálogo de regras](/docs/methodologies/bold-recycling/framework/application/application-rules) · [Guia de integração](/docs/methodologies/bold-recycling/framework/application/integration)
# Guia de Integração BOLD Recycling Credit
Este guia explica como submeter documentos [MassID](/docs/protocol/mass-ids) que atendem às regras do
[BOLD Recycling](/docs/methodologies/bold-recycling). Ele cobre a sequência de eventos esperada,
campos obrigatórios por evento e problemas comuns de validação.
Para o fluxo base da API, consulte [Submetendo um MassID](/docs/integrations/guides/submitting-a-mass-id). Para o
catálogo completo de regras, consulte [Regras do BOLD Recycling](/docs/methodologies/bold-recycling/framework/application/application-rules).
## Pré-requisitos [#pré-requisitos]
* Concluiu o fluxo do [Quick Start](/docs/integrations/getting-started/quick-start).
* Familiaridade com [Conceitos Fundamentais](/docs/integrations/getting-started/core-concepts) (modelo de documentos, ordenação de eventos, idempotência).
* Documento de [homologação](/docs/protocol/network-integrators) registrado para o [Integrador](/docs/protocol/network-integrators), o [Processador](/docs/protocol/supply-chain) e o [Reciclador](/docs/protocol/supply-chain#o-papel-do-reciclador) — a validade do Processador e do Reciclador é verificada quando a metodologia roda. A regra 4 verifica apenas esses três — um [Transportador](/docs/protocol/supply-chain) não precisa de homologação, e a do [Gerador de Resíduos](/docs/protocol/supply-chain) não é exigida por essa regra.
## Criação do documento [#criação-do-documento]
Crie o documento com as qualificações obrigatórias (validadas pela regra 5 — MassID Qualifications):
| Campo | Valor obrigatório |
| ------------- | ---------------------------------------- |
| `category` | `MassID` |
| `type` | `Organic` |
| `measureUnit` | `kg` |
| `value` | Maior que 0 |
| `subtype` | Um subtipo válido de resíduo orgânico |
| `isPublic` | Conforme seus requisitos de visibilidade |
Referência: [API de Documentos](/docs/integrations/api/documents).
## Sequência esperada de eventos [#sequência-esperada-de-eventos]
Submeta eventos em ordem cronológica via `POST /documents/{documentId}/events`. Consulte
[Especificação de Eventos](/docs/integrations/reference/event-specification) para campos comuns de eventos.
A sequência a seguir reflete a ordem validada pelas regras do BOLD Recycling:
### Papéis obrigatórios dos participantes [#papéis-obrigatórios-dos-participantes]
| Papel | Label ACTOR | Função |
| ------------------- | ----------------- | ------------------------------------------------------------------ |
| Gerador de Resíduos | `Waste Generator` | Origem do material residual |
| Transportador | `Hauler` | Transporta resíduos da origem até a instalação |
| Reciclador | `Recycler` | Opera a instalação de reciclagem ou compostagem |
| Processador | `Processor` | Processa material triado (pode ser a mesma entidade do reciclador) |
### 1. Eventos ACTOR — registro de participantes [#1-eventos-actor--registro-de-participantes]
Registre cada participante com um evento `ACTOR`. A regra 4 — Participant Accreditations & Verifications
— verifica documentos de homologação apenas para o Integrador, o Processador e o Reciclador, e a
homologação do Processador e do Reciclador precisa estar válida na data da avaliação. Registrar um
Transportador ou um Gerador de Resíduos não exige documento de homologação.
| Participante | Obrigatório? | Condições |
| ------------------- | ------------ | -------------------------------------------------------------------------------------------------------- |
| Integrador | Sim | Deve ter um documento de homologação. |
| Gerador de Resíduos | Condicional | Obrigatório se a origem do resíduo é identificada (regra 8). Omitir se não identificada. |
| Transportador | Condicional | Obrigatório para a maioria dos tipos de veículos (regra 9). Opcional para carrinho ou tubulação de lodo. |
| Processador | Sim | Exatamente um processador obrigatório (regra 13). |
| Reciclador | Sim | Exatamente um reciclador obrigatório (regra 14). |
Todo evento ACTOR carrega os identificadores de participante e de endereço. Ele não carrega dados de homologação: a homologação não é enviada pela API — ela vive na camada de homologação, e o pipeline de verificação a lê de lá. A regra 7 — Geolocation Precision — compara o endereço de um evento com o endereço homologado dos participantes que têm homologação registrada.
O formato do payload é idêntico entre atores — apenas o identificador do papel muda.
### 2. Pick-up — coleta de resíduos [#2-pick-up--coleta-de-resíduos]
O evento Pick-up captura informações do veículo e motorista:
| Campo | Obrigatório? | Validado por |
| -------------------------- | ------------ | --------------------------------------------------- |
| Tipo de veículo | Sim | Regra 10 — Vehicle Identification |
| Placa / identificação | Condicional | Por tipo de veículo (regra 10) |
| Identificação do motorista | Condicional | Por tipo de veículo (regra 11) |
| Justificativa de isenção | Condicional | Quando ID do motorista não é obrigatório (regra 11) |
### 3. Transport Manifest — documentação de transporte [#3-transport-manifest--documentação-de-transporte]
Deve incluir (regra 12 — Transport Manifest):
| Campo | Obrigatório? | Observações |
| ------------------- | ------------ | ------------------------------------------------------------------------ |
| Número do documento | Sim | |
| Tipo do documento | Sim | Deve ser `MTR` para recicladores no Brasil. |
| Data de emissão | Sim | |
| Anexos | Sim | Upload via [Upload de Arquivos](/docs/integrations/guides/file-uploads). |
### 4. Weighing — medição de massa [#4-weighing--medição-de-massa]
Registre medições de peso (regra 15 — Weighing):
| Campo | Obrigatório? | Observações |
| ----------------------- | ------------ | ----------------------------------------------------------------------------- |
| Valor do evento | Sim | Peso líquido em kg, deve ser maior que 0. |
| Descrição | Sim | Descrição do evento de pesagem. |
| Peso bruto | Sim | Deve ser maior que 0, em kg. |
| Tara | Sim | Peso do container vazio em kg (isenções podem ser aplicadas por homologação). |
| Tipo de container | Sim | Um de: Bag, Bin, Drum, Pail, Street Bin, Waste Box ou Truck. |
| Quantidade de container | Condicional | Obrigatório quando o tipo de container não é Truck. |
| Capacidade do container | Condicional | Obrigatório para pesagem com múltiplos containers. |
| Método de captura | Sim | Um de: Digital, Photo (Scale+Cargo), Manual ou Transport Manifest. |
| Tipo de balança | Sim | Deve corresponder a um tipo de balança aprovado. |
| Ticket de pesagem | Condicional | Quando exigido pela homologação do reciclador. |
| Placa do veículo | Condicional | Obrigatório quando o tipo de container é Truck. |
Suporta processos de pesagem em uma ou duas etapas.
### 5. Drop-off — entrega na instalação de reciclagem [#5-drop-off--entrega-na-instalação-de-reciclagem]
Deve incluir (regra 16 — Drop-off At Recycling Facility):
| Campo | Obrigatório? | Observações |
| -------------------- | ------------ | ------------------------------------------------------- |
| Operador de recepção | Sim | Identificação do operador na instalação. |
| Endereço | Sim | Deve corresponder ao endereço homologado do reciclador. |
### 6. Sorting — triagem de massa [#6-sorting--triagem-de-massa]
Deve incluir (regra 17 — Mass Sorting):
| Campo | Obrigatório? | Observações |
| ---------------- | ------------ | -------------------------------------------------------------- |
| Descrição | Sim | Descrição do evento de triagem. |
| Peso bruto | Sim | Peso total antes das deduções. |
| Peso deduzido | Sim | Peso de contaminantes/material não-alvo. |
| Fator de triagem | Sim | Calculado a partir do peso bruto e deduzido. |
| Valor do evento | Sim | Deve ser corretamente calculado a partir dos dados de triagem. |
### 7. Recycled — conclusão do tratamento biológico [#7-recycled--conclusão-do-tratamento-biológico]
O evento Recycled marca o fim do ciclo de tratamento biológico. O timestamp é validado contra o evento Drop-off
(regra 18 — Composting Cycle Timeframe):
* O tempo entre Drop-off e Recycled deve ser de **60–180 dias**.
### 8. Recycling Manifest — documentação de reciclagem [#8-recycling-manifest--documentação-de-reciclagem]
Deve incluir (regra 19 — Recycling Manifest):
| Campo | Obrigatório? | Observações |
| ------------------------ | ------------ | ----------------------------------------------------------- |
| Número do documento | Sim | |
| Tipo do documento | Sim | Deve ser `CDF` para recicladores no Brasil. |
| Data de emissão | Sim | |
| Anexos | Condicional | Obrigatório a menos que justificativa de isenção fornecida. |
| Justificativa de isenção | Condicional | Quando anexos não estão disponíveis. |
## Mapeamento de eventos e regras [#mapeamento-de-eventos-e-regras]
## Validações adicionais [#validações-adicionais]
| Regra | O que verifica |
| ----- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1 | Não existe MassID duplicado com a mesma combinação de drop-off + pick-up + reciclador + gerador de resíduos + placa. |
| 2 | MassID não está vinculado a um [RecycledID](/docs/protocol/certificates#recycledid) ou ordem de crédito. |
| 3 | O evento Recycled ocorreu em ou após 1 de janeiro do ano anterior. |
| 6 | A classificação local de resíduos corresponde a um código Ibama válido (recicladores no Brasil). |
| 7 | Endereços de eventos dos participantes são validados contra endereços homologados usando limiares de distância escalonados (≤2 km: verificação GPS, 2–30 km: revisão de similaridade de endereço, >30 km: falha). |
## Pós-validação [#pós-validação]
Quando todas as 19 regras passam, a plataforma:
1. Emite um [certificado RecycledID](/docs/protocol/certificates#recycledid) vinculado ao MassID.
2. Emite os tokens de crédito [C-BIOW](/docs/protocol/credits#tokenized-recycling-credits-trc) (Tokenized Recycling Credits) na mesma transação do certificado.
3. As [recompensas](/docs/protocol/rewards-distribution) dos participantes da [cadeia de suprimentos](/docs/protocol/supply-chain) são calculadas e registradas on-chain depois, quando um crédito daquele certificado é vendido.
## Problemas comuns [#problemas-comuns]
* **Incompatibilidade de geolocalização** — Endereços de eventos dos participantes são validados contra endereços homologados usando limiares de distância escalonados. Verifique a precisão do GPS.
* **Prazo do tratamento biológico** — A janela entre Drop-off e Recycled deve ser de 60–180 dias. Documentos fora desse intervalo falham na regra 18.
* **Homologações ausentes** — O Integrador, o Processador e o Reciclador devem ter documento de homologação registrado, e a do Processador e do Reciclador precisa estar válida e não expirada no momento em que a metodologia roda, não no momento em que o evento foi submetido. A regra 4 não verifica a homologação do Transportador nem do Gerador de Resíduos.
* **MassIDs duplicados** — A verificação de unicidade (regra 1) impede submissões duplicadas. Use `deduplicationId` para retentativas, não reenvios.
* **Códigos Ibama** — Para recicladores no Brasil, a classificação local de resíduos deve corresponder a um código Ibama válido. Valide antes da submissão.
[Catálogo de regras](/docs/methodologies/bold-recycling/framework/application/application-rules) · [Referência da aplicação](/docs/methodologies/bold-recycling/framework/application) · [Fluxo base de integração](/docs/integrations/guides/submitting-a-mass-id)