# 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 a governance layer for Carrot's environmental protocols, using smart contracts for transparent and traceable decision-making as well as sharing of network proceeds. It encompasses a [standard](/docs/standard), a public credit [registry](/docs/registry), and digital Measurement, Reporting and Verification (digital MRV) infrastructure for independent, third-party verification. Learn more in the [overview](/docs/network).
### 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 revenue is 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 TRCs and TCCs? [#what-are-trcs-and-tccs]
[Tokenized Recycling Credits (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc) represent 1 metric ton of certified recycled material. [Tokenized Carbon Credits (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc) represent 1 metric ton of CO₂-equivalent emission reductions through waste diversion. Both are fungible ERC-20 tokens backed by verified [certificates](/docs/protocol/certificates).
### How are credits purchased? [#how-are-credits-purchased]
Credits are purchased only through Carrot interfaces — buyers do not purchase directly on-chain. Individuals can buy environmental impact through the [Carrot Store](https://store.carrot.eco) (store.carrot.eco), which offers intention-based products that result in retired credits. Organizations use Carrot-provided interfaces that accept multiple payment methods (e.g. Pix, credit/debit card, USDC); the platform executes the on-chain transaction and credits are delivered to the buyer's wallet. Purchased credits can be [retired](/docs/protocol/credit-retirement) as permanent, on-chain proof of environmental action, viewable on the public blockchain (e.g. via any blockchain block explorer) or the [Carrot Explorer](/docs/protocol/explorer) (explore.carrot.eco). 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]
No. You can purchase any quantity directly on the [Carrot Store](https://store.carrot.eco). For enterprise volume agreements or annual minimum commitments (AMC), contact the Carrot sales team.
### How much does a credit cost? [#how-much-does-a-credit-cost]
A [Tokenized Carbon Credit (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc) is priced at US$ 50.00 per metric ton of CO₂ equivalent.
A [Tokenized Recycling Credit (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc) has a base price of US$ 103.53 per metric ton — composed of the carbon emission reductions value plus the social and environmental co-benefits of verified recycling. For volume purchases, co-benefits can be negotiated with the Carrot sales team.
### What payment methods are accepted? [#what-payment-methods-are-accepted]
Pix, credit/debit card, and USDC.
### Do I need a crypto wallet to buy credits? [#do-i-need-a-crypto-wallet-to-buy-credits]
No. [MyCarrot](/docs/for-buyers/how-to-buy#manage-your-impact-with-mycarrot) is a portal with an intuitive interface that requires no blockchain knowledge. Through MyCarrot you can view your impact dashboard, purchase history with certificate details, and audit trails — all in one place at [my.carrot.eco](https://my.carrot.eco).
### 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 an on-chain certificate with a complete audit trail, compatible with GHG Protocol, CDP, GRI 305, and ISO 14064-3. See [Impact Evidence](/docs/for-buyers/impact-evidence) 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.
## 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).
**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 (B) 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).
**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 Explorer, 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. A family of methodologies on the Carrot Network for verifying organic waste diversion. Carrot provides the infrastructure; methodology frameworks and applications are developed by third parties. See [BOLD Recycling](/docs/methodologies/bold-recycling) and [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon).
## C [#c]
**C-BIOW** — The ERC-20 token symbol for [Tokenized Recycling Credits (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc) issued by the [BOLD Recycling](/docs/methodologies/bold-recycling) methodology. 1 token = 1 metric ton of certified recycled bio waste. Other recycling methodologies may issue TRCs with different symbols.
**C-CARB.CH4** — The ERC-20 token symbol for [Tokenized Carbon Credits (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 token = 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. An ML-based layer that continuously monitors dMRV data, detecting anomalies and suspicious patterns in supply chain and methodology data. See [Methodology Ecosystem](/docs/standard/concepts/ecosystem#platform-intelligence-layers).
**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 Explorer** — The [public interface](/docs/protocol/explorer) of Carrot's verification platform at [explore.carrot.eco](https://explore.carrot.eco). Provides a transparent, user-friendly view of environmental data and audit trails — both on-chain data (MassIDs, certificates, credits, retirement records) and platform data (methodology definitions, rule execution, accreditations). On-chain 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 Explorer" refers specifically to the UI.
**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** — A governance layer for Carrot's environmental protocols, using smart contracts for transparent and traceable decision-making as well as sharing of network proceeds. Encompasses a [standard](/docs/standard), a public credit [registry](/docs/registry), and [dMRV](/docs/protocol/dmrv) infrastructure for [third-party verification](/docs/protocol/third-party-verification).
**Carrot Store** — A consumer experience at [store.carrot.eco](https://store.carrot.eco) for purchasing environmental impact. Offers intention-based products (e.g. For me, For my family) 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 [For Buyers](/docs/for-buyers).
**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 soulbound NFT representing a single MassID that has passed methodology verification. Two types: [GasID](/docs/protocol/certificates#gasid) (emission reductions) and [RecycledID](/docs/protocol/certificates#recycledid) (material recycled).
**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.
**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 Impact Pool** — A collective fund (CP) for socio-environmental projects in the territory where recycling took place. Receives discounted reward amounts from scenarios such as incomplete onboarding or Large Business classification. Over time, the Pool will evolve toward progressive community participation in its governance. 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 ERC-20 token 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 on-chain 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 [For Buyers](/docs/for-buyers).
**Credit retirement** — The permanent removal of credit tokens from circulation. When a buyer retires credits, the tokens are burned and a `CreditRetirementReceipt` NFT is minted as immutable 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.
**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.
## 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` credit tokens at minting; 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).
## K [#k]
**KYC** — Know Your Customer/Client. The mandatory process of verifying participant identity before network participation.
## M [#m]
**MassID** — A unique digital asset (soulbound NFT) 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 on-chain.
**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).
**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 Explorer](/docs/protocol/explorer). Requires no blockchain knowledge. See [Purchasing Credits](/docs/protocol/credit-purchase).
## N [#n]
**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).
**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 [credit](/docs/protocol/credits) sale revenue for their role in the recycling process. Revenue from credit purchases is [distributed](/docs/protocol/rewards-distribution) based on each participant's role and the weight of waste they handled.
**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)** — Carrot issues, tracks, and retires environmental credits on a public blockchain ledger. The blockchain 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 asset minting, reward distribution, credit purchases, and credit retirement. See [Smart Contracts](/docs/protocol/smart-contracts).
**Soulbound** — A property of NFTs meaning they cannot be transferred between wallets. All Carrot Network NFTs are soulbound, ensuring the audit trail is 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 Waste`, `Garden 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 on-chain 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 Explorer](/docs/protocol/explorer).
**Tracking ID** — The unique public identifier assigned to each [document](#document) in the Carrot platform, used to look up the record in the [Carrot Explorer](/docs/protocol/explorer).
**TRC (`C-BIOW`)** — Tokenized Recycling Credit. A fungible credit representing 1 metric ton of certified recycled material. The on-chain 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 stablecoin pegged 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 cryptocurrency 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 soulbound NFTs (MassIDs, certificates, receipts) and credit token 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 present, all participants receive full [rewards](/docs/protocol/rewards-distribution); when absent, discounted payouts apply. See [supply chain](/docs/protocol/supply-chain).
## 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 tokens on a public blockchain. Each credit carries an immutable record that links the physical event that originated it — a verified mass of material collected, sorted, or processed — through the verification and issuance steps to its eventual retirement.
This record is permanent and publicly accessible. Anyone can trace a credit's full history independently, without relying on Carrot or any other intermediary to provide the data.
## 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:
* **Tokenization** — RecycledID and GasID certificates back fungible credit tokens such as TRCs and TCCs.
* **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 burns the claimed credit amount and creates a permanent receipt for the environmental claim.
* **Wallet and custody flows** — Wallets interact with credit balances, receipts, and settlement flows while soulbound 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 blockchain? [#why-blockchain]
Three properties of blockchain infrastructure 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) distribute credit sale proceeds automatically to [supply chain](/docs/protocol/supply-chain) participants based on their verified contributions. This removes manual intermediation from revenue distribution.
## 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 [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 minting 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
* [On-Chain Minting](/docs/protocol/on-chain-minting) — how physical verification becomes an on-chain credit
* [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
# Contact Us
We are ready to support your process — from the initial assessment to complete onboarding.
## Where to start [#where-to-start]
**I want to better understand credits and the process**
Schedule a conversation with our business team. We can present how credits fit into your sustainability program and answer specific technical questions.
**I am ready to move forward commercially**
Get in touch directly to discuss volume, terms, and next steps for an enterprise or AMC agreement.
**I want to evaluate the technical integration**
Our technical team can provide sandbox access, API documentation, and support for integration evaluation with your internal systems.
**I want to become an intermediary partner**
Talk to our partnerships team about the distribution model and commercial structure.
> [contact@carrot.eco](mailto:contact@carrot.eco)
> [carrot.eco/en/contact](https://carrot.eco/en/contact)
For access to due diligence materials — sample audit trails, methodology documentation, white paper — request directly from our team.
# How to Buy
From single purchases to enterprise volume agreements — the process adapted to your profile.
## Direct purchase (Corporate ESG and mid-market) — In development [#direct-purchase-corporate-esg-and-mid-market--in-development]
For organizations that want to start with a smaller volume or explore credits before a long-term agreement:
1. Access the Carrot Store at [store.carrot.eco](https://store.carrot.eco)
2. Choose the credit type (TCC or TRC) and the volume in metric tons
3. Complete the purchase via Pix, credit card, or USDC
4. Receive the retirement certificate with public audit trail
5. Access **MyCarrot** at [my.carrot.eco](https://my.carrot.eco) — your impact management dashboard.
Track the complete history of purchases, issued certificates, and accumulated impact. No blockchain knowledge required.
[Access MyCarrot](https://my.carrot.eco)
{/* Prices must match src/data/pricing.ts (canonical source). Update both pricing.ts and hardcoded values here when prices change. */}
## Pricing [#pricing]
| Credit | Description | Price |
| ------- | -------------------------------------------------------------------------------------------------- | ----------------------- |
| **TCC** | Tokenized Carbon Credit — prevented GHG emissions | US$ 50.00 / metric ton |
| **TRC** | Tokenized Recycling Credit — certified recycled material with social and environmental co-benefits | US$ 103.53 / metric ton |
For enterprise volume purchases, TRC co-benefits can be negotiated with our sales team.
## Enterprise volume purchases [#enterprise-volume-purchases]
For organizations with annual offset targets, structured sustainability programs, or the need for integration with internal reporting systems:
**Advance Market Commitment (AMC)**
Large buyers can enter Advance Market Commitment (AMC) structures — forward purchase commitments that guarantee credit volume, establish commercial terms, and support the financing of new recycling capacity.
**The enterprise process includes:**
* **Needs assessment** — Mapping your offset targets, reporting standards, and estimated annual volume.
* **Commercial proposal** — Pricing, volume, and terms tailored to your sustainability program.
* **Technical due diligence** — Access to complete methodology documentation, sample audit trails, and technical team support for internal evaluation.
* **Contract and onboarding** — Integration with your reporting systems and certificate issuance flow.
## Partners and intermediaries [#partners-and-intermediaries]
If you want to incorporate Carrot credits into your product or service — offering carbon offset to your end customers — we have a dedicated partnership structure.
**Typical use cases:**
* Travel platforms offering offset for flight or hotel emissions
* E-commerce with carbon-neutral delivery option
* Financial services with ESG investment products
The partner model includes API access, certificates, and a shared revenue structure across the entire chain.
[Contact our team to start a partnership conversation](/docs/for-buyers/contact)
## Manage your impact with MyCarrot [#manage-your-impact-with-mycarrot]
Every purchase is recorded in MyCarrot — your impact management dashboard. In MyCarrot you access:
* Complete history of purchased and retired credits
* Retirement certificates with full audit trail
* Audit trail for each credit, linked to the [Carrot Explorer](/docs/protocol/explorer)
* Accumulated impact in metric tons of CO₂ and recycled material
The interface is fully accessible — no technical setup required.
[Access MyCarrot](https://my.carrot.eco)
**Still evaluating?**
Our team can provide sample audit trails, methodology documentation, and existing buyer references to support your due diligence process.
[Contact our team](/docs/for-buyers/contact)
# Impact Evidence
Each purchase generates a set of auditable evidence — designed to support ESG reporting, external audits, and public disclosures.
## Retirement certificate [#retirement-certificate]
When you retire credits, your organization receives an on-chain certificate with:
* Unique identifier of the retired credit
* Date and time of retirement (immutable timestamp)
* Volume in metric tons of CO₂ equivalent (or recycled material)
* Credit type and methodology applied
* Link to public audit trail — traceable to the physical event of origin
The certificate is permanent and verifiable by any third party via [Carrot Explorer](/docs/protocol/explorer).
## Public audit trail [#public-audit-trail]
Each credit has a chain of public, traceable evidence. An external auditor can verify:
1. The physical event that originated the credit (material type, weight, facility, date)
2. The digital MRV ([dMRV](/docs/protocol/dmrv)) verification applied (which rules were executed, which passed)
3. The [certificate](/docs/protocol/certificates) issued (GasID or RecycledID)
4. The credit minted and its transfer history
5. The retirement with beneficiary identification
## Reporting compatibility [#reporting-compatibility]
| Standard | How Carrot credits apply |
| ------------------------------- | ----------------------------------------------------------------------- |
| **GHG Protocol (Scope 3)** | Retired TCC credits as emissions offset for the relevant category |
| **CDP Climate Disclosure** | Evidence of compensation action with verifiable traceability |
| **GRI 305** | Retired credits as documented offset in emissions inventory |
| **ISO 14064-3** | Audit trail compatible with third-party verification |
| **EPR / Regulatory compliance** | TRC as recycling evidence for Extended Producer Responsibility programs |
[Contact our team](/docs/for-buyers/contact) — we can map how Carrot credits fit into your
specific framework.
## For technical and audit teams [#for-technical-and-audit-teams]
All evidence data is accessible via:
* **[Carrot Explorer](/docs/protocol/explorer)** — Public interface for manual verification
* **[Public API](/docs/integrations/api)** — For integration with ESG management systems or reporting platforms
* **Data export** — Available for audits and due diligence processes
[See the API Reference](/docs/integrations/api) | [Contact our team](/docs/for-buyers/contact)
# For Buyers
Carrot offers [environmental credits](/docs/protocol/credits) backed by real recycling events — verified by Carrot's digital Measurement, Reporting and Verification ([dMRV](/docs/protocol/dmrv)) system, recorded on a public blockchain, and auditable from the physical event to retirement. Every credit comes with a complete [audit trail](/docs/for-buyers/impact-evidence) and a [retirement certificate](/docs/protocol/credit-retirement) compatible with major ESG reporting standards.
Whether you lead an enterprise sustainability program or are ready to act before the market catches up, Carrot provides the evidence infrastructure to back your commitment.
If you want to understand the full ecosystem behind each credit, see
[Credit Ecosystem Roles](/docs/protocol/credit-ecosystem-roles).
Each credit is verified using event-level data (not estimates), auditable by any third party via [Carrot Explorer](/docs/protocol/explorer), and backed by open-source verification logic.
[See the evidence you receive](/docs/for-buyers/impact-evidence) | [Learn how credits are generated](/docs/for-buyers/traceable-credits)
## What is your profile? [#what-is-your-profile]
### Large Enterprises [#large-enterprises]
You represent an organization with global carbon targets, structured sustainability programs, and a need for auditable evidence for public reporting.
* Annual offset targets aligned with GHG Protocol, CDP, or ISO 14064-3
* Need for integration with internal reporting systems
* Require due diligence materials and technical evaluation support
[See the enterprise journey](/docs/for-buyers/how-to-buy#enterprise-volume-purchases)
### Corporate ESG [#corporate-esg]
You need to offset emissions or demonstrate ESG compliance, and want a simple process with clear documentation.
* Looking for verified credits with transparent pricing
* Want retirement certificates compatible with ESG disclosure standards
* Prefer a self-service purchase flow with no blockchain knowledge required
[See how to buy credits](/docs/for-buyers/how-to-buy)
### Partners & Intermediaries [#partners--intermediaries]
You want to offer carbon or recycling offsets as part of your product or service — for your end customers.
* Travel, e-commerce, or financial platforms embedding offset into their product
* Need API access for automated credit purchases and certificate issuance
* Shared revenue structure across the supply chain
[See how to become a partner](/docs/for-buyers/how-to-buy#partners-and-intermediaries)
# Traceable Environmental Credits
Each Carrot credit is backed by a real physical event — digitally verified, immutably recorded, and auditable by anyone.
## How a Carrot credit is generated [#how-a-carrot-credit-is-generated]
The process begins in the physical world: a batch of waste materials is collected, weighed, and identified at origin. This event generates a [MassID](/docs/protocol/mass-ids) — an immutable digital record that captures material type, weight, and chain of custody.
The MassID accompanies the material throughout the entire recycling chain. When it reaches an accredited facility and passes [methodology verification](/docs/protocol/methodology-execution), it generates a verified [certificate](/docs/protocol/certificates) and a matching environmental credit — a tokenized, fungible, and tradable asset.
Physical event → [MassID](/docs/protocol/mass-ids) (immutable record) → digital MRV
([dMRV](/docs/protocol/dmrv)) verification → [Certificate](/docs/protocol/certificates) (GasID /
RecycledID) → [Credit](/docs/protocol/credits) (TCC / TRC) → Retirement with public trail
## What this means for your organization [#what-this-means-for-your-organization]
**Complete audit trail**
Any auditor can walk the chain of evidence — from the retirement receipt to the physical event that originated the credit. The trail is public, permanent, and accessible via [Carrot Explorer](/docs/protocol/explorer) or any [blockchain block explorer](/docs/glossary#blockchain-block-explorer).
**Event data, not estimates**
Verification is based on data collected directly from the recycling event — not on projections, statistical models, or inferences. Each claim has corresponding physical evidence.
**Distributed social impact**
Under the current rewards model, more than 70% of the revenue from each credit is distributed to [supply chain participants](/docs/protocol/supply-chain) — from waste generators and haulers to processors and [recyclers](/docs/protocol/supply-chain#the-role-of-the-recycler). Your purchase supports the environmental workers and facilities that expand recycling capacity.
**Open-source and auditable**
The verification code ([MvA](/docs/standard/concepts/mva)) that executes methodology rules is open source (LGPL-3.0). Any technical team can audit the verification logic before a purchase decision.
## Available credit types [#available-credit-types]
{/* Prices must match src/data/pricing.ts (canonical source). Update both pricing.ts and hardcoded values here when prices change. */}
**[TCC](/docs/protocol/credits#tokenized-carbon-credits-tcc)** — Tokenized Carbon Credit
GHG emission reductions (e.g., methane diverted from landfill via composting). Issued under the [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) methodology. Aligned with UNFCCC CDM, [EPA WARM](https://www.epa.gov/warm), and [GHG Protocol](https://ghgprotocol.org/). US$ 50.00 per metric ton of CO₂ equivalent.
**[TRC](/docs/protocol/credits#tokenized-recycling-credits-trc)** — Tokenized Recycling Credit
Certified recycled material, processed at an accredited facility. Issued under the [BOLD Recycling](/docs/methodologies/bold-recycling) methodology. US$ 103.53 per metric ton.
[Learn about methodologies](/docs/methodologies) | [See the impact evidence you receive](/docs/for-buyers/impact-evidence)
# 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. 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. Create a document (`POST /documents`).
3. Append timeline events (`POST /documents/{documentId}/events`), or submit multiple events at once (`POST /documents/events`).
4. Upload optional files through pre-signed attachment URLs.
5. 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`.
* **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).
# 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), explore.carrot.eco, store.carrot.eco, docs.carrot.eco, my.carrot.eco, and whitepaper.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/legal/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/legal/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/legal/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/legal/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/legal/privacy-policy](/docs/legal/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/legal/token-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 or $Carrot) 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 Carrot Community Fund, 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, whitepapers, 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 [Carrot White Paper](https://whitepaper.carrot.eco/), Websites available at [www.carrot.eco](http://www.carrot.eco), docs.carrot.eco and [www.explore.carrot.eco](http://www.explore.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 White Paper, 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 current Code of Conduct is described in the [Carrot White Paper](https://whitepaper.carrot.eco/) under the Governance section and subsections for [Community Values](https://whitepaper.carrot.eco/) and [Community Guidelines](https://whitepaper.carrot.eco/).
## 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 Carrot's Community Fund 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/legal/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, white 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/legal/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/legal/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.
# Terms and Conditions for Token Sales and Purchases
{/* cspell:words Fndn stablecoins */}
**Version 1.0 — March 29, 2024**
## Preambles [#preambles]
Carrot Fndn, a Swiss foundation in the sense of Article 80 et seqq. Swiss Civil Code with its registered seat in Zug (**"Foundation"**) has developed and deployed the Carrot blockchain-based network (**"Network"**) that allows the off-chain and on-chain recording of circular economy actions taken by raw material providers, packers, fillers, producers, waste generators, bin custodians, haulers, processors, recyclers, raw material buyers, network integrators, methodology authors, methodology developers, auditors, NGOs, among others (**"Users"**). The circular economy actions are recorded off-chain by Carrot Network Integrators (**"INTs"**) before being submitted and recorded on the Network via APIs. Waste resources (**"MassIDs"**) and/or products (**"ProductIDs"**) are codified as unique identifiers that can record the chain of custody of materials and/or products and thereby the responsibility over them. The circular economy actions recorded and tracked through MassIDs and ProductIDs serve as the basis for real-world activity verification and certification of environmental contributions and the issuance of non-fungible Tokenized Recycling Credits (**"TRC"**) as well as non-fungible Tokenized Carbon Credits (**"TCC"**) by the Foundation (**"Project"**) which, when purchased, distribute token rewards to environmental contributors recorded in the chain of custody. Retired TRCs and TCCs can be utilized to report the environmental and social claims that were realized through the circular economy actions (**"Environmental & Social Claims"**).
The Foundation generates the TRC and TCC (**"Tokens"**), as further described below, and offers them for sale to you and other individuals and entities (**"Buyers"**) in a continuous public sale (**"Token Sale"**) under the following terms and conditions (**"Token Purchase Terms"**).
By accepting these Token Purchase Terms and transferring the Purchase value as defined below, you, as the buyer, enter into a legally binding token sale agreement with the Foundation. As a buyer, you are responsible for complying with applicable laws and regulations, in particular, but not limited to, the regulations governing the receipt, holding, and sale of Tokens.
These Token Purchase Terms are subject to the general [Terms and Conditions](/docs/legal/terms-and-conditions) of the Foundation.
## 1. Purchase and Allocation of Tokens [#1-purchase-and-allocation-of-tokens]
By participating in the Token Sale, the Buyer purchases Tokens from the Foundation, and the Foundation sells Tokens to the Buyer.
Subject to the acceptance of these Terms and the transfer of the purchase value as indicated in the purchase process (Token Purchase Terms and the successful passing of the Foundation's KYC process), the Foundation undertakes to allocate to the Buyer the corresponding Tokens and deliver said Tokens within 180 days after receiving the proceeds, or by a mutually agreed upon date determined in a separate contract.
The Buyer may transfer the purchase value to the foundation in two ways.
### 1.1 Direct Purchase [#11-direct-purchase]
The Buyer may conduct a direct purchase of the non-fungible token ("NFT") (i.e., TRCs or TCCs) using USDC or another stablecoin token. The purchase delivers the NFT to the Buyer and distributes a portion of stablecoins utilized as rewards to each Participant recorded in the chain of custody. Third-party services may be utilized to facilitate this transaction, including the use of credit cards and other financial services.
### 1.2 Funds Transfer [#12-funds-transfer]
The Buyer may transfer the funds by wire to the foundation's bank account or by sending stablecoins (e.g., USDC) to its digital wallet. Given the added complexity of this process, additional fees may be charged, and the delivery date may be significantly delayed, which is the reason why a longer period for delivery is requested and will be negotiated with the token Buyers.
## 2. Technical Description of the Token [#2-technical-description-of-the-token]
The Tokens (TRC and TCC) are unique blockchain-based digital information units built using the ERC-721 Non-Fungible Token standard that have their transactions recorded on the Ethereum blockchain. TRCs are associated with unique MassIDs that contain material mass type and weight, along with the corresponding circular economy actions and its chain of custody. TCCs represent the measured, verified and reported greenhouse gas emissions that were prevented, captured or removed from a unique set of MassIDs. The circular economy information contained in the Tokens depends on the specific Token, but comprises at least the information mentioned in Section 2.1.
### 2.1 Functionality of the Tokens [#21-functionality-of-the-tokens]
The Tokens have the following functions:
### 2.2 Evidence Function [#22-evidence-function]
TRCs correspond to one or more unique MassID which serve as evidence that a certain number of metric tons of a certain type of waste in a specific area has arrived at an appropriate recycling or reuse center and/or been recycled or reused (e.g., 1 metric ton of aluminum has been recycled in the state of Sao Paulo, Brazil); or
TCCs correspond to one or more unique MassIDs that serve as evidence that a certain number of metric tons of CO2 equivalent emissions have been prevented, captured, or removed through recycling, reuse, or other verifiable activities in a specific location (e.g., 1 metric ton of CO2e has been prevented in the state of Sao Paulo, Brazil, due to the composting of organic waste when compared to the baseline of sending waste to a landfill).
### Retirement Function [#retirement-function]
Token holders can retire their Tokens subject to paying the retirement fee as further described in Section 2.4. The Retirement renders the Tokens non-transferable, establishing permanent ownership over the Token and the underlying Environmental and Social Claims realized through the measurement, reporting, and verification process as determined by a Carrot Network-approved methodology (**"Methodologies"**).
The Foundation remains free to change the name, symbol, and collection of future Tokens issued at any time and at its sole and free discretion.
### 2.3 No Redemption; No Ownership, Revenue or Participation Rights [#23-no-redemption-no-ownership-revenue-or-participation-rights]
Tokens do not give any (partial or full) claim for redemption. In particular, holders of TRCs and TCCs do not receive anything in return for the retirement of their Tokens other than the claim of their ownership of the Token itself and what it represents.
Tokens are not designed to be used as a means of payment.
Tokens do not represent or constitute any ownership rights, stakes, shares, security, or equivalent rights, nor any rights to receive future revenues, shares, or any other form of participation or governance rights in or relating to the Network and/or the Foundation. The Tokens do not create or confer any enforceable contractual or other obligations against any party, including the other Users, the Foundation, as well as its employees, contractors, and/or founders.
The Buyer has no license right and no right to any intellectual property rights, equivalent rights, or any other form of participation in or relating to the Network and/or the Foundation.
### 2.4 Retirement [#24-retirement]
A Token retirement fee can be charged when a Token Owner retires, or burns, the TRC or TCC himself/herself/itself for permanent ownership (**"Direct-Burn"**). The Direct Burn fee is embedded in the Token.
A Burn-As-A-Service (**"BAAS"**) retirement fee can be charged on a one-time basis when a Token Buyer needs assistance in purchasing and retiring specific TRCs or TCCs, such as from a MassIDs from a specific location. The BAAS fee may be embedded in the Token or charged separately, and it may be changed at any time in order to ensure adequate services are delivered.
Registry data storage (**"Registry Storage"**) fees can be charged following Token retirement to cover costs of storing data on a public database.
Additional Registry Services (**"Registry Services"**) may be offered by Carrot Fndn and contracted by the owner of the retired Tokens.
## 3. Know Your Customer/Business ("KYC") [#3-know-your-customerbusiness-kyc]
Buyers must provide individual identification information, such as their full name, mobile number, birthdate, email address, wallet address to which Rewards will 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.
Know Your Customer and Know Your Business checks may be conducted by the Carrot Network itself or by third parties on behalf of the Carrot Network.
## 4. Taxation [#4-taxation]
All taxes (including VAT, if any), charges, levies, assessments, and other fees of any kind imposed on the receipt or import of Tokens by the Buyer shall be the responsibility of, and for the account of, the Buyer.
## 5. Third-Party Fees [#5-third-party-fees]
Any third-party fees, including transaction fees, not-related specifically to the acquisition of a given Token are not the responsibility of the Carrot Fndn and are the full responsibility of the token Buyer including, but not limited to, the purchase of stablecoins to be used for the purchase of Tokens, on-ramping and off-ramping, KYC and AML fees, wallet management fees, gas fees, exchange fees relating to Token swaps, wrapping smart contract fees, liquidity pool fees, etc.
## 6. Risks [#6-risks]
The Buyer understands and accepts the risks connected to Tokens. In particular, but not exhaustively, the Buyer understands the inherent risks listed hereinafter. By accepting these Terms, the Buyer expressly acknowledges and assumes these risks.
### 6.1 Risk of Software Weaknesses [#61-risk-of-software-weaknesses]
The Buyer understands and accepts that the Network and the underlying infrastructure are young technologies, which is why there is no warranty that the process for receiving, using, and owning Tokens will be uninterrupted or error-free. The Buyer further understands and accepts that there is an inherent risk that the Network and the underlying technologies contain weaknesses, vulnerabilities, or bugs, causing, inter alia, the complete loss of the Tokens.
The Buyer particularly understands and accepts that the Network is as of its deployment immutable and that, consequently, it may be difficult or impossible to correct recorded errors or cure software weaknesses.
### 6.2 Regulatory Risk [#62-regulatory-risk]
The Buyer understands and accepts that blockchain technology allows for 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 Network, including the termination of the Project and the loss of the Tokens or their functionality for the Buyer.
The Buyer understands and accepts that even if Tokens do not create or confer any contractual or other obligations against any party (including the Foundation as well as its employees, contractors, and/or founders), certain regulators may nevertheless qualify Tokens as securities or other financial instruments under their applicable law. It remains the Buyer's responsibility to comply with any laws and regulations applicable to the Buyer when holding or transferring the Tokens.
The Buyer understands and accepts that no securities or other regulatory authority has expressed an opinion about the status of Tokens, and it is a criminal offense under the laws of some jurisdictions to claim otherwise;
The Buyer understands and accepts that the transactions contemplated in these Terms have not been reviewed by, passed on, or submitted to any regulatory agency or self-regulatory organization. As a result, the Buyer will not be afforded the full set of protections provided to the clients and customers of such entities under any applicable laws, and
The Buyer understands and accepts that if the Tokens are deemed to be securities in one or more jurisdictions, or if these Terms or the issuance of the Tokens constitute a non-exempt forward contract, or if the Foundation or its affiliates are required to register with a regulatory agency, the Tokens and the Foundation could be subject to significant additional regulation, including restrictions on transferability and resale or operational activity. This could lead to significant changes with respect to Tokens, how Tokens are structured, how they are purchased and sold, and other issues, and would greatly increase the Foundation's costs in creating and facilitating transactions in Tokens. Such regulation could lead to the Tokens losing functionality and/or depreciating partially or fully in value, subject the Foundation and its affiliates, directors, and officers to potential penalties, including federal civil and criminal penalties, or make the Tokens illegal or impossible to use, buy, or sell in the United States and other jurisdictions. Further, a regulator could take action against the Foundation or its affiliates if it views Tokens as an unregistered offering of securities or the Foundation's operations otherwise as a violation of existing law. Any of these outcomes would negatively affect the value and functionality of the Tokens and/or could cause the Foundation to cease operations.
### 6.3 Risk of Abandonment / Lack of Success [#63-risk-of-abandonment--lack-of-success]
The Buyer understands and accepts that the further development of the Project may be abandoned for a number of reasons, including, but not limited to, lack of interest from the public, lack of funding, incapacitation of key developers and project members, force majeure (including pandemics) or lack of commercial success or prospects. The Buyer therefore understands that there are no assurances that the Buyer will be able to retire his Tokens.
### 6.4 Risk of Private Key Loss [#64-risk-of-private-key-loss]
Tokens allocated to a particular address can only be accessed with the private key associated with that address. The Buyer understands and accepts that if its private key file or wallet password were lost or stolen, the allocated Tokens associated with the Buyer's address or password would be unrecoverable and would be permanently lost. The Foundation has no control over the Tokens; therefore, the Buyer shall have no recourse to seek any refunds, recovery, or replacements from the Foundation in the event that the Tokens are lost or stolen.
### 6.5 Risk of Theft [#65-risk-of-theft]
The Buyer understands and accepts that the Network and/or the underlying infrastructure, other involved software, other technology components, and/or platforms may be exposed to attacks by hackers or other individuals that could result in theft or loss of the Tokens.
### 6.6 Risk of Network Attacks and Forks [#66-risk-of-network-attacks-and-forks]
The Buyer understands and accepts that, as with other blockchain-based tokens, the Network and/or the underlying infrastructure 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, 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 Buyer.
### 6.7 Limitation of Liability [#67-limitation-of-liability]
**PLEASE READ THIS SECTION CAREFULLY. THESE PROVISIONS LIMIT THE SCOPE OF THE FOUNDATION'S LIABILITY IN CONNECTION WITH THE TRANSACTIONS CONTEMPLATED BY THESE TERMS.**
The Parties limit the liability of both Parties under these Terms under any title to damages caused by fraud, wilful misconduct, or gross negligence. To the fullest extent permitted by any applicable law, in no event will the aggregate liability of the Buyer or the Foundation exceed, as the case may be, the amount of the Purchase Price.
The Buyer acknowledges and agrees that, to the fullest extent permitted by any applicable law and subject to paragraph 25, the Foundation or any of its employees, contractors and/or founders are not liable, and the Buyer agrees not to hold them liable, for any and all damages (including direct, indirect, incidental, and/or consequential damages, loss of profits, goodwill or data), regulatory implications, tax or other liability or injury whatsoever caused by or related to the use of, or the inability to use the Network, the allocation, ownership or use of Tokens or in connection with these Terms or any transaction contemplated in these Terms under any cause or action whatsoever of any kind in any jurisdiction.
The Foundation provides no warranties or guarantees regarding the availability, reliability, accuracy, or quality of the Tokens. The Tokens are provided on an "as is" basis, without any express or implied warranties of any kind.
## 7. General Representations and Warranties of the Buyer [#7-general-representations-and-warranties-of-the-buyer]
The Buyer represents and warrants to the Foundation the following and acknowledges that the Foundation is relying on these representations and warranties:
a) The Buyer is duly organized, validly existing and in good standing under the laws of the country in which he is incorporated and has all requisite power and authority to execute, issue and deliver this Agreement, and to carry out and perform its obligations under this Agreement and any related agreements;
b) The Buyer is 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 the Buyer nor any of its 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;
c) The Buyer confirms not to be resident of, citizen of or located in a geographic area that is subject to UN-, US-, EU-, Swiss or any other sovereign country sanctions or embargoes;
d) The Buyer is not domiciled in or organized under the laws of any country, whose legislation conflicts with the present allocation of the Tokens and/or the purpose of the Foundation in general;
e) The Buyer 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 lit. b) – d) above;
f) Any funds used for the transfer of the Purchase Price are: (a) good, clean, clear and are of non-criminal origin; (b) completely free and clear of any liens or encumbrances of any kind of any rights of third-party interests; and (c) have no origins that may be connected to any breach of money laundering regulations whatsoever, as defined in the jurisdiction of origin, or internationally;
g) The Buyer understands that no public market may exist for the Tokens, and that the Foundation has made no assurances that a public market will ever exist for the Tokens;
h) The Buyer has such knowledge and experience in financial and business matters that the Buyer is capable of evaluating the merits and risks of participating in the Token Sale respectively, of such investment and being allocated the Tokens, is able to incur a complete loss of such investment without impairing the Buyer's financial condition and is able to bear the economic risk of such investment for an indefinite period of time;
i) The Buyer has a deep understanding of the functionality, usage, storage, transmission mechanisms and intricacies associated with cryptographic tokens, like BTC and ETH, and blockchain-based software systems;
j) The Buyer understands that the Token Sale does not involve the purchase of shares, securities exchangeable into shares or any equivalent in any existing or future public or private company, corporation or other entity in any jurisdiction;
k) The Buyer has been advised that the Tokens to be allocated to the Buyer hereunder may, in certain jurisdictions, be considered a security and that the Tokens issuable hereunder may not be resold except in compliance with applicable securities laws. Consequently, Buyer understands that Buyer must bear the economic risks of its purchase under these Terms or possible future receipt of Tokens for an indefinite period of time;
l) All information provided by the Buyer within any registration process linked to this purchase is true and accurate and the Buyer does not act on behalf of any third-party;
m) The Buyer is legally permitted to receive, hold and make use of Tokens in its jurisdiction and is not obtaining or using Tokens for any illegal purposes;
n) The Buyer is purchasing the Tokens to make use of their functionality. In particular, the Buyer is not purchasing the Tokens for the purpose of speculative investment;
o) The Buyer will indicate to the Foundation an address for the allocation of the Tokens prior to the allocation of the Tokens. The Buyer understands and accepts that indicating a false address or an address that does not technically support the Tokens may result in the Buyer failing to gain access to its Tokens. The Buyer further understands that it remains in its sole responsibility to safeguard the private key file related to said address and that in case the Buyer loses access to the address (or wallet), the Tokens would be unrecoverable and permanently lost;
p) The Buyer confirms that the Buyer's address belongs to the Buyer and is under his sole control. Buyer understands that as part of the Token allocation process, he may be requested by the Foundation or a Service Provider to evidence control over the Buyer's address and that, lacking such proof, the Token allocation may not be conducted.
q) The Buyer understands that it has no right against any party to request any refund of the Purchase Price under any circumstance.
r) THE BUYER HEREBY WAIVES THE RIGHT TO PARTICIPATE IN ANY CLASS-ACTION LAWSUIT OR CLASS-WIDE ARBITRATION AGAINST ANY ENTITY OR INDIVIDUAL INVOLVED IN THE ALLOCATION OF TOKENS AND WITH THE OPERATION OF THE NETWORK;
s) The Buyer understands and expressly accepts that there is no warranty whatsoever on the Tokens and/or the success of the Project, expressed or implied, to the extent permitted by law, and that the Tokens to be created and obtained are at the sole risk of the Buyer 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;
t) The Buyer understands and accepts that it has 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, white paper, marketing materials, social media content or website posting;
u) The Buyer understands that the value of Tokens over time (if any) may experience extreme volatility or depreciate in full;
v) The Buyer understands that it bears the sole responsibility to determine if the transfer of the Purchase Price, the allocation, use or ownership of Tokens, the potential appreciation or depreciation in the value of Tokens over time (if any), the sale and purchase of Tokens and/or any other action or transaction related to the Network have tax implications.
## 8. Representations, Warranties, and Acknowledgments of the Foundation [#8-representations-warranties-and-acknowledgments-of-the-foundation]
The Foundation represents and warrants to the Buyer the following, and acknowledges that the Buyer is relying on these representations and warranties:
a) 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.
b) The execution, delivery, and performance of these Terms will – to the best knowledge of the Foundation – not result in any violation of, be in a material conflict with, or constitute a material default under (i) any provision of the Foundation's organizational documents; (ii) any provision of any permit, judgment, decree, contract or order to which the Foundation is a party.
c) The execution, delivery, and performance under these Terms require no approval or other action from any person other than the Foundation.
## 9. Warranty Disclaimer [#9-warranty-disclaimer]
The Tokens are sold on an "as is" and "as available" basis without warranties of any kind. To the fullest extent permitted by applicable law, the Foundation expressly disclaims all implied warranties as to the Tokens and/or the Network, including, without limitation, implied warranties of merchantability, fitness for a particular purpose, title, and non-infringement. The Foundation does in particular not warrant that the Tokens are reliable, current, or error-free, meet the Buyer's requirements, or that defects in the Tokens and/or the Network will be corrected; and (iii) the Foundation cannot and does not warrant that the Tokens, the Network, or the delivery mechanism for Tokens are free of viruses or other harmful components.
Some jurisdictions do not allow the exclusion of certain warranties or disclaimers of implied terms in contracts with consumers, so some or all of the exclusions of warranties and disclaimers in this Section may not apply to the Buyer. In such a case, it will be so held to the minimum extent required by law, and all other terms, clauses, and provisions of this Agreement will remain valid and enforceable.
## 10. Miscellaneous [#10-miscellaneous]
### 10.1 Independent Contractors [#101-independent-contractors]
These Terms do not create a principal or agent, employer or employee partnership, joint venture, or any other relationship except that of independent contractors between the Parties. Nothing contained herein shall be construed to create or imply a joint venture, principal and agent, employer or employee, partnership, or any other relationship except that of independent contractors between the Parties, and neither Party shall have any right, power, or authority to create any obligation, express or implied, on behalf of the other in connection with the performance hereunder.
### 10.2 Assignments and Transfers [#102-assignments-and-transfers]
These Terms, including any rights and obligations contained herein, and in particular the right to being allocated Tokens as described herein, cannot be assigned or transferred by the Buyer in whole or in part without the prior written consent of the other Party, such consent to be given at the sole and exclusive discretion of the other Party and only in compliance with applicable laws and regulations, including without limitation the Securities and Exchange Act and regulations promulgated thereunder. Any assignment or transfer that does not conform with the terms of this provision shall be void.
### 10.3 Severability [#103-severability]
If any provision of these Terms should be invalid in any jurisdiction under applicable law, the legality and enforceability of the remaining provisions hereof shall not in any way be affected or impaired thereby. In such an event, the Parties commit themselves to compose a legally valid replacement rule that approaches the invalid provision as closely as possible within the economic intent of these Terms. These Terms will be interpreted as though the invalid clause had been omitted from the outset.
### 10.4 No Waiver [#104-no-waiver]
If any Party waives the enforcement or exercise of its contractual right in a particular case, this may not be considered a general waiver of the respective right, any other contractual right, or the exercise and enforcement thereof.
### 10.5 Governing Law and Jurisdiction [#105-governing-law-and-jurisdiction]
These Terms and all claims relating to or arising out of them, or the breach thereof, whether in contract, tort, or otherwise, shall be governed by Swiss Law, excluding Swiss choice-of-law principles. The United Nations Convention for the International Sales of Goods ("Vienna Sales Convention") is excluded.
Any dispute, controversy, or claim arising out of or in relation to, these Terms, including the validity, invalidity, breach, or termination thereof, shall be resolved by the ordinary courts in Zug, Switzerland.
# 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 or FAILED 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 | Token | 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 a circular, low-carbon 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.
## 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 make governance a promise of current decentralized control.
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 on-chain records, including [MassIDs](/docs/protocol/mass-ids), [Certificates](/docs/protocol/certificates), credit tokens, and retirement receipts, are recorded on public blockchain infrastructure
* Rule execution and verification outputs remain inspectable through the [Carrot Explorer](/docs/protocol/explorer) 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 makes the network public-purpose infrastructure: shared market rails for circular economy crediting, governed to serve the mission rather than a private product optimized for extraction.
## A governance layer [#a-governance-layer]
The Carrot Network is a technology-enabled governance layer for shared market infrastructure. Smart contracts support 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 Explorer](/docs/protocol/explorer) traceability.
Blockchain is part of this accountability model because it gives final credit records 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.
In the language of Chris Dixon's [*Read Write Own*](https://a16zcrypto.com/posts/article/read-write-own-intro/), this model reflects the shift from platforms that read and write data on behalf of users to networks where participants own the rules and outcomes. 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 on-chain credit infrastructure records can be independently verified through public blockchain infrastructure and reused by interoperable systems.
* **Reward sharing** — credit purchase revenue is distributed according to published rewards policies for the relevant supply chain and methodology roles.
## 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).
## Learn more [#learn-more]
How decisions are made within the Carrot Network
The Carrot Foundation's role, structure, and purpose
# The Foundation
## The Carrot Foundation [#the-carrot-foundation]
The Carrot Foundation is the guardian of the Carrot ecosystem — 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.
## 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, decentralized software architectures, 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** — Blockchain, security, AI, IoT
For the current list of advisors, visit [carrot.eco](https://www.carrot.eco/).
# Original White Paper
## Original White Paper [#original-white-paper]
The original Carrot White Paper remains useful as historical context for the early thinking behind
the [Carrot Network](/docs/network). It is not the current source of truth for the live protocol,
methodologies, registry, governance, rewards, legal terms, or buyer-facing information.
Current docs take precedence wherever they differ from historical White Paper language.
## Current source of truth [#current-source-of-truth]
* **Protocol and verification** — Start with the
[Circular Economy Protocol](/docs/protocol), then use
[MassIDs](/docs/protocol/mass-ids) and digital MRV ([dMRV](/docs/protocol/dmrv)) for the current verification
flow.
* **Registry and rewards** — Use the [registry](/docs/registry) page for credit issuance,
tracking, and retirement, and [Rewards Distribution](/docs/protocol/rewards-distribution) for how
credit revenue reaches verified contributors.
* **Standard and methodologies** — Use [The Standard](/docs/standard) for Carrot's role as a
standards body and [Methodologies](/docs/methodologies) for approved methodology content.
* **Foundation and governance** — Use [The Foundation](/docs/network/the-foundation) for the
Foundation's role and public purpose, and [Governance](/docs/network/governance) for how
participation evolves around that purpose.
* **Buyers and legal terms** — Use [For Buyers](/docs/for-buyers) for buyer-facing information,
[Terms and Conditions](/docs/legal/terms-and-conditions), and
[Token Sales Terms](/docs/legal/token-sales-terms) for legal terms.
For questions about the historical White Paper or archived background material, reach out to the
founding team at [founders@carrot.eco](mailto:founders@carrot.eco).
# 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) |
| 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 Integrator | Connects operational systems to Carrot by submitting supply chain data through the API. | [Network Integrators](/docs/protocol/network-integrators) |
| 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. | [For Buyers](/docs/for-buyers) |
## 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. The methodology is translated into an **MvF** and implemented as an **MvA**.
4. **Network Integrators** submit supply chain data from physical operations.
5. **dMRV** executes methodology rules against that data and produces auditable evidence.
6. **VVBs and independent auditors** provide external assurance where required.
7. Verified outcomes become [certificates](/docs/protocol/certificates) and [credits](/docs/protocol/credits).
8. The **registry** issues, tracks, and retires credits.
9. **Credit buyers** purchase and retire credits.
10. Revenue flows back to verified contributors through [rewards distribution](/docs/protocol/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
* [For Buyers](/docs/for-buyers) — What credit buyers receive and how to buy
# 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) — non-fungible tokens that 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 mint fungible credit tokens: [Tokenized Carbon Credits (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc) and [Tokenized Recycling Credits (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc). These credits are standardized by material type, 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 smart contracts. 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, what evidence you receive, and how to start an enterprise
conversation. [Go to For Buyers](/docs/for-buyers)
# 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, tokenized 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, on-chain minting, purchase, and retirement
Smart contracts, on-chain flows, and interoperability
# 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 tokenization, 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 tokenization, 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 on-chain minting.
[Learn about methodology execution](/docs/protocol/methodology-execution)
### 4. On-chain minting [#4-on-chain-minting]
Each verified MassID is minted on-chain — metadata is built, uploaded to [IPFS](https://ipfs.tech/), and the MassID NFT is minted on-chain. This creates an immutable, publicly verifiable record of the waste batch.
[Learn about on-chain minting](/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 fungible credit tokens — [Tokenized Recycling Credits (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc) and [Tokenized Carbon Credits (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc) — each representing 1 metric ton of verified environmental impact. The [BOLD Recycling](/docs/methodologies/bold-recycling) methodology issues TRCs as `C-BIOW`; the [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) methodology issues TCCs as `C-CARB.CH4` (methane). Other methodologies may issue different credit symbols. Credits are standard ERC-20 tokens, 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 as atomic on-chain transactions in USDC; all steps complete in a single transaction or none of them do.
### 8. Rewards distribution [#8-rewards-distribution]
Revenue from credit purchases is [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 burns the credit tokens on-chain and mints a [soulbound](/docs/protocol/credit-lifecycle) `CreditRetirementReceipt` as permanent proof. Credits can be retired standalone (at any time after purchase) or through integrated retirement (purchased and retired in a single atomic transaction).
## Public verifiability [#public-verifiability]
All on-chain activity — from MassID minting through credit retirement — is recorded on the **public blockchain** as smart contract transactions. 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 chain 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 Explorer](/docs/protocol/explorer) offers a user-friendly, domain-focused view of on-chain data plus platform data (methodology definitions, rule execution, accreditations). For decentralized, infrastructure-independent verification of on-chain data only, any blockchain block 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 on-chain infrastructure that powers the network
* [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
* [Explorer](/docs/protocol/explorer) — The Carrot Explorer and blockchain block explorers for verifying on-chain data
### 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 smart contracts.
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/for-buyers/how-to-buy) | [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: no single entity controls both the execution of verification rules and the judgment of whether those rules are correctly applied.
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. Every verification result is deterministic, recorded on-chain, and auditable by any party. | Deterministic software, auditable by VVBs and the public |
## 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
## What is a standard in environmental markets? [#what-is-a-standard-in-environmental-markets]
In environmental markets, a **standard** is the organization that defines and governs the rules for how environmental credits are measured and verified. It approves 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, 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.
## 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 on-chain and viewable through the [Carrot Explorer](/docs/protocol/explorer).
* **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 slashed. 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** — MvF, MvA, ecosystem, and lifecycle fundamentals.
* **Guides** — Practical guides for authoring frameworks, building verification applications, and participating in RFPs.
* **Policies** — Versioning, quality assurance, accreditation, discontinuation, and rewards distribution.
# 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. 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.
* Attachments are typically referenced later from event payloads.
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 unauthorized`: invalid, expired, or malformed bearer token.
* `403 restrictedResource`: valid token without permission for the target resource.
***
[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`
* one of `participantId` or `participant` (required)
* one of `addressId` or `address` (required)
Optional fields:
* `deduplicationId` to avoid duplicate submissions on retries.
* `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": "validationError",
"message": "Failed validating required field",
"id": "5g1XRgWZ0odA79dHJvcPP",
"timestamp": "1684766595"
}
]
}
```
## Error codes [#error-codes]
| HTTP | Code | Meaning |
| ---- | -------------------------------- | ---------------------------------------------------------------------- |
| 400 | `invalidJson` | Request body could not be decoded as JSON. |
| 400 | `validationError` | Request payload failed schema validation. |
| 401 | `unauthorized` | Access token is missing, invalid, or expired. |
| 403 | `restrictedResource` | Token does not have permission for this resource or environment. |
| 404 | `objectNotFound` | Resource does not exist or is not shared with token owner. |
| 409 | `conflictError` | Operation could not be completed due to data conflict. |
| 409 | `PENDING_PROCESS_CONFLICT_ERROR` | Requested document is still processing. Retry later. |
| 429 | `Too Many Requests` | Request rate exceeded allowed threshold. |
| 500 | `internalServerError` | Unexpected server-side failure. |
| 503 | `serviceUnavailable` | Service temporarily unavailable or request exceeded processing window. |
| 504 | `gatewayTimeout` | Upstream timeout/session expiration while completing request. |
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.
## Batch events [#batch-events]
Use `POST /documents/events` to create multiple events for a document in a single request. Each event
in the batch follows the same schema and validation rules as the single-document endpoint above.
## 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. |
| `RELATED` | Links this document to another document. |
| `UPDATE` | Updates specific document visibility fields. |
| `SPLIT` | Creates a new document with part of the original value. No dedicated schema — represented via `target` payload fields. |
| `OUTPUT` | Creates a new downstream document from current data. No dedicated schema — represented via `target` payload fields. |
| `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`). `SPLIT` and `OUTPUT` do not have their own schemas and are
instead represented through event data using the `target` payload fields.
## 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.
## Event propagation [#event-propagation]
When `propagateEvent` is enabled, propagation applies only one relationship level deep.
Some event combinations are restricted (for example, propagated events cannot send `value`).
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: 6 endpoints across 3 resources (`documents`, `events`, `attachments`).
## Base URL [#base-url]
* API: `https://api.carrot.eco`
* Auth: `https://auth.api.carrot.eco/oauth2/token`
* Explorer: `https://explore.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.
* [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).
# 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 Explorer](https://explore.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) Create a document [#2-create-a-document]
Create the base traceability record:
```http
POST /documents
Authorization: Bearer
```
Endpoint details: [Documents](/docs/integrations/api/documents).
## 3) Append an event [#3-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).
## 4) Retrieve and validate state [#4-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).
## 5) Add production safeguards [#5-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 |
| `401` / `403` | 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` | Other conflict errors | **Abort** — fix data conflict (e.g. duplicate), 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 (`4xx` other than `409 PENDING_PROCESS_CONFLICT_ERROR` and `429`).
## deduplicationId mechanics [#deduplicationid-mechanics]
The `deduplicationId` is your idempotency 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). If the server already processed your request, the retry returns the original response instead of creating a duplicate. This is critical for `POST /documents` and `POST /documents/{id}/events`.
## 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 /v1/documents/{wrongDocumentId}/events
{ "name": "CANCEL", ... }
2. POST /v1/documents
{ ...corrected document data... }
3. POST /v1/documents/{newDocumentId}/events
{
"name": "RELATED",
"relatedDocument": {
"documentId": "{wrongDocumentId}",
"bidirectional": true
},
...
}
```
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 per-integrator rate limits (see [Rate Limits](/docs/integrations/reference/rate-limits) for the full reference):
| Environment | Limit |
| -------------- | ---------------------- |
| Test / Sandbox | 5 requests per second |
| Production | 10 requests per second |
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 Explorer](/docs/protocol/explorer).
* `isPubliclySearchable`: controls whether records can be found through public search.
The `isPublic` flag can appear at three levels:
* **Event level** — controls visibility of the entire event.
* **Attribute level** — overrides event-level visibility for a specific attribute.
* **`metadata.attributes` level** — controls visibility of individual metadata entries.
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.
When a document or event is marked as public (`isPublic: true`), anyone with the document ID can
view it on the Carrot Explorer (explore.carrot.eco). When private (`isPublic: false`), the
data is hidden from public view but remains accessible to auditors for compliance verification.
## 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 `sensible: true` (the API field name for sensitive-data masking) in
the metadata. The platform applies masking on public surfaces (e.g. `AA*-A**A` for a license
plate) while preserving the full value for auditors.
Do not pre-mask or redact values in your payload. Send the complete data and let the platform handle
the masking.
See [Data Formats](/docs/integrations/reference/data-formats#sensitive-data) for the `sensible`
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 — protects generator identity from competitors |
| Transport manifest (MTR) | Attachment | Download restricted for confidentiality; the existence of the document remains publicly visible |
| Final destination certificate (CDF) | Attachment | Download restricted for confidentiality; the existence of the document remains publicly visible |
| Vehicle license plate | Event metadata | Personal data — use `sensible: true` with `isPublic: true` for partial masking |
| Driver identifier | Event metadata | Personal data — use `sensible: 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 `sensible: 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 — these are created inline on your first submission (no separate creation step needed)
* Familiarity with [core concepts](/docs/integrations/getting-started/core-concepts) — especially the immutable event-sourced model
## Step 1: Create the document [#step-1-create-the-document]
Create the root record with classification and baseline visibility fields. Participant and address
data can be sent inline as objects on the first request. On subsequent requests, you can reuse the
IDs returned by the platform.
```json
POST /v1/documents
{
"category": "MassID",
"type": "YOUR_WASTE_TYPE",
"measurementUnit": "kg",
"externalCreatedAt": "2026-03-01T10:00:00.000Z",
"isPublic": true,
"isPubliclySearchable": true,
"participant": {
"countryCode": "BR",
"name": "Example Company",
"taxId": "11111111111111",
"taxIdType": "CNPJ",
"type": "COMPANY"
},
"address": {
"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
},
"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` | Yes | `kg` for recycling, `kg CO₂e` for carbon |
| `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 |
| `participant` | No\* | Inline participant object (see required fields below) |
| `participantId` | No\* | ID of an existing participant — use for subsequent requests |
| `address` | No\*\* | Inline address object (see required fields below) |
| `addressId` | No\*\* | ID of an existing address — use for subsequent requests |
| `externalId` | No | Your internal ID for reconciliation — useful for mapping back to your system |
| `deduplicationId` | No | Idempotency key — see tip below |
\* Send either `participant` (inline object) or `participantId` (ID), not both.
\*\* Send either `address` (inline object) or `addressId` (ID), not both.
On your **first request**, send full `participant` and `address` objects. The platform creates
them and returns their IDs in the response. On **subsequent requests**, reuse those IDs via
`participantId` and `addressId` instead of resending the full objects.
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.
**Inline `participant` required fields:**
| Field | Type | Description |
| ------------- | ------ | -------------------------------------------- |
| `countryCode` | string | Two-letter country code (ISO 3166-1 alpha-2) |
| `name` | string | Full name or company name |
| `taxId` | string | Tax ID number (digits only, no formatting) |
| `taxIdType` | string | Tax ID type — e.g. `CPF`, `CNPJ` |
| `type` | string | `PERSON` or `COMPANY` |
Reference: [Documents API](/docs/integrations/api/documents).
## Step 2: Append timeline events [#step-2-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 a participant and address:
```json
POST /v1/documents/{documentId}/events
{
"name": "ACTOR",
"label": "YOUR_ROLE_LABEL",
"externalCreatedAt": "2026-03-01T10:05:00.000Z",
"isPublic": true,
"participant": {
"countryCode": "BR",
"name": "Participant Name",
"taxId": "22222222222",
"taxIdType": "CPF",
"type": "PERSON"
},
"address": {
"name": "Collection Site",
"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
}
}
```
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.
After the first inline creation, you can use `participantId` and `addressId` for subsequent events referencing the same participant or address.
### 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 /v1/documents/{documentId}/events
{
"name": "YOUR_EVENT_NAME",
"externalCreatedAt": "2026-03-01T11:00:00.000Z",
"isPublic": true,
"participantId": "participant-id-from-previous-response",
"addressId": "address-id-from-previous-response",
"metadata": {
"attributes": [
{ "name": "YOUR_ATTRIBUTE_NAME", "value": "attribute-value" }
]
},
"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.
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.
**Inline `address` required fields:**
| Field | Type | Description |
| -------------- | ------ | -------------------------------------------- |
| `city` | string | City name |
| `countryCode` | string | Two-letter country code (ISO 3166-1 alpha-2) |
| `countryState` | string | State or province |
| `latitude` | number | Latitude coordinate |
| `longitude` | number | Longitude coordinate |
| `name` | string | Descriptive name for the address |
| `neighborhood` | string | Neighborhood or district |
| `number` | string | Street number |
| `street` | string | Street name |
| `zipCode` | string | Postal code (digits only, no formatting) |
### 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` events are accepted.
* **`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 /v1/documents/{documentId}/events
{
"name": "CLOSE",
"externalCreatedAt": "2026-03-02T16:00:00.000Z",
"isPublic": true,
"participantId": "integrator-participant-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 3: Attach evidence files (optional) [#step-3-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 4: Retrieve and validate final state [#step-4-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. This guarantees at-most-once semantics: if the server received your first request but
the response was lost, the retry will return the original result instead of creating a duplicate.
* 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).
* 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.
## 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` for idempotent retry behavior.
## 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 `sensible: true` (the API field name for sensitive-data masking) in the metadata so the platform can apply masking on public surfaces.
* See [Privacy & Masking](/docs/integrations/guides/privacy-and-masking) for visibility controls.
Related references:
* [Core Concepts](/docs/integrations/getting-started/core-concepts)
* [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. |
| `RELATED` | Creates relation links between documents. |
| `UPDATE` | Updates selected document visibility-related fields. |
| `SPLIT` | Creates a new document with part of existing value. |
| `OUTPUT` | Creates downstream document output from current context. |
| `CUSTOM` | Methodology/application-specific event names. |
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` / `SPLIT` / `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`
* one of `participant` or `participantId` (required)
* one of `address` or `addressId` (required)
* optional `attachments`
* optional `deduplicationId`
For methodology-driven integrations, `ACTOR` events must include a **label** that identifies the participant role. 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`.
## 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 per-integrator limits.
## Limits [#limits]
| Limit | Test | Production |
| -------------------- | ----- | ---------- |
| Requests per second | 5 | 10 |
| Events per document | 100 | 100 |
| Max file upload size | 10 MB | 10 MB |
## 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) must be classified using a three-level
hierarchy: **Category**, **Type**, and **Subtype**. 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. For example, under the
`MassID` category, types include:
* `Organic`
* `Plastic`
* `Paper`
* `Glass`
Each type helps identify the nature of the mass being tracked.
### Subtype [#subtype]
The subtype provides the most specific classification, refining the type with detailed information
about the material. For example:
* For type `Plastic`: `PET`, `HDPE`, `Plastic Film`
* For type `Organic`: `Food Waste`, `Garden Waste`, `Industrial Sludge`
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]
* The category, type, and subtype combination is required for every document.
* 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)
# 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** — Revenue from credit purchases is 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. Revenue from credit purchases is 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 Explorer](https://explore.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 — then distribute [rewards](/docs/protocol/rewards-distribution) to every participant in the supply chain.
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. Revenue from credit purchases is 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 Explorer](https://explore.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)
# 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 the broader blockchain ecosystem. 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 Explorer](/docs/protocol/explorer) 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 transferred, Rewards assigned |
| **Retirement** | Credits retired, Retirement receipt minted |
| **Rewards** | Rewards recorded, Credit note withdrawals |
| **Revocation** | Token revoked, Credits burned |
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 fully 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.
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 `upgradeTo` is called, only the implementation address stored inside the proxy changes — the ContractRegistry entry (which points to the proxy) does not need to be updated, and all dependent contracts continue operating without redeployment.
* **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.
[Learn about smart contracts](/docs/protocol/smart-contracts) · [Learn about contract categories](/docs/protocol/smart-contracts/contract-categories) · [View the Carrot Explorer](https://explore.carrot.eco)
# 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-chain, each certificate is soulbound (non-transferable) and held by the [Vault](/docs/protocol/smart-contracts); when it is minted, a matching amount of fungible credit tokens 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 minted:
| 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 recycling |
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` credit tokens; other recycling methodologies may issue different credit symbols.
### GasID [#gasid]
A GasID certificate quantifies the greenhouse gas **emission reductions** achieved by recycling waste instead of sending it to a landfill or dump. GasIDs are generated directly from MassIDs by a carbon methodology: the emission reductions are calculated by comparing the recycling scenario against the baseline scenario (what would have happened to the waste without recycling).
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` credit tokens (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 minted** — The `InventoryManager` smart contract mints 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 credit tokens are minted 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 minting, 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 on-chain 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 soulbound NFT (ERC-721).
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 soulbound NFT.
3. **[Credit](/docs/protocol/credits)** — A tradeable unit of verified environmental impact where 1 credit = 1 metric ton. Minted automatically when certificates are created, in a matching amount. Each methodology issues credits under its own on-chain 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 ERC-20 token — issued and transacted in any amount, including fractions.
4. **`CreditPurchaseReceipt`** — A soulbound NFT minted when credits are [purchased](/docs/protocol/credit-purchase). Provides immutable proof that the transaction occurred.
5. **`CreditRetirementReceipt`** — A soulbound NFT minted 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 | Token | Standard | Transferable? | What it proves |
| -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | -------------- | ----------------------------------------------------- |
| Tracking | MassID | ERC-721 | No (soulbound) | Physical waste was collected, sorted, and transported |
| Certification | [GasID](/docs/protocol/certificates#gasid) / [RecycledID](/docs/protocol/certificates#recycledid) | ERC-721 | No (soulbound) | Environmental impact was verified by dMRV |
| Credit minting | [TRC](/docs/protocol/credits#tokenized-recycling-credits-trc) / [TCC](/docs/protocol/credits#tokenized-carbon-credits-tcc) (e.g. `C-BIOW`, `C-CARB.CH4`) | ERC-20 | Yes (fungible) | 1 credit = 1 metric ton of verified impact |
| Purchase | `CreditPurchaseReceipt` | ERC-721 | No (soulbound) | Credits were purchased with USDC payment |
| Retirement | `CreditRetirementReceipt` | ERC-721 | No (soulbound) | Credits were permanently burned and claimed |
All tokens are deployed on-chain.
## Why soulbound? [#why-soulbound]
All NFTs in the Carrot Network are **soulbound** — they cannot be transferred between wallets. 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 soulbound NFTs are held by the Vault smart contract, which manages custody on behalf of the network.
Only credits (ERC-20 tokens) 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 minted proportionally to each certificate's verified quantity. The BOLD Recycling methodology issues TRCs with the on-chain symbol `C-BIOW`; other recycling methodologies may use different symbols. TRCs are material-specific — glass TRCs represent recycled glass, plastic TRCs represent recycled plastic.
### 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 minted proportionally to each GasID certificate's verified quantity. The BOLD Carbon (CH₄) methodology issues TCCs with the on-chain 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 Explorer](/docs/protocol/explorer) 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-chain. 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 on-chain flow:
| Step | Action | Description |
| ---- | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| 1 | **Purchase order signed** | The buyer (or an authorized operator) signs a purchase order using an EIP-712 typed data signature, authorizing the transaction with the credit type, amount, and payment details. |
| 2 | **Payment transferred** | USDC is transferred from the payer to the `RewardsVault` smart contract, 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 transferred** | Credit tokens (e.g. `C-BIOW`, `C-CARB.CH4`) are transferred from the Vault to the buyer's wallet. |
| 5 | **Receipt minted** | A `CreditPurchaseReceipt` NFT is minted as immutable, on-chain 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. |
All purchases and receipts are publicly verifiable through the [Carrot Explorer](/docs/protocol/explorer) or any blockchain block explorer (e.g. [PolygonScan](https://polygonscan.com/)).
## Certificate allocation [#certificate-allocation]
Every credit is backed by a [certificate](/docs/protocol/certificates) — 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 on a first-available basis, drawing from the oldest eligible certificates first.
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**. When the integrated retirement flag is enabled, credits are bought and immediately burned within the same on-chain operation. Both a `CreditPurchaseReceipt` and a `CreditRetirementReceipt` NFT are minted 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.
For buyers who prefer to hold credits and retire them later, standalone retirement is available as a separate transaction. 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** — including credit card and wire transfer — for buyers that prefer traditional payment flows. The platform handles the conversion so that the smart contracts always settle 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, smart contracts, and on-chain records into a six-step transaction: order signed, USDC transferred, certificate updated, credits transferred, receipt minted, 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 token is **burned** (destroyed on-chain) 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 blockchain and viewable through the [Carrot Explorer](/docs/protocol/explorer) or any blockchain block explorer (e.g. [PolygonScan](https://polygonscan.com/)).
## Two retirement paths [#two-retirement-paths]
The Carrot Network supports two methods for retiring credits:
### Standalone retirement [#standalone-retirement]
The credit holder retires credits from their own wallet at any time after purchase. This is useful for buyers that purchase credits in advance and retire them according to their own reporting schedules.
1. The holder signs a retirement transaction specifying the credit type and amount.
2. Credit tokens are **burned** from the holder's wallet balance.
3. The backing [certificate's](/docs/protocol/certificates) retirement amount is updated.
4. A **`CreditRetirementReceipt`** NFT (Non-Fungible Token) is minted as permanent proof.
5. The retirement is recorded on the blockchain.
### 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. The buyer signs a [purchase order](/docs/protocol/credit-purchase) with the integrated retirement flag enabled.
2. USDC payment is transferred to the `RewardsVault` for [rewards distribution](/docs/protocol/rewards-distribution).
3. Credit tokens are transferred from the [Vault](/docs/protocol/smart-contracts) to the buyer — and immediately burned.
4. Both a **`CreditPurchaseReceipt`** and a **`CreditRetirementReceipt`** NFT are minted in the same transaction.
5. The retirement is recorded on the blockchain.
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 soulbound NFT that serves as permanent, on-chain 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)
* **Retiring party** — The wallet address of the buyer that retired the credits
* **Timestamp** — The block 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 soulbound, it cannot be transferred or altered. It remains in the retiring party's wallet as a permanent credential.
## 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. Burned tokens cannot be recreated, and the on-chain retirement receipt provides unambiguous proof of who claimed the offset. 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 plastic TRCs to offset 50 metric tons of plastic packaging). 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 Explorer](https://explore.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-chain, credits are implemented as fungible ERC-20 tokens 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 **on-chain 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 token = 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 token = 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 on-chain 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 credit tokens are minted in a matching amount. The [BOLD Recycling](/docs/methodologies/bold-recycling) methodology issues TRCs with the on-chain 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 — glass TRCs represent recycled glass, plastic TRCs represent recycled plastic. This granularity allows credit buyers to target specific waste streams that match their product footprints.
### Tokenized Carbon Credits (TCC) [#tokenized-carbon-credits-tcc]
TCCs represent greenhouse gas emission reductions achieved through recycling. 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 recycling outcome to the baseline 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 on-chain 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 minting to retirement:
1. **Minted** — When a certificate is created by the `InventoryManager`, credit tokens are minted in a matching amount and deposited into the [Vault](/docs/protocol/smart-contracts) smart contract.
2. **Held** — Credits remain in the Vault as available inventory until purchased.
3. **Purchased** — When a buyer [purchases credits](/docs/protocol/credit-purchase), tokens are transferred from the Vault to the buyer's wallet. Payment (in USDC) is sent to the `RewardsVault` for distribution to participants. A `CreditPurchaseReceipt` NFT is minted as immutable proof of the transaction.
4. **Retired** — The buyer can permanently retire credits to claim the environmental offset. Retirement burns the tokens and mints a `CreditRetirementReceipt` NFT as proof. 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 token 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 digital asset for the digital MRV ([dMRV](/docs/protocol/dmrv)) process. On-chain, each MassID is [soulbound](/docs/protocol/credit-lifecycle) (non-transferable) and held by the [Vault](/docs/protocol/smart-contracts).
When any amount of post-consumer or post-industrial waste is identified, measured, and custody is established between two parties, a MassID is created on-chain. 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/) (InterPlanetary File System), creating an immutable, publicly verifiable record of 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** | B | 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 (local collection and long-distance transport) and two processors (local accumulation center and the glass bottling plant).
Every participant in the chain of custody is identified by their wallet address and is eligible for a share of the rewards when [credits](/docs/protocol/credits) are issued from the MassID.
## 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.
## Proof-of-Work and Provenance [#proof-of-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, shipment, 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 trackable digital asset 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](/docs/protocol/certificates), it enters the [on-chain minting process](/docs/protocol/on-chain-minting) — where its metadata is stored on IPFS and the MassID is minted on-chain.
[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.
# On-Chain Minting
## From verified data to on-chain assets [#from-verified-data-to-on-chain-assets]
After a [MassID](/docs/protocol/mass-ids) passes [methodology verification](/docs/protocol/methodology-execution), it is minted — transformed from an off-chain verified record into an immutable on-chain asset. Minting creates a permanent, publicly verifiable link between the physical recycling work and its digital representation on-chain.
On-chain minting 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 minting process [#the-minting-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 minting.
### 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 wallet address and role |
| **Timestamps** | When each event in the chain of custody occurred |
| **Methodology** | Which methodology rules were applied and the version used for verification |
| **Verification references** | Links to the verification records that confirmed material validity |
This metadata becomes the permanent, immutable description of the MassID once it is stored on-chain.
### 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 token, linking the lightweight blockchain record to the full metadata stored in decentralized storage.
### 4. On-chain minting [#4-on-chain-minting]
The MassID NFT is minted on-chain. The token is a soulbound ERC-721 NFT — non-transferable and permanently held by the [Vault](/docs/protocol/smart-contracts) contract. The minting transaction records the IPFS metadata URI on-chain, creating an immutable association between the token and its provenance data.
Because MassIDs are soulbound, they cannot be traded or transferred between wallets. 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 off-chain verified MassID with its on-chain token ID. This linkage ensures that the platform, the blockchain, and the [Carrot Explorer](/docs/protocol/explorer) 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 critical guarantees for minted MassIDs:
* **Immutability** — The content-addressed URI is derived from the metadata itself. If anyone altered the metadata after upload, the URI would change, immediately revealing the tampering. This ensures that the provenance record attached to a MassID cannot be modified after minting.
* **Persistence** — Because IPFS is a distributed network, metadata is not dependent on any single server or organization. The data remains accessible as long as at least one node is actively pinning it, reducing the risk of data loss.
Together, these properties ensure that the metadata backing every minted MassID is permanent, verifiable, and resistant to tampering — a critical requirement for environmental credits that must withstand regulatory scrutiny.
## What happens next [#what-happens-next]
Minted MassIDs are the foundation upon which the rest of the credit lifecycle is built. Once a MassID exists on-chain:
* **Certificates are generated** — When MassIDs pass methodology verification at a facility accredited by independent third-party auditors, [certificates](/docs/protocol/certificates) (RecycledID or GasID) are minted, referencing the underlying minted MassIDs as proof of the physical work performed.
* **Credits are created** — Each certificate generates fungible [credit tokens](/docs/protocol/credits) (TRC or TCC), representing 1 metric ton of verified environmental impact. These credits are the tradeable assets 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 minted 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 Explorer](/docs/protocol/explorer) 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 minting 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.
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 mint fungible credit tokens (TCC and TRC). Each methodology issues credits under its own on-chain 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** — On-chain activities — from minting through [credit retirement](/docs/protocol/credit-retirement) — are viewable through the [Carrot Explorer](/docs/protocol/explorer) or any [blockchain block explorer](/docs/glossary#blockchain-block-explorer). Auditors, credit buyers, regulators, or anyone else can verify on-chain data independently.
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, shipments, 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 a machine-learning layer that continuously monitors dMRV data, detecting anomalies and suspicious patterns in supply chain data. When irregularities are identified, the system flags events for additional review or blocks credit issuance until issues are resolved. 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-chain. 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 minting consume that evidence on the verification layer. A single bridge edge marks the transition from collected evidence to verified credit.
# Explorer
## What is the Carrot Explorer? [#what-is-the-carrot-explorer]
The Carrot Explorer ([explore.carrot.eco](https://explore.carrot.eco)) is the public interface of Carrot's verification platform. It presents public, immutable, and auditable data in a user-friendly way — making the Carrot Network's environmental claims independently verifiable without relying on technical tools or raw blockchain interfaces.
## Main sections [#main-sections]
The Explorer 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 token supply is also available in the Explorer.
Not everything in the Explorer is stored on the blockchain. Only certain data is written on-chain — for example, minted [MassIDs](/docs/protocol/mass-ids), [Certificates](/docs/protocol/certificates), [credit](/docs/protocol/credits) tokens, 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 Explorer 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.
On-chain records — minted MassIDs, Certificates, credits, purchase and retirement receipts — are backed by blockchain transactions and presented in the Explorer with environmental context, so anyone can trace a retired credit back through its certificate to the underlying MassIDs and the physical work they represent.
## 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 Explorer 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 Explorer** | 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 Explorer 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)
# 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 on-chain credits.
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 Explorer](/docs/protocol/explorer) ([explore.carrot.eco](https://explore.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, drop-offs, and shipments — material type, weight, and the participants involved |
| **Facility audits** | Third-party verification of facility operations, accreditation status, and material throughput |
| **Environmental outcomes** | Recycling and biological treatment confirmations, including certified quantities and processing methods |
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. Examples from current frameworks:
* **MassID document submission** — When a Network Integrator submits a MassID document with supply chain events, the platform routes it to the applicable methodology and runs the framework's MassID validation rules. 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)).
* **Credit order processing** — When a credit order document is processed, the methodology's credit-order rules (such as rewards distribution) execute.
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 Explorer.
### 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 Explorer, so execution progress and outcomes are available in real time.
### 3. Finalize [#3-finalize]
After all rules complete, 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. Final results are recorded on-chain immutably and reflected in the Carrot Explorer.
## 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 100% of the applicable framework criteria through code-based validation. If any required criterion fails, the MassID is not eligible for certificate issuance or credit generation until the issue is corrected under the applicable framework.
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 Explorer, 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
* [On-Chain Minting](/docs/protocol/on-chain-minting) — How verified MassIDs become on-chain assets
* [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 rewards for sorting quality, 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 portion of the rewards generated when MassIDs they helped track reach a certified Recycler and are converted into [Tokenized Recycling Credits (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc) or [Tokenized Carbon Credits (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc). 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, and the more material reaches certified recycling, 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)
# Rewards Distribution
## How rewards work [#how-rewards-work]
When [a quantity of credits is purchased](/docs/protocol/credit-purchase), the revenue is distributed back to 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), and the Carrot Network itself are all rewarded for their verified contributions.
Rewards are paid in [USDC](/docs/glossary#usdc) (a stablecoin pegged to the US dollar), giving participants **stable value** without exposure to cryptocurrency price volatility. Participants can withdraw their rewards in **fiat or crypto** 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 weight [#step-1-split-by-weight]
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 revenue is split across those MassIDs proportional to each MassID's weight in the allocation. A MassID representing 10 kg in a 1,000 kg (1 ton) allocation receives 1% of the total revenue for that purchase.
### 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 |
| **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) |
| **Carrot Network** | N | Provides the protocol and smart contract infrastructure for verification, issuance, record-keeping, and rewards distribution |
The total percentages across all categories always equal 100% of the MassID's value. The first four categories (G through R) are the [supply chain participants](/docs/protocol/supply-chain) who physically handle waste. The remaining categories (I, A, D, N) are ecosystem participants who 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 — including the Community Impact Pool — 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 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.
When the Waste Generator is not identified:
* **100% of the Waste Generator's share** is redirected to the **Community Impact Pool** — a collective fund for socio-environmental projects in the territory where the recycling took place.
* **All other logistics and service participants** (Haulers, Processors, Recyclers) 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 Impact Pool.
The Community Impact Pool supports environmental, social, and innovation projects aligned with circular economy principles. Over time, the Pool will evolve toward progressive community participation in its governance.
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 — all participants receive 100% of their allocated rewards. This is the economic incentive driving the network toward full supply chain transparency.
## Claiming rewards [#claiming-rewards]
Participants claim earned rewards through a **privacy-preserving on-chain mechanism**. During each credit purchase, a Merkle root is recorded on-chain representing the complete rewards distribution for that transaction. This root commits to the full distribution without revealing any individual amounts or identities publicly.
Participant identities are **anonymized on-chain**. No participant identifiers are stored publicly — each participant is represented by a purchase-scoped hash, preventing cross-purchase correlation by external observers. An observer can verify that a distribution is valid but cannot determine which real-world participant corresponds to any given entry.
When claiming, participants can receive payouts in fiat or crypto as described above. Each claim is verified against the on-chain 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. This prevents the platform from unilaterally moving funds.
Neither party can claim rewards unilaterally. The backend cannot redirect rewards to a different wallet without the participant's signature, and the participant cannot claim without passing identity verification. This design ensures:
* **Privacy** — No participant identifiers are stored on-chain; only purchase-scoped hashes appear in the Merkle tree.
* **Verifiability** — Every claim is checked against the committed Merkle root, guaranteeing distribution correctness.
* **Security** — Dual signatures prevent both unauthorized claims and unilateral fund movement.
## 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 and location to optimize recycling performance for specific markets.
For example, the Foundation could increase the Waste Generator's share in a municipality launching a new source sorting program to drive participation, or adjust the Hauler's share in regions where transport costs are a 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]
Six role categories define who does what in the recycling supply chain:
| Role | Responsibility | Reward eligibility |
| ---------------------- | --------------------------------------------------------------- | ------------------------------------------------------- |
| **Waste Generator** | Produces waste and performs source sorting | Yes — rewarded for sorting quality |
| **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 and processing (dual role) |
| **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 always receives credit for two roles: Processor (receiving and sorting) and Recycler (performing certified recycling or biological treatment).
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 **Carrot Network** itself (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.
## 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. A shipment event covers both pick-up and drop-off, with 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 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 tokenization into [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.
* **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 revenue 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 decentralized 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 participant chain from waste generator to bin custodian, hauler, processor, and recycler, with the Network Integrator connected beneath the grouped participants. The takeaway is that operational evidence comes from several handoffs, while the integrator coordinates the chain as a network-facing role rather than another processing step.
# 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)** (tokenized 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** | Tokenized certificate representing verified impact | TRC (e.g. `C-BIOW` from BOLD Recycling), TCC (e.g. `C-CARB.CH4` from BOLD Carbon (CH₄)) |
## 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 minted from Certificates and [rewards](/docs/protocol/rewards-distribution) are distributed 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.
* Rules that pass generate an audit trail explaining what was verified.
* MassIDs that pass methodology verification generate [Certificates](/docs/protocol/certificates), and matching [Credits](/docs/protocol/credits) are minted.
* [Rewards](/docs/protocol/rewards-distribution) are distributed to [supply chain](/docs/protocol/supply-chain) participants according to the methodology's distribution policy.
## 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 deterministic PASSED or FAILED results with explanations.
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 or failed.
Each rule is a deterministic function: given the same input document and the same rule version, 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 PASSED or FAILED result is linked to the specific source data that was evaluated, making results independently verifiable.
* **Determinism** — Same input always produces the same output. No randomness, no external state that could change results between runs.
* **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 or FAILED 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 or FAILED.
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 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 condition with clear criteria |
| **Formulas** | Defines emission calculations, credit quantification, and reward distribution 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) or FAILED (with the specific reason).
4. When all rules pass, MassIDs that pass methodology verification generate [Certificates](/docs/protocol/certificates), and matching [credits](/docs/protocol/credits) are minted.
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**: Accredited [waste generators](/docs/protocol/supply-chain), [haulers](/docs/protocol/supply-chain), [processors](/docs/protocol/supply-chain), and [recyclers](/docs/protocol/supply-chain#the-role-of-the-recycler) with valid documentation
* **Validation rules**: Rules covering document validation, actor identification, weighing, geolocation, manifests, accreditation, and integrity checks
* **Formulas**: Credit quantification based on verified composted mass; reward distribution percentages by actor type
* **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 the number of [Tokenized Carbon Credits (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc) and [Tokenized Recycling Credits (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc) that can be generated from organic waste composting. Select a baseline scenario, waste type, and volume to see projected credit amounts and an illustrative revenue breakdown.
## 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 revenue is 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 or FAILED with an explanation.
The explanation in `evaluateResult()` is critical — it must state what was verified and why the result is PASSED or FAILED. 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 PASSED or FAILED result 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
* 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 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
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 (TCC or TRC) linked, 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 Explorer](/docs/protocol/explorer) 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
## 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 organic waste is claimed for both a recycling credit and a carbon credit based on the same biological treatment activity, the environmental impact would be counted twice — undermining the integrity of the entire credit system.
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 Explorer](/docs/protocol/explorer) and on the blockchain.
## 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 revenue from [Tokenized Recycling Credit (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc) and [Tokenized Carbon Credit (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc) **purchases** is distributed among participants. Buyers purchase 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). Revenue is split across the underlying MassIDs proportional to each MassID's weight in the allocation, 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.
**Current version:** v1.0 (Ratified January 22, 2024)
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.
## Payment currency and withdrawal [#payment-currency-and-withdrawal]
Rewards are paid in [USDC](/docs/glossary#usdc) (a stablecoin pegged to the US dollar). Participants can withdraw their rewards in **fiat or crypto** — fiat payouts are fulfilled off-chain via integrated payment providers, while crypto withdrawals use the on-chain USDC balance. Using USDC as the settlement currency gives participants **stable value** without exposure to cryptocurrency price volatility, keeps protocol settlement consistent on-chain, and allows participants to choose how they receive value (fiat or crypto) 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 |
| 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) |
| CP | Community Impact Pool | Fund for socio-environmental projects in the local territory |
| 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) |
| N | Carrot Network | Provides the protocol and smart contract infrastructure for verification, issuance, record-keeping, and rewards distribution |
## 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%), H (10%), P (10%), R (20%), I (8%), A (1%), D (1%), N (20%)
**Composting of sludge from waste treatment plants:**
G (25%), H (5%), P (10%), R (30%), I (8%), A (1%), D (1%), N (20%)
**Composting of tobacco industry residues:**
G (25%), H (5%), P (10%), R (30%), I (8%), A (1%), D (1%), N (20%)
G (20%), H (20%), P (15%), R (15%), I (8%), A (1%), D (1%), N (20%)
G (20%), H (20%), P (15%), R (15%), I (8%), A (1%), D (1%), N (20%)
G (25%), H (10%), P (20%), R (15%), I (8%), A (1%), D (1%), N (20%)
G (25%), H (15%), P (15%), R (15%), I (8%), A (1%), D (1%), N (20%)
Use the [Credit Calculator](/docs/standard/guides/credit-calculator) to see an illustrative
revenue breakdown for a given waste type and volume.
## Reward discounts [#reward-discounts]
### Supply chain digitization incentive [#supply-chain-digitization-incentive]
A standard **25% discount** is applied to all logistics and service providers (Recyclers, Processors, Haulers) when the [Waste Generator](/docs/protocol/supply-chain) is not identified in the chain of custody. 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 Waste Generator rewards applies in two scenarios:
1. **Waste Generators without completed onboarding** — Waste Generators that have not yet completed the onboarding process will receive a 50% discount on rewards for all credits issued before the onboarding completion date. Once onboarding is completed, only credits issued from that date onward are eligible for full reward allocation; credits issued prior to the onboarding completion date remain subject to the 50% discount. This discount ensures uniform application of the policy while formalization and registration verification remain pending, and it functions as an incentive mechanism to drive onboarding completion. In practical terms, the rule reinforces the principle that full reward redistribution depends on minimum eligibility and traceability conditions within the network, ensuring transparency, governance, and predictability for all ecosystem stakeholders.
2. **Large Businesses** — Waste Generators classified as Large Businesses (revenue exceeding USD 4 million in the prior calendar year) receive 50% of their allocated rewards after onboarding. This calibrates incentives proportionally while preserving participation motivation.
### Community Impact Pool [#community-impact-pool]
Discounted amounts from both scenarios above are directed to the **Community Impact Pool** — a collective fund for socio-environmental projects in the territory where the recycling took place. The Pool supports environmental, social, and innovation projects aligned with circular economy principles. Over time, the Pool will evolve toward progressive community participation in its governance.
[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.
* **Meritocracy** — The best proposal wins, regardless of who submits it.
* **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 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, [Certificate](/docs/protocol/certificates) NFTs, and [Credit](/docs/protocol/credits) tokens in a single coordinated operation. 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
* Mints a `CreditPurchaseReceipt` as permanent proof
* Records reward allocations for participants
The CreditPurchaseManager also supports **integrated retirement** — purchasing and retiring credits in one transaction, which avoids the need for a separate retirement step.
### 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 immutable and traceable. 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 and individual reward details private — only hashed commitments are stored publicly. 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. This ensures an immutable, tamper-proof audit trail. No NFT can be moved, sold, or hidden after minting.
### 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 MassIDs 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 from the other three). This accounting model is central to preventing double-counting — the contract enforces that credits cannot be sold or retired beyond the available balance.
### CreditPurchaseReceipt [#creditpurchasereceipt]
Immutable 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 Explorer](/docs/protocol/explorer) 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 Explorer](/docs/protocol/explorer) 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 is key to the upgradeability model — when a contract is upgraded to a new implementation, only the registry entry needs to change. All dependent contracts automatically discover the new address without redeployment.
### 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 to the specific waste batches it represents through this registry. 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. One or more MassIDs back each certificate.
* **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 batches 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 blockchain [#why-blockchain]
The Carrot Network records every [environmental credit](/docs/protocol/credits) on a public blockchain to guarantee three properties that traditional databases cannot:
* **Immutability** — Once a credit is minted, its provenance data cannot be altered or deleted. Every issuance, purchase, and retirement is permanently recorded on-chain, while protocol-level contract logic (single-use checks, token burning 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 Explorer](/docs/protocol/explorer) 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** — Tokenized assets and every credit lifecycle event (minting, purchase, retirement) exist on-chain. Together with platform data in the [Carrot Explorer](/docs/protocol/explorer), 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 minting, 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 and stored data remain the same — only the logic changes. 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: when a contract is upgraded to a new implementation, only the registry entry needs to change. All other contracts automatically discover the new version through the registry, without any redeployment of their own. This means individual contracts can be improved, patched, or extended without requiring 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. Every [MassID](/docs/protocol/mass-ids), [certificate](/docs/protocol/certificates), purchase receipt, and retirement receipt remains exactly where it was created, forming an unbreakable chain of evidence.
### Meta-transactions [#meta-transactions]
The system supports **gas-less transactions** through meta-transaction relayers. This means end users do not need to hold cryptocurrency or pay blockchain transaction fees — the relayer submits transactions on their behalf, removing a significant barrier to adoption for non-crypto-native buyers.
### Role-based access control [#role-based-access-control]
Every contract implements **RBAC** with defined roles for day-to-day operations, upgrades, and emergency actions. No single account can perform all operations. This separation of duties ensures that even if one key is compromised, the damage is contained.
### Pausability [#pausability]
Critical operations can be paused in emergencies to halt all activity while a vulnerability or incident is investigated. Emergency pauses **auto-expire after 48 hours** to prevent indefinite lockouts — ensuring the network cannot be permanently frozen, even in worst-case scenarios. See [Security](/docs/protocol/smart-contracts/security) for the full access control and pausability model.
## 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. Each flow is designed to be **atomic** — either every step completes successfully or none of them do, preventing partial state changes.
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 Explorer](/docs/protocol/explorer) with environmental context and traceability data.
## Minting [#minting]
When verified data is ready for minting, the **InventoryManager** creates the foundational on-chain assets in a coordinated operation.
### 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 transfer [#step-4--credit-transfer]
Credit tokens (e.g. `C-BIOW`, `C-CARB.CH4`) are transferred from the Vault to the buyer's wallet address. At this point, the buyer holds fungible credit tokens that they can hold or retire.
### Step 5 — Receipt minting [#step-5--receipt-minting]
A **`CreditPurchaseReceipt`** NFT is minted to the Vault as permanent, immutable 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]
If the buyer opts for **integrated retirement**, the credits are burned (instead of transferred to the buyer) in the same transaction, and a `CreditRetirementReceipt` is also minted. This allows buyers to purchase and retire credits in a single step — useful for those who intend to immediately claim the environmental offset.
## 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 are anonymized — 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 holder's balance. 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 Explorer, 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 triggers a **cascading** revocation:
* All certificates linked to the revoked MassID are automatically revoked.
* Any unsold credits backed by those certificates are burned.
* **Protection**: Revocation is blocked if any credits from the linked certificates have already been sold. This prevents retroactively invalidating credits that buyers have already purchased in good faith.
### 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]
Revocation preserves the complete audit trail. The original IPFS metadata for revoked assets remains accessible, and the revocation reason is recorded on-chain. This ensures that even revoked assets can be examined by auditors and regulators — nothing is hidden or deleted, only marked as invalid.
## 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]
Each contract function is restricted to specific authorized roles. No single account can perform all operations. 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. Emergency pauses auto-expire after 48 hours to prevent indefinite lockouts, ensuring that even a compromised emergency account cannot permanently freeze the system.
The admin, operator, upgrader, and pauser roles are held by **multi-signature wallets** — meaning multiple authorized parties must approve any action before it executes. The emergency pauser is the exception: it is a single externally-owned account to enable rapid response when seconds matter.
### 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`, automatically expire after 48 hours — providing a safety net that balances rapid incident response with protection against permanent denial of service.
### 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** — Tracks participant behavior across the network, surfacing patterns that indicate bad actors. Sensitive operations can be gated by reputation thresholds, ensuring that only trusted participants access them.
* **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 and can include suspension of credit minting participation, wallet freezing, or account restrictions.
## 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** or **FAILED** 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 across three scopes: MassID validation, [GasID certificate](/docs/protocol/certificates#gasid) issuance, and [credit](/docs/protocol/credits) order settlement.
All rules are licensed under LGPL-3.0: [github.com/carrot-foundation/methodology-rules](https://github.com/carrot-foundation/methodology-rules)
[View on Carrot Explorer](https://explore.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.
## GasID rules [#gasid-rules]
These rules execute after all MassID rules pass and the [GasID certificate](/docs/protocol/certificates#gasid) is issued.
## Credit Order rules [#credit-order-rules]
These rules execute when [credit](/docs/protocol/credits) order documents are processed.
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.
> 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 or FAILED 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).
* All participants ([Waste Generator](/docs/protocol/supply-chain), [Hauler](/docs/protocol/supply-chain), [Processor](/docs/protocol/supply-chain), [Recycler](/docs/protocol/supply-chain#the-role-of-the-recycler)) have valid [accreditation](/docs/protocol/network-integrators) documents.
* 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 (with accreditation)
* 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. GasID rules run (rewards distribution for [supply chain](/docs/protocol/supply-chain) participants).
3. [C-CARB.CH4](/docs/protocol/credits#tokenized-carbon-credits-tcc) (Tokenized Carbon Credits ([TCC](/docs/protocol/credits#tokenized-carbon-credits-tcc))) credit tokens are generated upon credit order settlement.
## 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** or **FAILED** 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 across three scopes: MassID validation, [RecycledID certificate](/docs/protocol/certificates#recycledid) issuance, and [credit](/docs/protocol/credits) order settlement.
All rules are licensed under LGPL-3.0: [github.com/carrot-foundation/methodology-rules](https://github.com/carrot-foundation/methodology-rules)
[View on Carrot Explorer](https://explore.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.
## RecycledID rules [#recycledid-rules]
These rules execute after all MassID rules pass and the [RecycledID certificate](/docs/protocol/certificates#recycledid) is issued.
## Credit Order rules [#credit-order-rules]
These rules execute when [credit](/docs/protocol/credits) order documents are processed.
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.
> 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 or FAILED 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).
* All participants ([Waste Generator](/docs/protocol/supply-chain), [Hauler](/docs/protocol/supply-chain), [Processor](/docs/protocol/supply-chain), [Recycler](/docs/protocol/supply-chain#the-role-of-the-recycler)) have valid [accreditation](/docs/protocol/network-integrators) documents.
## 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. Each must have a valid accreditation document
(rule 4 — Participant Accreditations & Verifications).
| Participant | Required? | Conditions |
| --------------- | ----------- | ----------------------------------------------------------------------------- |
| Integrator | Yes | Must have valid accreditation with valid dates. |
| 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). |
Each ACTOR event must include the participant's accreditation data and address (used by rule 7 — Geolocation Precision, which validates event addresses against accredited addresses using tiered distance thresholds).
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. RecycledID rules run (rewards distribution for [supply chain](/docs/protocol/supply-chain) participants).
3. [C-BIOW](/docs/protocol/credits#tokenized-recycling-credits-trc) credit tokens (Tokenized Recycling Credits) are generated upon credit order settlement.
## 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** — All participants must have valid, non-expired accreditation documents at the time of event submission.
* **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 é o Ecossistema Carrot? [#o-que-é-o-ecossistema-carrot]
O [Ecossistema Carrot](/docs/network) é uma camada de governança para os protocolos ambientais da Carrot — incluindo créditos de carbono e de reciclagem — utilizando contratos inteligentes para tomada de decisão transparente e rastreável, bem como compartilhamento das receitas da rede. Abrange um [standard](/docs/standard), um [registry](/docs/registry) público de créditos e infraestrutura de Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)) para verificação de terceiros. Saiba mais na [visão geral](/docs/network).
### Como a reciclagem é verificada no Ecossistema Carrot? [#como-a-reciclagem-é-verificada-no-ecossistema-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 as receitas de compra de créditos? [#para-onde-vão-as-receitas-de-compra-de-créditos]
A receita de compra de créditos é distribuída 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 TRCs e TCCs? [#o-que-são-trcs-e-tccs]
[Créditos Tokenizados de Reciclagem (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc) representam 1 tonelada métrica de material reciclado certificado. [Créditos Tokenizados de Carbono (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc) representam 1 tonelada métrica de reduções de emissões de CO₂ equivalente por meio do desvio de resíduos. Ambos são tokens fungíveis ERC-20 respaldados por [certificados](/docs/protocol/certificates) verificados.
### 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 on-chain. Indivíduos podem adquirir impacto ambiental pela [Loja Carrot](https://store.carrot.eco) (store.carrot.eco), que oferece produtos baseados em intenção que resultam em créditos aposentados. Organizações utilizam interfaces fornecidas pela Carrot que aceitam diversos métodos de pagamento (ex.: Pix, cartão de crédito/débito, USDC); a plataforma executa a transação on-chain e os créditos são entregues na carteira do comprador. Créditos adquiridos podem ser [aposentados](/docs/protocol/credit-retirement) como prova permanente e on-chain de ação ambiental, verificável na blockchain pública (ex.: por meio de qualquer explorador de blockchain) ou pelo [Carrot Explorer](/docs/protocol/explorer) (explore.carrot.eco). 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á volume mínimo. É possível comprar qualquer quantidade diretamente na [Loja Carrot](https://store.carrot.eco). Para acordos de volume enterprise ou compromissos mínimos anuais (AMC), entre em contato com nossa equipe comercial.
### Quanto custa um crédito? [#quanto-custa-um-crédito]
O [Crédito Tokenizado de Carbono (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc) tem preço de US$ 50,00 por tonelada métrica de CO₂ equivalente.
O [Crédito Tokenizado de Reciclagem (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc) tem preço base de US$ 103,53 por tonelada — composto pelo valor das reduções de emissões de carbono mais os co-benefícios sociais e ambientais da reciclagem verificada. Para compras em volume, os co-benefícios podem ser negociados com a equipe comercial.
### Quais formas de pagamento são aceitas? [#quais-formas-de-pagamento-são-aceitas]
Pix, cartão de crédito/débito e USDC.
### Preciso ter uma carteira de criptomoedas para comprar? [#preciso-ter-uma-carteira-de-criptomoedas-para-comprar]
Não. O [MyCarrot](/docs/for-buyers/how-to-buy#gerencie-seu-impacto-com-o-mycarrot) é um portal com interface intuitiva, sem necessidade de conhecimento em blockchain. 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 em [my.carrot.eco](https://my.carrot.eco).
### 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 on-chain com trilha de auditoria completa, compatível com GHG Protocol, CDP, GRI 305 e ISO 14064-3. Veja [Evidências de Impacto](/docs/for-buyers/impact-evidence) 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 ao Ecossistema 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.
## Metodologias [#metodologias]
### O que é BOLD? [#o-que-é-bold]
BOLD (Breakthrough in Organics Landfill Diversion) é a família de [metodologias](/docs/methodologies) no Ecossistema 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 a prevenção de metano proveniente da compostagem.
### 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 do Ecossistema 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).
**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 tokens de crédito de circulação. Quando um comprador aposenta créditos, os tokens são queimados e um NFT `CreditRetirementReceipt` é mintado como prova imutá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 o Ecossistema Carrot. Veja [Verificação de Terceiros](/docs/protocol/third-party-verification).
## B [#b]
**BOLD** — Breakthrough in Organics Landfill Diversion. Uma família de metodologias no Ecossistema Carrot para verificar o desvio de resíduos orgânicos. O Carrot fornece a infraestrutura; frameworks e aplicações de metodologia são desenvolvidos por terceiros. Veja [BOLD Recycling](/docs/methodologies/bold-recycling) e [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon).
## C [#c]
**C-BIOW** — O símbolo de token ERC-20 para [Créditos de Reciclagem Tokenizados (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc) emitidos pela metodologia [BOLD Recycling](/docs/methodologies/bold-recycling). 1 token = 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 token ERC-20 para [Créditos de Carbono Tokenizados (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc) emitidos pela metodologia [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) (reduções de metano por compostagem). 1 token = 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. Uma camada baseada em ML que monitora continuamente os dados de dMRV, detectando anomalias e padrões suspeitos nos dados da cadeia de suprimentos e metodologias. Veja [Ecossistema de Metodologias](/docs/standard/concepts/ecosystem#platform-intelligence-layers).
**Carrot dMRV Standard** — Os cinco princípios fundamentais que toda metodologia no Ecossistema Carrot deve seguir: integridade & rastreabilidade, adicionalidade & verificabilidade, padronização & comparabilidade, interoperabilidade & automação, e transparência & auditabilidade. Veja [Carrot dMRV Standard](/docs/standard).
**Carrot Explorer** — A [interface pública](/docs/protocol/explorer) da plataforma de verificação do Carrot em [explore.carrot.eco](https://explore.carrot.eco). Fornece uma visão transparente e amigável de dados ambientais e trilhas de auditoria — tanto dados on-chain (MassIDs, certificados, créditos, registros de aposentadoria) quanto dados da plataforma (definições de metodologia, execução de regras, homologações). Dados on-chain também são verificáveis por qualquer pessoa via qualquer [explorador de blockchain](#blockchain-block-explorer), sem depender da infraestrutura do Carrot. A função de registry do Ecossistema Carrot é descrita como "registry público de créditos" (em minúsculas); "Carrot Explorer" refere-se especificamente à interface.
**Carrot Foundation** — Uma fundação na Suíça que constrói o Ecossistema Carrot. Missão: acelerar a transição para uma economia circular eficiente em recursos, de baixo carbono e inclusiva.
**Carrot Store** — Uma experiência de consumo em [store.carrot.eco](https://store.carrot.eco) para a compra de impacto ambiental. Oferece produtos baseados em intenção (ex.: Para mim, Para minha família) 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#scientific-basis) 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#supported-waste-codes).
**Certificado** — Um NFT soulbound representando um único MassID que passou pela 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-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.
**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.
**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 [Para Compradores](/docs/for-buyers).
**Crédito** — Um token ERC-20 fungível representando 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 on-chain.
**Custodiante de Ponto de Coleta** — Um participante da cadeia de suprimentos (B) que gerencia contêineres de coleta ou pontos de entrega onde Geradores de Resíduos depositam materiais recicláveis. Veja [cadeia de suprimentos](/docs/protocol/supply-chain).
## D [#d]
**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.
**Ecossistema Carrot (Carrot Network)** — Uma camada de governança para os protocolos ambientais da Carrot, utilizando contratos inteligentes para tomada de decisão transparente e rastreável, bem como compartilhamento das receitas da rede. Abrange um [standard](/docs/standard), 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).
**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 do Ecossistema 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 Explorer, 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.
**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).
**Fundo de Impacto Comunitário** — Um fundo coletivo para projetos socioambientais no território onde a reciclagem ocorreu. Recebe valores descontados de recompensas em cenários como onboarding incompleto ou classificação de Grande Empresa. Com o tempo, o Fundo evoluirá para participação comunitária progressiva em sua governança. Veja [Política de Distribuição de Recompensas](/docs/standard/policies/rewards-distribution).
## 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. Sob o [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon), GasIDs geram tokens de crédito `C-CARB.CH4` no minting; 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 presente, todos os participantes recebem [recompensas](/docs/protocol/rewards-distribution) integrais; quando ausente, pagamentos com desconto se aplicam. Veja [cadeia de suprimentos](/docs/protocol/supply-chain).
**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#the-role-of-the-recycler), [Integrador](/docs/protocol/network-integrators) ou outro participante atende aos padrões do Ecossistema 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#supported-waste-codes).
**Integrador** — Uma aplicação ou plataforma de software de terceiros que conecta operações reais ao Ecossistema 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 ativo digital único (NFT soulbound) criado quando um resíduo é identificado e medido. Registra tipo de material, peso e cadeia de custódia. A fundação do sistema de verificação do Ecossistema 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 detalhes completos da distribuição on-chain.
**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).
**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 no ecossistema 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 Explorer](/docs/protocol/explorer). 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 no Ecossistema 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 do Ecossistema 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#the-role-of-the-recycler).
**Recicle e Ganhe** — O modelo de incentivo no qual cada participante verificado da [cadeia de suprimentos](/docs/protocol/supply-chain) recebe uma parcela da receita de venda de [créditos](/docs/protocol/credits) pelo seu papel no processo de reciclagem. A receita das compras de créditos é [distribuída](/docs/protocol/rewards-distribution) com base no papel de cada participante e no peso dos resíduos que manusearam.
**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.
**Registry (papel da Carrot)** — A Carrot emite, rastreia e aposenta créditos ambientais em um ledger público de blockchain. A blockchain fornece registros públicos, permanentes e verificáveis de forma independente. Distinto 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).
**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 do Ecossistema Carrot, como minting de ativos, distribuição de recompensas, compras de créditos e aposentadoria de créditos. Veja [Smart Contracts](/docs/protocol/smart-contracts).
**Soulbound** — Uma propriedade de NFTs que significa que não podem ser transferidos entre carteiras. Todos os NFTs do Ecossistema Carrot são soulbound, garantindo que a trilha de auditoria seja 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 `Orgânico`, subtipos incluem `Resíduos Alimentares`, `Resíduos de Jardim`, `Lodo Industrial`. 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 representando 1 tonelada métrica de reduções de emissões de CO₂-equivalente por meio do desvio de resíduos. O símbolo on-chain `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 Explorer](/docs/protocol/explorer).
**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 Explorer](/docs/protocol/explorer).
**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 representando 1 tonelada métrica de material reciclado certificado. O símbolo on-chain `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 stablecoin atrelada ao dólar americano, usada no Ecossistema Carrot para compras de créditos e [distribuição de recompensas](/docs/protocol/rewards-distribution). Fornece aos participantes valor estável sem a volatilidade de preços de criptomoedas.
## 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 detém todos os NFTs soulbound (MassIDs, certificados, recibos) e inventário de tokens de crédito 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 o ecossistema 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 tokens em uma blockchain pública. Cada crédito carrega um registro imutável que vincula o evento físico que o originou — uma massa verificada de material coletado, triado ou processado — passando pelas etapas de verificação e emissão até sua eventual aposentadoria de créditos.
Esse registro é permanente e publicamente acessível. Qualquer pessoa pode rastrear o histórico completo de um crédito de forma independente, sem depender da Carrot ou de qualquer outro intermediário para fornecer os dados.
## 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:
* **Tokenização** — Certificados RecycledID e GasID lastreiam tokens de crédito fungíveis, como TRCs e TCCs.
* **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 queima a quantidade reivindicada e cria um recibo permanente para a reivindicação ambiental.
* **Fluxos de carteira e custódia** — Carteiras interagem com saldos de crédito, recibos e fluxos de liquidação, enquanto evidências soulbound 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 blockchain? [#por-que-blockchain]
Três propriedades da infraestrutura blockchain 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) distribuem automaticamente os valores da venda de créditos para os participantes da [cadeia de suprimentos](/docs/protocol/supply-chain) com base em suas contribuições verificadas. Isso elimina a intermediação manual na distribuição de receitas.
## 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 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 — do minting à 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
* [Minting On-Chain](/docs/protocol/on-chain-minting) — como a verificação física se torna um crédito on-chain
* [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
# Fale com Nossa Equipe
Estamos prontos para apoiar seu processo — desde a primeira avaliação até o onboarding completo.
## Por onde começar [#por-onde-começar]
**Quero entender melhor os créditos e o processo**
Agende uma conversa com nossa equipe de negócios. Podemos apresentar como os créditos se encaixam no seu programa de sustentabilidade e responder perguntas técnicas específicas.
**Estou pronto para avançar comercialmente**
Entre em contato direto para discutir volume, condições e próximos passos para um acordo enterprise ou AMC.
**Quero avaliar a integração técnica**
Nossa equipe técnica pode fornecer acesso sandbox, documentação de API e suporte para avaliação de integração com seus sistemas internos.
**Quero me tornar parceiro intermediário**
Fale com nosso time de parcerias sobre o modelo de distribuição e estrutura comercial.
> [contact@carrot.eco](mailto:contact@carrot.eco)
> [carrot.eco/pt-BR/contact](https://carrot.eco/pt-BR/contact)
Para acesso a materiais de due diligence — trilhas de auditoria de amostra, documentação de metodologia, white paper — solicite diretamente à nossa equipe.
# Como Comprar
Desde a compra avulsa até acordos de volume enterprise — o processo adaptado ao seu perfil.
## Compra direta (ESG corporativo e mid-market) — Em desenvolvimento [#compra-direta-esg-corporativo-e-mid-market--em-desenvolvimento]
Para empresas que querem começar com um volume menor ou explorar os créditos antes de um acordo de longo prazo:
1. Acesse a Carrot Store em [store.carrot.eco](https://store.carrot.eco)
2. Escolha o tipo de crédito (TCC ou TRC) e o volume em toneladas
3. Conclua a compra via Pix, cartão de crédito ou USDC
4. Receba o certificado de aposentadoria com trilha pública
5. Acesse o **MyCarrot** em [my.carrot.eco](https://my.carrot.eco) — sua plataforma de gestão de impacto. Acompanhe o histórico completo de compras, certificados emitidos e impacto acumulado em um painel exclusivo com interface intuitiva e sem necessidade de conhecimento em blockchain.
[Acessar MyCarrot](https://my.carrot.eco)
{/* 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. */}
## Preços [#preços]
| Crédito | Descrição | Preço |
| ------- | -------------------------------------------------------------------------------------------------- | ----------------------------- |
| **TCC** | Tokenized Carbon Credit — reduções de emissões de GHG | US$ 50,00 / tonelada métrica |
| **TRC** | Tokenized Recycling Credit — material reciclado certificado com co-benefícios sociais e ambientais | US$ 103,53 / tonelada métrica |
Para compras em volume enterprise, os co-benefícios do TRC podem ser negociados com nossa equipe comercial.
## Compra em volume (Enterprise) [#compra-em-volume-enterprise]
Para organizações com metas anuais de compensação, programas estruturados de sustentabilidade ou necessidade de integração com sistemas internos de reporte:
**Advance Market Commitment (AMC)**
A Carrot oferece estrutura de AMC para grandes compradores — um compromisso de compra antecipado que garante volume de créditos, estabelece condições comerciais e apoia o financiamento de nova capacidade de reciclagem na cadeia.
**O processo enterprise inclui:**
* **Avaliação de necessidades** — Mapeamos juntos metas de compensação, padrões de reporte e volume anual estimado.
* **Proposta comercial** — Condições de preço, volume e prazo adequados ao seu programa de sustentabilidade.
* **Due diligence técnica** — Acesso a documentação completa de metodologia, trilhas de auditoria de amostra e suporte da equipe técnica para avaliação interna.
* **Contrato e onboarding** — Integração com seus sistemas de reporte e fluxo de emissão de certificados.
## Parceiros e intermediários [#parceiros-e-intermediários]
Se você quer incorporar créditos Carrot no seu produto ou serviço — oferecendo compensação de carbono para seus clientes finais — temos uma estrutura de parceria dedicada.
**Casos de uso típicos:**
* Plataformas de viagem oferecendo compensação por emissões de voo ou hospedagem
* E-commerces com opção de entrega carbono-neutro
* Serviços financeiros com produtos de investimento ESG
O modelo de parceiro inclui acesso à API, certificados e estrutura de receita compartilhada com toda a cadeia.
[Fale com nossa equipe para iniciar uma conversa de parceria](/docs/for-buyers/contact)
## Gerencie seu impacto com o MyCarrot [#gerencie-seu-impacto-com-o-mycarrot]
Cada compra fica registrada no MyCarrot — uma plataforma exclusiva criada para você acompanhar sua jornada de impacto ambiental. No MyCarrot você acessa:
* Histórico completo de créditos comprados e aposentados
* Certificados de aposentadoria com trilha de auditoria completa
* Trilha de auditoria de cada crédito, vinculada ao [Carrot Explorer](/docs/protocol/explorer)
* Impacto acumulado em toneladas de CO₂ e material reciclado
A interface é totalmente acessível — sem configurações técnicas.
[Acessar MyCarrot](https://my.carrot.eco)
**Ainda avaliando?**
Nossa equipe pode fornecer amostras de trilha de auditoria, documentação de metodologia e referências de compradores existentes para suportar seu processo de due diligence.
[Fale com nossa equipe](/docs/for-buyers/contact)
# Evidências de Impacto
Cada compra gera um conjunto de evidências auditáveis — projetadas para suportar relatórios ESG, auditorias externas e divulgações públicas.
## Certificado de aposentadoria [#certificado-de-aposentadoria]
Ao aposentar créditos, sua empresa recebe um certificado on-chain com:
* Identificador único do crédito aposentado
* Data e hora da aposentadoria (timestamp imutável)
* Volume em toneladas métricas de CO₂ equivalente (ou material reciclado)
* Tipo de crédito e metodologia aplicada
* Link para trilha de auditoria pública — rastreável até o evento físico de origem
O certificado é permanente e verificável por qualquer terceiro via [Carrot Explorer](/docs/protocol/explorer).
## Trilha de auditoria pública [#trilha-de-auditoria-pública]
Cada crédito de reciclagem ou de carbono tem uma cadeia de evidências públicas e rastreáveis. Um auditor externo pode verificar:
1. O evento físico que originou o crédito (tipo de material, peso, instalação, data)
2. A verificação por Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)) aplicada (quais regras foram executadas, quais passaram)
3. O [certificado](/docs/protocol/certificates) emitido (GasID ou RecycledID)
4. O crédito mintado e seu histórico de transferência
5. A aposentadoria com identificação do beneficiário
## Compatibilidade com padrões de reporte [#compatibilidade-com-padrões-de-reporte]
| Padrão | Como os créditos Carrot se aplicam |
| ---------------------------------- | ----------------------------------------------------------------------------------------- |
| **GHG Protocol (Scope 3)** | Créditos TCC aposentados como compensação de emissões de categoria relevante |
| **CDP Climate Disclosure** | Evidência de ação em compensação com rastreabilidade verificável |
| **GRI 305** | Créditos aposentados como offset documentado no inventário de emissões |
| **ISO 14064-3** | Trilha de auditoria compatível com verificação por terceiros |
| **EPR / Conformidade regulatória** | TRC como evidência de reciclagem para programas de Responsabilidade Estendida do Produtor |
[Fale com nossa equipe](/docs/for-buyers/contact) — podemos mapear como os créditos Carrot se
encaixam na sua estrutura específica.
## Para equipes técnicas e de auditoria [#para-equipes-técnicas-e-de-auditoria]
Todos os dados de evidência são acessíveis via:
* **[Carrot Explorer](/docs/protocol/explorer)** — Interface pública para verificação manual
* **[API pública](/docs/integrations/api)** — Para integração com sistemas de gestão ESG ou plataformas de reporte
* **Exportação de dados** — Disponível para auditorias e processos de due diligence
[Ver Referência da API](/docs/integrations/api) | [Fale com nossa equipe](/docs/for-buyers/contact)
# Para Compradores
A Carrot oferece [créditos ambientais](/docs/protocol/credits) — incluindo créditos de reciclagem e de carbono — respaldados por eventos reais de reciclagem, verificados digitalmente por Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)), registrados em blockchain pública e auditáveis do evento físico à aposentadoria. Cada crédito vem com uma [trilha de auditoria](/docs/for-buyers/impact-evidence) completa e um [certificado de aposentadoria](/docs/protocol/credit-retirement) compatível com os principais padrões de relatório ESG.
Se você quer entender o ecossistema completo por trás de cada crédito, veja [Papéis no Ecossistema
de Créditos](/docs/protocol/credit-ecosystem-roles).
Cada crédito é verificado com dados em nível de evento (não estimativas), auditável por qualquer terceiro via [Carrot Explorer](/docs/protocol/explorer) e respaldado por lógica de verificação open source.
[Veja as evidências que você recebe](/docs/for-buyers/impact-evidence) | [Saiba como os créditos são gerados](/docs/for-buyers/traceable-credits)
## Qual é o seu perfil? [#qual-é-o-seu-perfil]
### Grandes Empresas [#grandes-empresas]
Você representa uma organização com metas globais de carbono, programas de sustentabilidade estruturados e necessidade de evidências auditáveis para relatórios públicos.
* Metas anuais de compensação alinhadas com GHG Protocol, CDP ou ISO 14064-3
* Necessidade de integração com sistemas internos de reporte
* Necessidade de materiais de due diligence e suporte para avaliação técnica
[Ver jornada enterprise](/docs/for-buyers/how-to-buy#compra-em-volume-enterprise)
### ESG Corporativo [#esg-corporativo]
Você precisa compensar emissões ou comprovar conformidade com normas ESG, e quer um processo simples com documentação clara.
* Busca créditos verificados com preços transparentes
* Quer certificados de aposentadoria compatíveis com padrões de divulgação ESG
* Prefere um fluxo de compra self-service sem necessidade de conhecimento em blockchain
[Ver como comprar créditos](/docs/for-buyers/how-to-buy)
### Parceiros e Intermediários [#parceiros-e-intermediários]
Você quer oferecer compensação de carbono ou reciclagem como parte do seu produto ou serviço — para seus clientes finais.
* Plataformas de viagem, e-commerce ou financeiras integrando compensação ao produto
* Necessidade de acesso à API para compras automatizadas e emissão de certificados
* Estrutura de receita compartilhada com toda a cadeia produtiva
[Ver como se tornar parceiro](/docs/for-buyers/how-to-buy#parceiros-e-intermediários)
# Créditos Ambientais Rastreáveis
Cada crédito Carrot é lastreado em um evento físico real — verificado digitalmente, registrado de forma imutável e auditável por qualquer pessoa.
## Como um crédito Carrot é gerado [#como-um-crédito-carrot-é-gerado]
O processo começa no mundo físico: um lote de resíduos é coletado, pesado e identificado na origem. Esse evento gera um [MassID](/docs/protocol/mass-ids) — um registro digital imutável que captura tipo de material, peso e cadeia de custódia.
O MassID acompanha o material ao longo de toda a cadeia de reciclagem. Quando chega a uma instalação credenciada e passa pela [verificação de metodologia](/docs/protocol/methodology-execution), gera um [certificado](/docs/protocol/certificates) verificado e um crédito ambiental correspondente — incluindo créditos de carbono e de reciclagem — um ativo tokenizado, fungível e negociável.
Evento físico → [MassID](/docs/protocol/mass-ids) (registro imutável) → Verificação por MRV
digital ([dMRV](/docs/protocol/dmrv)) → [Certificado](/docs/protocol/certificates) (GasID /
RecycledID) → [Crédito](/docs/protocol/credits) (TCC / TRC) → Aposentadoria com trilha pública
## O que isso significa para sua empresa [#o-que-isso-significa-para-sua-empresa]
**Trilha de auditoria completa**
Qualquer auditor pode percorrer a cadeia de evidências — do recibo de aposentadoria até o evento físico que originou o crédito. A trilha é pública, permanente e acessível via [Carrot Explorer](/docs/protocol/explorer) ou qualquer [explorador de blockchain](/docs/glossary#blockchain-block-explorer).
**Dados do evento, não estimativas**
A verificação é baseada em dados coletados diretamente do evento de reciclagem — não em projeções, modelos estatísticos ou inferências. Cada reivindicação tem evidência física correspondente.
**Impacto social distribuído**
Mais de 70% da receita de cada crédito vai diretamente para os [participantes da cadeia](/docs/protocol/supply-chain) — de geradores e transportadores a processadores e [recicladores](/docs/protocol/supply-chain#the-role-of-the-recycler). Sua compra financia diretamente mais capacidade de reciclagem.
**Código aberto e auditável**
O código de verificação ([MvA](/docs/standard/concepts/mva)) que executa as regras de metodologia é de código aberto (LGPL-3.0). Qualquer equipe técnica pode auditar a lógica de verificação antes de uma decisão de compra.
## Tipos de créditos disponíveis [#tipos-de-créditos-disponíveis]
{/* 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. */}
**[TCC](/docs/protocol/credits#tokenized-carbon-credits-tcc)** — Tokenized Carbon Credit
Reduções de emissões de GHG (ex: metano desviado de aterro via compostagem). Emitido sob a metodologia [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon). Alinhado com UNFCCC CDM, [EPA WARM](https://www.epa.gov/warm) e [GHG Protocol](https://ghgprotocol.org/). US$ 50,00 por tonelada métrica de CO₂ equivalente.
**[TRC](/docs/protocol/credits#tokenized-recycling-credits-trc)** — Tokenized Recycling Credit
Material reciclado certificado, processado em instalação credenciada. Emitido sob a metodologia [BOLD Recycling](/docs/methodologies/bold-recycling). US$ 103,53 por tonelada métrica.
[Saiba mais sobre metodologias](/docs/methodologies) | [Ver evidências de impacto que você recebe](/docs/for-buyers/impact-evidence)
# Visão Geral das Integrações
Integrações conectam sua plataforma ao [Ecossistema 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. 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. Criar um documento (`POST /documents`).
3. Adicionar eventos à linha do tempo (`POST /documents/{documentId}/events`), ou enviar múltiplos eventos de uma vez (`POST /documents/events`).
4. Fazer upload de arquivos opcionais por meio de URLs de anexo pré-assinadas.
5. 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 o Ecossistema 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`.
* **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).
# 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), explore.carrot.eco, store.carrot.eco, docs.carrot.eco, my.carrot.eco e whitepaper.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/legal/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/legal/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/legal/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/legal/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/legal/privacy-policy](/docs/legal/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 contêineres, 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/legal/token-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 ou $Carrot) 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 Fundo Comunitário da Carrot, 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 ou removidas, certificados e créditos (de reciclagem, carbono e outros) emitidos e aposentados — no website da Carrot, canais de mídia social, whitepapers 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 o [White Paper da Carrot](https://whitepaper.carrot.eco/), os Websites disponíveis em [www.carrot.eco](http://www.carrot.eco), docs.carrot.eco e [www.explore.carrot.eco](http://www.explore.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 o White Paper, 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.
O Código de Conduta atual está descrito no [White Paper da Carrot](https://whitepaper.carrot.eco/) na seção de Governança e subseções de [Valores da Comunidade](https://whitepaper.carrot.eco/) e [Diretrizes da Comunidade](https://whitepaper.carrot.eco/).
## 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 Fundo Comunitário da Carrot 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 Contêineres, 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/legal/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, white paper, 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/legal/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/legal/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.
# Termos e Condições para Vendas e Compras de Tokens
{/* cspell:words Fndn Tokenizados stablecoins */}
**Versão 1.0 — 29 de março de 2024**
## Preâmbulos [#preâmbulos]
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" ("Foundation")**), desenvolveu e implantou a rede baseada em blockchain da Carrot (**"Rede" ("Network")**) que permite o registro off-chain e on-chain de ações de economia circular realizadas por fornecedores de matérias-primas, embaladores, envasadores, produtores, geradores de resíduos, custodiantes de contêineres, transportadores, processadores, recicladores, compradores de matérias-primas, integradores de rede, autores de metodologias, desenvolvedores de metodologias, auditores, ONGs, entre outros (**"Usuários" ("Users")**). As ações de economia circular são registradas off-chain pelos Integradores de Rede da Carrot (**"INTs"**) antes de serem submetidas e registradas na Rede via APIs. Recursos de resíduos (**"MassIDs"**) e/ou produtos (**"ProductIDs"**) são codificados como identificadores únicos que podem registrar a cadeia de custódia de materiais e/ou produtos e, consequentemente, a responsabilidade sobre eles. As ações de economia circular registradas e rastreadas por meio de MassIDs e ProductIDs servem como base para a verificação de atividades do mundo real e certificação de contribuições ambientais, bem como para a emissão de Créditos de Reciclagem Tokenizados (**"TRC"**) não fungíveis, assim como Créditos de Carbono Tokenizados (**"TCC"**) não fungíveis pela Fundação (**"Projeto" ("Project")**), os quais, quando adquiridos, distribuem recompensas em tokens aos contribuintes ambientais registrados na cadeia de custódia. TRCs e TCCs aposentados podem ser utilizados para reportar as reivindicações ambientais e sociais que foram realizadas por meio das ações de economia circular (**"Reivindicações Ambientais e Sociais" ("Environmental & Social Claims")**).
A Fundação gera os TRC e TCC (**"Tokens"**), conforme descrito abaixo, e os oferece para venda a você e a outros indivíduos e entidades (**"Compradores" ("Buyers")**) em uma venda pública contínua (**"Venda de Tokens" ("Token Sale")**) sob os seguintes termos e condições (**"Termos de Compra de Tokens" ("Token Purchase Terms")**).
Ao aceitar estes Termos de Compra de Tokens e transferir o Valor de Compra conforme definido abaixo, você, como comprador, celebra um contrato de venda de tokens juridicamente vinculante com a Fundação. Como comprador, você é responsável por cumprir as leis e regulamentos aplicáveis, em particular, mas não se limitando a, os regulamentos que regem o recebimento, a posse e a venda de Tokens.
Estes Termos de Compra de Tokens estão sujeitos aos [Termos e Condições](/docs/legal/terms-and-conditions) gerais da Fundação.
## 1. Compra e Alocação de Tokens [#1-compra-e-alocação-de-tokens]
Ao participar da Venda de Tokens, o Comprador adquire Tokens da Fundação, e a Fundação vende Tokens ao Comprador.
Sujeito à aceitação destes Termos e à transferência do valor de compra conforme indicado no processo de compra (Termos de Compra de Tokens e a aprovação bem-sucedida no processo de KYC da Fundação), a Fundação compromete-se a alocar ao Comprador os Tokens correspondentes e entregar os referidos Tokens dentro de 180 dias após o recebimento dos valores, ou até uma data mutuamente acordada determinada em contrato separado.
O Comprador pode transferir o valor de compra para a Fundação de duas maneiras.
### 1.1 Compra Direta [#11-compra-direta]
O Comprador pode realizar uma compra direta do token não fungível ("NFT") (ou seja, TRCs ou TCCs) utilizando USDC ou outro token stablecoin. A compra entrega o NFT ao Comprador e distribui uma parte das stablecoins utilizadas como recompensas a cada Participante registrado na cadeia de custódia. Serviços de terceiros podem ser utilizados para facilitar essa transação, incluindo o uso de cartões de crédito e outros serviços financeiros.
### 1.2 Transferência de Fundos [#12-transferência-de-fundos]
O Comprador pode transferir os fundos por transferência bancária para a conta bancária da Fundação ou enviando stablecoins (por exemplo, USDC) para sua carteira digital. Dada a complexidade adicional desse processo, taxas adicionais podem ser cobradas e a data de entrega pode ser significativamente atrasada, razão pela qual um prazo mais longo para entrega é solicitado e será negociado com os Compradores de tokens.
## 2. Descrição Técnica do Token [#2-descrição-técnica-do-token]
Os Tokens (TRC e TCC) são unidades de informação digital únicas baseadas em blockchain, construídas utilizando o padrão de Token Não Fungível ERC-721, que têm suas transações registradas na blockchain Ethereum. Os TRCs estão associados a MassIDs únicos que contêm o tipo e o peso da massa do material, juntamente com as ações de economia circular correspondentes e sua cadeia de custódia. Os TCCs representam as emissões de gases de efeito estufa medidas, verificadas e reportadas que foram reduzidas, capturadas ou removidas a partir de um conjunto único de MassIDs. As informações de economia circular contidas nos Tokens dependem do Token específico, mas compreendem pelo menos as informações mencionadas na Seção 2.1.
### 2.1 Funcionalidade dos Tokens [#21-funcionalidade-dos-tokens]
Os Tokens possuem as seguintes funções:
### 2.2 Função de Evidência [#22-função-de-evidência]
Os TRCs correspondem a um ou mais MassIDs únicos que servem como evidência de que uma determinada quantidade de toneladas métricas de um determinado tipo de resíduo em uma área específica chegou a um centro de reciclagem ou reutilização adequado e/ou foi reciclado ou reutilizado (por exemplo, 1 tonelada métrica de alumínio foi reciclada no estado de São Paulo, Brasil); ou
Os TCCs correspondem a um ou mais MassIDs únicos que servem como evidência de que uma determinada quantidade de toneladas métricas de emissões equivalentes de CO2 foram reduzidas, capturadas ou removidas por meio de reciclagem, reutilização ou outras atividades verificáveis em um local específico (por exemplo, 1 tonelada métrica de CO2e foi reduzida no estado de São Paulo, Brasil, devido à compostagem de resíduos orgânicos quando comparado à linha de base de envio de resíduos para um aterro sanitário).
### Função de Aposentadoria [#função-de-aposentadoria]
Os detentores de Tokens podem aposentar seus Tokens mediante o pagamento da taxa de aposentadoria, conforme descrito na Seção 2.4. A Aposentadoria torna os Tokens intransferíveis, estabelecendo propriedade permanente sobre o Token e as Reivindicações Ambientais e Sociais subjacentes realizadas por meio do processo de medição, reporte e verificação, conforme determinado por uma metodologia aprovada pela Rede Carrot (**"Metodologias" ("Methodologies")**).
A Fundação permanece livre para alterar o nome, símbolo e coleção de futuros Tokens emitidos a qualquer momento e a seu exclusivo critério.
### 2.3 Sem Resgate; Sem Direitos de Propriedade, Receita ou Participação [#23-sem-resgate-sem-direitos-de-propriedade-receita-ou-participação]
Os Tokens não conferem qualquer reivindicação (parcial ou total) de resgate. Em particular, os detentores de TRCs e TCCs não recebem nada em troca da aposentadoria de seus Tokens além da reivindicação de sua propriedade sobre o Token em si e o que ele representa.
Os Tokens não são projetados para serem utilizados como meio de pagamento.
Os Tokens não representam nem constituem quaisquer direitos de propriedade, participações, ações, valores mobiliários ou direitos equivalentes, nem quaisquer direitos de receber receitas futuras, ações ou qualquer outra forma de participação ou direitos de governança em ou relacionados à Rede e/ou à Fundação. Os Tokens não criam nem conferem quaisquer obrigações contratuais ou de outra natureza exigíveis contra qualquer parte, incluindo os demais Usuários, a Fundação, bem como seus funcionários, prestadores de serviço e/ou fundadores.
O Comprador não possui direito de licença nem direito a quaisquer direitos de propriedade intelectual, direitos equivalentes ou qualquer outra forma de participação em ou relacionada à Rede e/ou à Fundação.
### 2.4 Aposentadoria [#24-aposentadoria]
Uma taxa de aposentadoria de Token pode ser cobrada quando um Proprietário de Token aposenta, ou queima, o TRC ou TCC por conta própria para propriedade permanente (**"Direct-Burn"**). A taxa de Direct-Burn está embutida no Token.
Uma taxa de aposentadoria Burn-As-A-Service (**"BAAS"**) pode ser cobrada de forma única quando um Comprador de Token necessita de assistência na compra e aposentadoria de TRCs ou TCCs específicos, como de MassIDs de um local específico. A taxa de BAAS pode estar embutida no Token ou ser cobrada separadamente, e pode ser alterada a qualquer momento para garantir que serviços adequados sejam prestados.
Taxas de armazenamento de dados no registro (**"Registry Storage"**) podem ser cobradas após a aposentadoria do Token para cobrir custos de armazenamento de dados em um banco de dados público.
Serviços adicionais de registro (**"Registry Services"**) podem ser oferecidos pela Carrot Fndn e contratados pelo proprietário dos Tokens aposentados.
## 3. Conheça Seu Cliente/Empresa ("KYC") [#3-conheça-seu-clienteempresa-kyc]
Os Compradores 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 da carteira para a qual as Recompensas serão enviadas, endereço residencial, documento comprovante de endereço residencial, nacionalidades, documento de identidade governamental para cada nacionalidade e documentos comprovantes do documento de identidade governamental, incluindo prova de posse, como uma foto da pessoa segurando o documento de identidade.
No caso de uma empresa, o representante legal deve, além de fornecer as informações de identificação individual, fornecer documentos comprovantes de representação legal, e-mail corporativo, razão social da empresa, CNPJ da empresa e documento comprovante do CNPJ, bem como qualquer outra informação que possa ser razoavelmente solicitada de tempos em tempos pela Fundação, a fim de completar a verificação da Fundação (**"KYC-Check"**). Usuários e INTs devem fornecer informações verdadeiras, precisas, atuais e completas e devem atualizar prontamente a Fundação eletronicamente com quaisquer alterações de dados.
As verificações de Conheça Seu Cliente e Conheça Sua Empresa podem ser realizadas pela própria Rede Carrot ou por terceiros em nome da Rede Carrot.
## 4. Tributação [#4-tributação]
Todos os tributos (incluindo IVA, se aplicável), encargos, taxas, contribuições e outras obrigações de qualquer natureza impostas sobre o recebimento ou importação de Tokens pelo Comprador serão de responsabilidade e por conta do Comprador.
## 5. Taxas de Terceiros [#5-taxas-de-terceiros]
Quaisquer taxas de terceiros, incluindo taxas de transação, não relacionadas especificamente à aquisição de um determinado Token, não são de responsabilidade da Carrot Fndn e são de total responsabilidade do Comprador de tokens, incluindo, mas não se limitando a, a compra de stablecoins a serem utilizadas para a compra de Tokens, on-ramping e off-ramping, taxas de KYC e AML, taxas de gerenciamento de carteira, taxas de gas, taxas de câmbio relacionadas a swaps de Tokens, taxas de smart contracts de wrapping, taxas de pool de liquidez, etc.
## 6. Riscos [#6-riscos]
O Comprador compreende e aceita os riscos relacionados aos Tokens. Em particular, mas não de forma exaustiva, o Comprador compreende os riscos inerentes listados a seguir. Ao aceitar estes Termos, o Comprador expressamente reconhece e assume estes riscos.
### 6.1 Risco de Fragilidades de Software [#61-risco-de-fragilidades-de-software]
O Comprador compreende e aceita que a Rede e a infraestrutura subjacente são tecnologias jovens, razão pela qual não há garantia de que o processo de recebimento, uso e posse de Tokens será ininterrupto ou livre de erros. O Comprador compreende e aceita ainda que existe um risco inerente de que a Rede e as tecnologias subjacentes contenham fragilidades, vulnerabilidades ou bugs, causando, entre outras coisas, a perda total dos Tokens.
O Comprador compreende e aceita particularmente que a Rede é, desde sua implantação, imutável e que, consequentemente, pode ser difícil ou impossível corrigir erros registrados ou sanar fragilidades de software.
### 6.2 Risco Regulatório [#62-risco-regulatório]
O Comprador compreende e aceita que a tecnologia blockchain permite novas formas de interação. Existe a possibilidade de que certas jurisdições apliquem regulamentos existentes ou introduzam novos regulamentos que abordem aplicações baseadas em tecnologia blockchain de forma que possa ser contrária à configuração atual e que possa, entre outras coisas, resultar em modificações substanciais na Rede, incluindo o encerramento do Projeto e a perda dos Tokens ou de sua funcionalidade para o Comprador.
O Comprador compreende e aceita que, mesmo que os Tokens não criem nem confiram quaisquer obrigações contratuais ou de outra natureza contra qualquer parte (incluindo a Fundação, bem como seus funcionários, prestadores de serviço e/ou fundadores), certos reguladores podem, não obstante, qualificar os Tokens como valores mobiliários ou outros instrumentos financeiros nos termos da legislação aplicável. Permanece sendo responsabilidade do Comprador cumprir quaisquer leis e regulamentos aplicáveis ao Comprador ao deter ou transferir os Tokens.
O Comprador compreende e aceita que nenhuma autoridade de valores mobiliários ou outra autoridade regulatória expressou opinião sobre o status dos Tokens, e que constitui crime, nos termos das leis de algumas jurisdições, afirmar o contrário;
O Comprador compreende e aceita que as transações contempladas nestes Termos não foram revisadas, aprovadas ou submetidas a qualquer agência reguladora ou organização autorreguladora. Como resultado, o Comprador não terá o conjunto completo de proteções oferecidas aos clientes e consumidores de tais entidades nos termos de quaisquer leis aplicáveis, e
O Comprador compreende e aceita que, se os Tokens forem considerados valores mobiliários em uma ou mais jurisdições, ou se estes Termos ou a emissão dos Tokens constituírem um contrato a termo não isento, ou se a Fundação ou suas afiliadas forem obrigadas a se registrar junto a uma agência reguladora, os Tokens e a Fundação poderão estar sujeitos a regulamentação adicional significativa, incluindo restrições à transferibilidade e revenda ou atividade operacional. Isso poderia levar a mudanças significativas com relação aos Tokens, como os Tokens são estruturados, como são comprados e vendidos e outras questões, e aumentaria significativamente os custos da Fundação na criação e facilitação de transações em Tokens. Tal regulamentação poderia levar à perda de funcionalidade dos Tokens e/ou à depreciação parcial ou total de seu valor, sujeitar a Fundação e suas afiliadas, diretores e executivos a potenciais penalidades, incluindo penalidades civis e criminais federais, ou tornar os Tokens ilegais ou impossíveis de usar, comprar ou vender nos Estados Unidos e em outras jurisdições. Além disso, um regulador poderia tomar medidas contra a Fundação ou suas afiliadas se considerar os Tokens como uma oferta não registrada de valores mobiliários ou as operações da Fundação como uma violação da legislação vigente. Qualquer um desses resultados afetaria negativamente o valor e a funcionalidade dos Tokens e/ou poderia fazer com que a Fundação cessasse suas operações.
### 6.3 Risco de Abandono / Falta de Sucesso [#63-risco-de-abandono--falta-de-sucesso]
O Comprador compreende e aceita que o desenvolvimento futuro do Projeto pode ser abandonado por diversos motivos, incluindo, mas não se limitando a, falta de interesse do público, falta de financiamento, incapacitação de desenvolvedores-chave e membros do projeto, força maior (incluindo pandemias) ou falta de sucesso ou perspectivas comerciais. O Comprador, portanto, compreende que não há garantias de que o Comprador será capaz de aposentar seus Tokens.
### 6.4 Risco de Perda de Chave Privada [#64-risco-de-perda-de-chave-privada]
Os Tokens alocados a um endereço específico só podem ser acessados com a chave privada associada a esse endereço. O Comprador compreende e aceita que, se seu arquivo de chave privada ou senha da carteira forem perdidos ou roubados, os Tokens alocados associados ao endereço ou senha do Comprador seriam irrecuperáveis e permanentemente perdidos. A Fundação não tem controle sobre os Tokens; portanto, o Comprador não terá recurso para buscar quaisquer reembolsos, recuperações ou substituições junto à Fundação no caso de os Tokens serem perdidos ou roubados.
### 6.5 Risco de Roubo [#65-risco-de-roubo]
O Comprador compreende e aceita que a Rede e/ou a infraestrutura subjacente, outros softwares envolvidos, outros componentes tecnológicos e/ou plataformas podem ser expostos a ataques de hackers ou outros indivíduos que possam resultar no roubo ou na perda dos Tokens.
### 6.6 Risco de Ataques à Rede e Forks [#66-risco-de-ataques-à-rede-e-forks]
O Comprador compreende e aceita que, assim como outros tokens baseados em blockchain, a Rede e/ou a infraestrutura subjacente podem ser suscetíveis a ataques relacionados ao consenso, incluindo, mas não se limitando a, ataques de gasto duplo, ataques de maioria de poder de validação, ataques de censura e comportamento bizantino no algoritmo de consenso, ou estar sujeitas a forks. Qualquer ataque ou fork bem-sucedido representa um risco para a Rede, a execução e sequenciamento esperados de transações de Tokens, a execução e sequenciamento esperados de computações de contratos, bem como os saldos de tokens na carteira do Comprador.
### 6.7 Limitação de Responsabilidade [#67-limitação-de-responsabilidade]
**POR FAVOR, LEIA ESTA SEÇÃO COM ATENÇÃO. ESTAS DISPOSIÇÕES LIMITAM O ESCOPO DA RESPONSABILIDADE DA FUNDAÇÃO EM RELAÇÃO ÀS TRANSAÇÕES CONTEMPLADAS POR ESTES TERMOS.**
As Partes limitam a responsabilidade de ambas as Partes sob estes Termos, a qualquer título, a danos causados por fraude, conduta dolosa ou negligência grave. Na máxima extensão permitida por qualquer lei aplicável, em nenhuma hipótese a responsabilidade agregada do Comprador ou da Fundação excederá, conforme o caso, o valor do Preço de Compra.
O Comprador reconhece e concorda que, na máxima extensão permitida por qualquer lei aplicável e sujeito ao parágrafo 25, a Fundação ou qualquer de seus funcionários, prestadores de serviço e/ou fundadores não são responsáveis, e o Comprador concorda em não responsabilizá-los, por quaisquer e todos os danos (incluindo danos diretos, indiretos, incidentais e/ou consequenciais, perda de lucros, fundo de comércio ou dados), implicações regulatórias, tributárias ou outra responsabilidade ou prejuízo de qualquer natureza causados por ou relacionados ao uso, ou à incapacidade de usar a Rede, a alocação, propriedade ou uso de Tokens ou em conexão com estes Termos ou qualquer transação contemplada nestes Termos sob qualquer causa de ação de qualquer natureza em qualquer jurisdição.
A Fundação não fornece garantias ou promessas quanto à disponibilidade, confiabilidade, precisão ou qualidade dos Tokens. Os Tokens são fornecidos "como estão", sem quaisquer garantias expressas ou implícitas de qualquer natureza.
## 7. Declarações e Garantias Gerais do Comprador [#7-declarações-e-garantias-gerais-do-comprador]
O Comprador declara e garante à Fundação o seguinte e reconhece que a Fundação está se baseando nestas declarações e garantias:
a) O Comprador está devidamente organizado, validamente existente e em situação regular nos termos das leis do país em que está constituído e possui todo o poder e autoridade necessários para executar, emitir e entregar este Contrato, e para cumprir e desempenhar suas obrigações sob este Contrato e quaisquer contratos relacionados;
b) O Comprador não está listado, nem está associado a qualquer pessoa ou entidade listada, em qualquer uma das listas de Pessoas ou Entidades Negadas 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 da UE 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 o Comprador nem qualquer de suas afiliadas, diretores ou administradores é residente de um país ou território que tenha sido designado como não cooperativo com os 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;
c) O Comprador confirma não ser residente, cidadão ou estar localizado em uma área geográfica sujeita a sanções ou embargos da ONU, EUA, UE, Suíça ou de qualquer outro país soberano;
d) O Comprador não está domiciliado nem organizado nos termos das leis de qualquer país cuja legislação conflite com a presente alocação dos Tokens e/ou com o propósito da Fundação em geral;
e) O Comprador compreende e concorda que não está autorizado a vender, doar, penhorar ou transferir de qualquer outra forma os Tokens a pessoas conforme definidas nas alíneas b) a d) acima;
f) Quaisquer fundos utilizados para a transferência do Preço de Compra são: (a) bons, limpos, desembaraçados e de origem não criminosa; (b) completamente livres e desembaraçados de quaisquer ônus ou gravames de qualquer natureza ou de quaisquer direitos de interesses de terceiros; e (c) não possuem origens que possam estar conectadas a qualquer violação de regulamentos de combate à lavagem de dinheiro, conforme definido na jurisdição de origem, ou internacionalmente;
g) O Comprador compreende que pode não existir um mercado público para os Tokens, e que a Fundação não garantiu que um mercado público existirá para os Tokens;
h) O Comprador possui tal conhecimento e experiência em assuntos financeiros e empresariais que é capaz de avaliar os méritos e riscos de participar da Venda de Tokens, respectivamente, de tal investimento e de receber a alocação dos Tokens, é capaz de incorrer em uma perda total de tal investimento sem prejudicar sua condição financeira e é capaz de suportar o risco econômico de tal investimento por um período indefinido;
i) O Comprador possui profundo entendimento da funcionalidade, uso, mecanismos de armazenamento, transmissão e complexidades associadas a tokens criptográficos, como BTC e ETH, e sistemas de software baseados em blockchain;
j) O Comprador compreende que a Venda de Tokens não envolve a compra de ações, valores mobiliários conversíveis em ações ou qualquer equivalente em qualquer empresa, corporação ou outra entidade pública ou privada, existente ou futura, em qualquer jurisdição;
k) O Comprador foi informado de que os Tokens a serem alocados ao Comprador nos termos deste instrumento podem, em certas jurisdições, ser considerados valores mobiliários e que os Tokens emitidos nos termos deste instrumento não podem ser revendidos, exceto em conformidade com as leis de valores mobiliários aplicáveis. Consequentemente, o Comprador compreende que deve suportar os riscos econômicos de sua compra nos termos destes Termos ou do possível recebimento futuro de Tokens por um período indefinido;
l) Todas as informações fornecidas pelo Comprador em qualquer processo de registro vinculado a esta compra são verdadeiras e precisas e o Comprador não age em nome de terceiros;
m) O Comprador está legalmente autorizado a receber, deter e fazer uso dos Tokens em sua jurisdição e não está obtendo ou utilizando Tokens para quaisquer fins ilegais;
n) O Comprador está adquirindo os Tokens para fazer uso de sua funcionalidade. Em particular, o Comprador não está adquirindo os Tokens com o propósito de investimento especulativo;
o) O Comprador indicará à Fundação um endereço para a alocação dos Tokens antes da alocação dos Tokens. O Comprador compreende e aceita que indicar um endereço falso ou um endereço que não suporte tecnicamente os Tokens pode resultar na impossibilidade de o Comprador obter acesso aos seus Tokens. O Comprador compreende ainda que permanece sob sua exclusiva responsabilidade proteger o arquivo de chave privada relacionado ao referido endereço e que, caso o Comprador perca o acesso ao endereço (ou carteira), os Tokens seriam irrecuperáveis e permanentemente perdidos;
p) O Comprador confirma que o endereço do Comprador pertence ao Comprador e está sob seu exclusivo controle. O Comprador compreende que, como parte do processo de alocação de Tokens, poderá ser solicitado pela Fundação ou por um Prestador de Serviços a comprovar o controle sobre o endereço do Comprador e que, na falta de tal comprovação, a alocação de Tokens poderá não ser realizada.
q) O Comprador compreende que não possui direito contra qualquer parte de solicitar qualquer reembolso do Preço de Compra sob qualquer circunstância.
r) O COMPRADOR RENUNCIA AO DIREITO DE PARTICIPAR DE QUALQUER AÇÃO COLETIVA OU ARBITRAGEM COLETIVA CONTRA QUALQUER ENTIDADE OU INDIVÍDUO ENVOLVIDO NA ALOCAÇÃO DE TOKENS E NA OPERAÇÃO DA REDE;
s) O Comprador compreende e expressamente aceita que não há qualquer garantia sobre os Tokens e/ou o sucesso do Projeto, expressa ou implícita, na máxima extensão permitida por lei, e que os Tokens a serem criados e obtidos são por conta e risco exclusivo do Comprador numa base "como estão" e "em desenvolvimento", sem, na máxima extensão permitida por lei, quaisquer garantias de qualquer natureza, incluindo, mas não se limitando a, garantias de título ou garantias implícitas, comercialização ou adequação a um propósito específico;
t) O Comprador compreende e aceita que não se baseou em quaisquer declarações ou garantias feitas pela Fundação ou por qualquer outra pessoa que não as feitas nestes Termos, incluindo, mas não se limitando a, conversas de qualquer natureza, seja por comunicação oral ou eletrônica, ou qualquer apresentação, documento técnico, white paper, materiais de marketing, conteúdo de mídia social ou publicação em website;
u) O Comprador compreende que o valor dos Tokens ao longo do tempo (se houver) pode experimentar extrema volatilidade ou depreciar-se totalmente;
v) O Comprador compreende que é de sua exclusiva responsabilidade determinar se a transferência do Preço de Compra, a alocação, uso ou propriedade de Tokens, a potencial valorização ou depreciação do valor dos Tokens ao longo do tempo (se houver), a venda e compra de Tokens e/ou qualquer outra ação ou transação relacionada à Rede têm implicações tributárias.
## 8. Declarações, Garantias e Reconhecimentos da Fundação [#8-declarações-garantias-e-reconhecimentos-da-fundação]
A Fundação declara e garante ao Comprador o seguinte, e reconhece que o Comprador está se baseando nestas declarações e garantias:
a) A Fundação é uma fundação devidamente organizada, validamente existente e em situação regular nos termos das leis da Suíça e possui todo o poder corporativo e autoridade necessários para exercer seu propósito estatutário e operação conforme atualmente conduzidos e conforme presentemente se propõe a conduzir.
b) A execução, entrega e cumprimento destes Termos não resultarão — no melhor conhecimento da Fundação — em qualquer violação, conflito material ou inadimplemento material de (i) qualquer disposição dos documentos organizacionais da Fundação; (ii) qualquer disposição de qualquer licença, sentença, decreto, contrato ou ordem da qual a Fundação seja parte.
c) A execução, entrega e cumprimento destes Termos não requerem aprovação ou outra ação de qualquer pessoa que não a Fundação.
## 9. Exclusão de Garantias [#9-exclusão-de-garantias]
Os Tokens são vendidos "como estão" e "conforme disponíveis", sem garantias de qualquer natureza. Na máxima extensão permitida pela lei aplicável, a Fundação expressamente exclui todas as garantias implícitas quanto aos Tokens e/ou à Rede, incluindo, sem limitação, garantias implícitas de comercialização, adequação a um propósito específico, titularidade e não violação. A Fundação, em particular, não garante que os Tokens sejam confiáveis, atuais ou livres de erros, que atendam aos requisitos do Comprador, ou que defeitos nos Tokens e/ou na Rede serão corrigidos; e (iii) a Fundação não pode e não garante que os Tokens, a Rede ou o mecanismo de entrega dos Tokens estejam livres de vírus ou outros componentes prejudiciais.
Algumas jurisdições não permitem a exclusão de certas garantias ou exclusões de termos implícitos em contratos com consumidores, de modo que algumas ou todas as exclusões de garantias e isenções nesta Seção podem não se aplicar ao Comprador. Em tal caso, serão mantidas na extensão mínima exigida por lei, e todos os outros termos, cláusulas e disposições deste Contrato permanecerão válidos e executáveis.
## 10. Disposições Gerais [#10-disposições-gerais]
### 10.1 Contratantes Independentes [#101-contratantes-independentes]
Estes Termos não criam uma relação de mandante e mandatário, empregador e empregado, sociedade, joint venture ou qualquer outra relação além de contratantes independentes entre as Partes. Nada aqui contido deverá ser interpretado como criando ou implicando uma joint venture, relação de mandante e mandatário, empregador e empregado, sociedade ou qualquer outra relação além de contratantes independentes entre as Partes, e nenhuma Parte terá qualquer direito, poder ou autoridade para criar qualquer obrigação, expressa ou implícita, em nome da outra em relação ao desempenho nos termos deste instrumento.
### 10.2 Cessões e Transferências [#102-cessões-e-transferências]
Estes Termos, incluindo quaisquer direitos e obrigações aqui contidos, e em particular o direito de receber a alocação de Tokens conforme aqui descrito, não podem ser cedidos ou transferidos pelo Comprador, no todo ou em parte, sem o consentimento prévio por escrito da outra Parte, tal consentimento a ser dado a critério exclusivo da outra Parte e somente em conformidade com as leis e regulamentos aplicáveis, incluindo, sem limitação, a Lei de Valores Mobiliários e regulamentos dela decorrentes. Qualquer cessão ou transferência que não esteja em conformidade com os termos desta disposição será nula.
### 10.3 Divisibilidade [#103-divisibilidade]
Se qualquer disposição destes Termos for inválida em qualquer jurisdição nos termos da lei aplicável, a legalidade e a exequibilidade das demais disposições aqui contidas não serão de forma alguma afetadas ou prejudicadas. Em tal evento, as Partes comprometem-se a elaborar uma regra substitutiva legalmente válida que se aproxime o máximo possível da disposição inválida dentro da intenção econômica destes Termos. Estes Termos serão interpretados como se a cláusula inválida tivesse sido omitida desde o início.
### 10.4 Não Renúncia [#104-não-renúncia]
Se qualquer Parte renunciar à execução ou ao exercício de seu direito contratual em um caso particular, isso não poderá ser considerado uma renúncia geral do respectivo direito, de qualquer outro direito contratual, ou do exercício e execução dos mesmos.
### 10.5 Lei Aplicável e Jurisdição [#105-lei-aplicável-e-jurisdição]
Estes Termos e todas as reivindicações relacionadas a ou decorrentes deles, ou de sua violação, sejam contratuais, extracontratuais ou de outra natureza, serão regidos pela Lei Suíça, excluindo os princípios de conflito de leis suíços. A Convenção das Nações Unidas sobre Contratos de Compra e Venda Internacional de Mercadorias ("Convenção de Viena sobre Vendas") é excluída.
Qualquer disputa, controvérsia ou reivindicação decorrente de ou em relação a estes Termos, incluindo a validade, invalidade, violação ou rescisão dos mesmos, será resolvida pelos tribunais ordinários de Zug, Suíça.
# Visão Geral das Metodologias
## O que é uma metodologia? [#o-que-é-uma-metodologia]
Uma metodologia no [Ecossistema 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 ou FAILED 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 no Ecossistema 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#the-mvf-author-role) escrevem a especificação de verificação e [MvA Developers](/docs/standard/concepts/mva#the-mva-developer-role) 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) são emitidos e [créditos](/docs/protocol/credits) são mintados.
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 Créditos Tokenizados de Reciclagem ([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 Créditos Tokenizados de Carbono ([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 uma economia circular e de baixo carbono. 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 do Ecossistema 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.
## 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 transforma a governança em uma promessa de controle descentralizado atual.
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, o Ecossistema Carrot é projetado 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 on-chain, incluindo [MassIDs](/docs/protocol/mass-ids), [Certificados](/docs/protocol/certificates), tokens de crédito 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 Explorer](/docs/protocol/explorer) 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 torna a rede uma infraestrutura de propósito público: trilhos de mercado compartilhados para créditos da economia circular, governados para servir à missão, e não um produto privado otimizado para extração.
## Uma camada de governança [#uma-camada-de-governança]
A Rede Carrot é uma camada de governança habilitada por tecnologia para infraestrutura de mercado compartilhada. Contratos inteligentes apoiam 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 Explorer](/docs/protocol/explorer).
A blockchain faz parte desse modelo de responsabilidade porque dá aos registros finais de créditos durabilidade, verificação independente, auditabilidade e interoperabilidade. Ela 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.
Na linguagem de Chris Dixon em [*Read Write Own*](https://a16zcrypto.com/posts/article/read-write-own-intro/), esse modelo representa a mudança de plataformas que leem e escrevem dados em nome dos usuários para redes onde os participantes são donos das regras e dos resultados. 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 on-chain da infraestrutura de créditos podem ser verificados de forma independente por meio de infraestrutura blockchain pública e reutilizados por sistemas interoperáveis.
* **Compartilhamento de recompensas** — a receita de compra de créditos é distribuída de acordo com políticas de recompensas publicadas para os papéis relevantes de cadeia de suprimentos e metodologia.
## 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).
## Saiba mais [#saiba-mais]
Como decisões são tomadas dentro da Rede Carrot
O papel, a estrutura e o propósito da Fundação Carrot
# A Fundação
## A Fundação Carrot [#a-fundação-carrot]
A Fundação Carrot é a guardiã do ecossistema Carrot — responsável pelo desenvolvimento do [standard](/docs/standard) e do [registro](/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.
## 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 e descentralizadas, 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** — Blockchain, segurança, IA, IoT
Para a lista atual de conselheiros, visite [carrot.eco](https://www.carrot.eco/).
# White Paper Original
## White Paper Original [#white-paper-original]
O White Paper original da Carrot continua útil como contexto histórico para o pensamento inicial por
trás do [Ecossistema Carrot](/docs/network). Ele não é a fonte de verdade atual para o protocolo em
operação, metodologias, registro, governança, recompensas, termos legais ou informações voltadas a
compradores.
A documentação atual prevalece sempre que divergir da redação histórica do White Paper.
## Fonte de verdade atual [#fonte-de-verdade-atual]
* **Protocolo e verificação** — Comece pelo
[Protocolo da Economia Circular](/docs/protocol), depois use
[MassIDs](/docs/protocol/mass-ids) e Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)) — para créditos de reciclagem e de carbono — para o fluxo de verificação
atual.
* **Registro e recompensas** — Use a página de [registro](/docs/registry) para emissão,
rastreamento e aposentadoria de créditos, e [Distribuição de Recompensas](/docs/protocol/rewards-distribution)
para entender como a receita de créditos chega aos contribuidores verificados.
* **Standard e metodologias** — Use [The Standard](/docs/standard) para o papel da Carrot como
organismo de standards e [Metodologias](/docs/methodologies) para o conteúdo de metodologias
aprovadas.
* **Fundação e governança** — Use [A Fundação](/docs/network/the-foundation) para o papel e o
propósito público da Fundação, e [Governança](/docs/network/governance) para entender como a
participação evolui ao redor desse propósito.
* **Compradores e termos legais** — Use [Para Compradores](/docs/for-buyers) para informações
voltadas a compradores, [Termos e Condições](/docs/legal/terms-and-conditions) e
[Termos de Venda de Tokens](/docs/legal/token-sales-terms) para termos legais.
Para perguntas sobre o White Paper histórico ou materiais de contexto arquivados, entre em contato
com a equipe fundadora em [founders@carrot.eco](mailto:founders@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) |
| 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) |
| Integrador | Conecta sistemas operacionais à Carrot enviando dados da cadeia de suprimentos pela API. | [Integradores](/docs/protocol/network-integrators) |
| 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. | [Para Compradores](/docs/for-buyers) |
## 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. A metodologia é traduzida em um **MvF** e implementada como uma **MvA**.
4. **Integradores** enviam dados da cadeia de suprimentos a partir de operações físicas.
5. O **dMRV** executa regras de metodologia contra esses dados e produz evidência auditável.
6. **VVBs e auditores independentes** fornecem garantia externa quando necessário.
7. Resultados verificados se tornam [certificados](/docs/protocol/certificates) e [créditos](/docs/protocol/credits).
8. O **registry** emite, rastreia e aposenta créditos.
9. **Compradores de créditos** compram e aposentam créditos.
10. A receita retorna aos participantes verificados por meio da [distribuição de recompensas](/docs/protocol/rewards-distribution).
## 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
* [Para Compradores](/docs/for-buyers) — O que compradores de créditos recebem e como comprar
# 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 digitalizam a cadeia de suprimentos da reciclagem ao conectar suas operações ao Ecossistema 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) — tokens não fungíveis 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, mintam tokens de crédito fungíveis: [Tokenized Carbon Credits (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc) e [Tokenized Recycling Credits (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc). Esses créditos são padronizados por tipo de material, 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]
As receitas das compras de créditos são distribuídas diretamente aos participantes verificados na cadeia de suprimentos da reciclagem por meio de contratos inteligentes. 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#the-role-of-the-recycler), [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]
O Ecossistema 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 ao Ecossistema 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, quais evidências você recebe e como iniciar uma conversa
enterprise. [Ir para Para Compradores](/docs/for-buyers)
# 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 no Ecossistema Carrot. Ele conecta dados da cadeia de suprimentos, registros de cadeia de custódia, certificados, créditos tokenizados, 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, minting on-chain, compra e aposentadoria
Smart contracts, fluxos on-chain e interoperabilidade
# Arquitetura da Plataforma
## Como o Ecossistema Carrot funciona [#como-o-ecossistema-carrot-funciona]
Esta página oferece a visão operacional ponta a ponta do Ecossistema 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, tokenizaçã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 tokenização de créditos, compra, aposentadoria, carteiras 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 minting on-chain.
[Saiba mais sobre a execução da metodologia](/docs/protocol/methodology-execution)
### 4. Minting on-chain [#4-minting-on-chain]
Cada MassID verificado é mintado on-chain — os metadados são construídos, enviados ao [IPFS](https://ipfs.tech/), e o NFT do MassID é mintado on-chain. Isso cria um registro imutável e publicamente verificável do lote de resíduos.
[Saiba mais sobre minting on-chain](/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 tokens de crédito fungíveis — [Tokenized Recycling Credits (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc) e [Tokenized Carbon Credits (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc) — cada um representando 1 tonelada métrica de impacto ambiental verificado. A metodologia [BOLD Recycling](/docs/methodologies/bold-recycling) emite TRCs como `C-BIOW`; a metodologia [BOLD Carbon (CH₄)](/docs/methodologies/ams-iii-f/bold-carbon) emite TCCs como `C-CARB.CH4` (metano). Outras metodologias podem emitir símbolos de crédito diferentes. Os créditos são tokens ERC-20 padrão, projetados 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 como transações atômicas on-chain em 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]
As receitas das compras de créditos são [distribuídas](/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), [Frentistas de Lixeira](/docs/protocol/supply-chain), [Transportadores](/docs/protocol/supply-chain), [Processadores](/docs/protocol/supply-chain), [Recicladores](/docs/protocol/supply-chain#the-role-of-the-recycler) 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 queima os tokens de crédito on-chain e minta um `CreditRetirementReceipt` [soulbound](/docs/protocol/credit-lifecycle) como prova permanente. Os créditos podem ser aposentados de forma independente (a qualquer momento após a compra) 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 on-chain — desde o minting do MassID até a aposentadoria de créditos — é registrada na **blockchain pública** como transações de contratos inteligentes. 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 na chain, 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 Explorer](/docs/protocol/explorer) oferece uma visualização amigável e focada no domínio dos dados on-chain, além de dados da plataforma (definições de metodologia, execução de regras, homologações). Para verificação descentralizada e independente de infraestrutura apenas dos dados on-chain, qualquer explorador 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) — A infraestrutura on-chain que sustenta o ecossistema
* [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
* [Explorer](/docs/protocol/explorer) — O Carrot Explorer e exploradores de blockchain para verificação de dados on-chain
### 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**. Cada massa de material pode ser rastreada ao longo da [cadeia de suprimentos](/docs/protocol/supply-chain) de reciclagem, desde a geração até o processamento final. O Ecossistema Carrot codifica esse trabalho físico em [MassIDs](/docs/protocol/mass-ids), criando uma cadeia de custódia inquebrável que elimina a contagem dupla e permite que as recompensas sejam distribuídas diretamente a todos os contribuidores verificados por meio de smart contracts.
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 — [Créditos Tokenizados de Reciclagem (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc) emitidos sob metodologias como [BOLD Recycling](/docs/methodologies/bold-recycling), e [Créditos Tokenizados de Carbono (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.
As receitas das compras de créditos são distribuídas 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]
O Ecossistema 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/for-buyers/how-to-buy) | [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: nenhuma entidade controla tanto a execução das regras de verificação quanto o julgamento sobre se essas regras são corretamente aplicadas.
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. Cada resultado de verificação é determinístico, registrado on-chain e auditável por qualquer parte. | Software determinístico, auditável por VVBs e pelo público |
## 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 fornece a infraestrutura que orquestra e registra a execução de Monitoramento, Relato e Verificação digital ([dMRV](/docs/protocol/dmrv)) — para créditos de reciclagem e de carbono. Ela aprova metodologias, frameworks de verificação de metodologia e aplicações de dMRV de terceiros para uso no Ecossistema Carrot, depois executa critérios de frameworks aprovados contra dados submetidos e preserva a evidência resultante.
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
## O que é um standard nos mercados ambientais? [#o-que-é-um-standard-nos-mercados-ambientais]
Nos mercados ambientais, um **standard** é a organização que define e governa as regras de como os créditos ambientais são medidos e verificados. Ele aprova metodologias, 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, 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 no Ecossistema 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.
## 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 on-chain e visíveis através do [Carrot Explorer](/docs/protocol/explorer).
* **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.
# 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. 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.
* Anexos são tipicamente referenciados posteriormente nos payloads de eventos.
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 unauthorized`: token bearer inválido, expirado ou malformado.
* `403 restrictedResource`: token válido sem permissão para o recurso ou ambiente alvo.
***
[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`
* um entre `participantId` ou `participant` (obrigatório)
* um entre `addressId` ou `address` (obrigatório)
Campos opcionais:
* `deduplicationId` para evitar envios duplicados em retentativas.
* `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": "validationError",
"message": "Failed validating required field",
"id": "5g1XRgWZ0odA79dHJvcPP",
"timestamp": "1684766595"
}
]
}
```
## Códigos de erro [#códigos-de-erro]
| HTTP | Código | Significado |
| ---- | -------------------------------- | ------------------------------------------------------------------------------------- |
| 400 | `invalidJson` | O corpo da requisição não pôde ser decodificado como JSON. |
| 400 | `validationError` | O payload da requisição falhou na validação de schema. |
| 401 | `unauthorized` | Token de acesso ausente, inválido ou expirado. |
| 403 | `restrictedResource` | O token não tem permissão para este recurso ou ambiente. |
| 404 | `objectNotFound` | O recurso não existe ou não é compartilhado com o proprietário do token. |
| 409 | `conflictError` | A operação não pôde ser concluída devido a um conflito de dados. |
| 409 | `PENDING_PROCESS_CONFLICT_ERROR` | O documento solicitado ainda está sendo processado. Tente novamente mais tarde. |
| 429 | `rateLimited` | A taxa de requisições excedeu o limite permitido. |
| 500 | `internalServerError` | Falha inesperada no servidor. |
| 503 | `serviceUnavailable` | Serviço temporariamente indisponível ou requisição excedeu a janela de processamento. |
| 504 | `gatewayTimeout` | Timeout upstream/expiração de sessão ao completar a requisição. |
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.
## Eventos em lote [#eventos-em-lote]
Utilize `POST /documents/events` para criar múltiplos eventos para um documento em uma única requisição.
Cada evento no lote segue o mesmo schema e as mesmas regras de validação do endpoint de documento
individual acima.
## 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. |
| `RELATED` | Vincula este documento a outro documento. |
| `UPDATE` | Atualiza campos específicos de visibilidade do documento. |
| `SPLIT` | Cria um novo documento com parte do valor original. Sem schema dedicado — representado via campos de payload `target`. |
| `OUTPUT` | Cria um novo documento downstream a partir dos dados atuais. Sem schema dedicado — representado via campos de payload `target`. |
| `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`). `SPLIT` e `OUTPUT` não possuem schemas próprios e são
representados através de dados de evento utilizando os campos de payload `target`.
## 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.
## Propagação de eventos [#propagação-de-eventos]
Quando `propagateEvent` está habilitado, a propagação se aplica apenas a um nível de relacionamento.
Algumas combinações de eventos são restritas (por exemplo, eventos propagados não podem enviar `value`).
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: 6 endpoints em 3 recursos (`documents`, `events`, `attachments`).
## URL base [#url-base]
* API: `https://api.carrot.eco`
* Auth: `https://auth.api.carrot.eco/oauth2/token`
* Explorer: `https://explore.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.
* [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).
# 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 do [Ecossistema 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 no Ecossistema 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 Explorer](https://explore.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) Criar um documento [#2-criar-um-documento]
Crie o registro base de rastreabilidade:
```http
POST /documents
Authorization: Bearer
```
Detalhes do endpoint: [Documentos](/docs/integrations/api/documents).
## 3) Adicionar um evento [#3-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).
## 4) Recuperar e validar o estado [#4-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).
## 5) Adicionar proteções para produção [#5-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 |
| `401` / `403` | 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` | Outros erros de conflito | **Abortar** — corrija o conflito de dados (ex: duplicata), 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 (`4xx` exceto `409 PENDING_PROCESS_CONFLICT_ERROR` e `429`).
## Mecânica do deduplicationId [#mecânica-do-deduplicationid]
O `deduplicationId` é sua chave de idempotência 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). Se o servidor já processou sua requisição, a retentativa retorna a resposta original em vez de criar uma duplicata. Isso é crítico para `POST /documents` e `POST /documents/{id}/events`.
## 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 /v1/documents/{wrongDocumentId}/events
{ "name": "CANCEL", ... }
2. POST /v1/documents
{ ...dados corrigidos do documento... }
3. POST /v1/documents/{newDocumentId}/events
{
"name": "RELATED",
"relatedDocument": {
"documentId": "{wrongDocumentId}",
"bidirectional": true
},
...
}
```
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 integrador (consulte [Limites de Taxa](/docs/integrations/reference/rate-limits) para a referência completa):
| Ambiente | Limite |
| -------------- | -------------------------- |
| Test / Sandbox | 5 requisições por segundo |
| Produção | 10 requisições por segundo |
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 Explorer](/docs/protocol/explorer).
* `isPubliclySearchable`: controla se os registros podem ser encontrados por meio de busca pública.
O flag `isPublic` pode aparecer em três níveis:
* **Nível do evento** — controla a visibilidade do evento inteiro.
* **Nível do atributo** — sobrepõe a visibilidade do evento para um atributo específico.
* **Nível de `metadata.attributes`** — controla a visibilidade de entradas de metadata individuais.
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.
Quando um documento ou evento é marcado como público (`isPublic: true`), qualquer pessoa com o ID do
documento pode visualizá-lo no Carrot Explorer (explore.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.
## 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 `sensible: true`
nos metadados. A plataforma aplica mascaramento nas superfícies públicas (ex.: `AA*-A**A` para uma
placa de veículo) enquanto preserva o valor completo para auditores.
Não pré-mascare ou redija valores no seu payload. Envie os dados completos e deixe a plataforma
realizar o mascaramento.
Veja [Formatos de Dados](/docs/integrations/reference/data-formats#sensitive-data) para o atributo
`sensible` 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 — protege a identidade do gerador de concorrentes |
| Manifesto de transporte (MTR) | Anexo | Download restrito por confidencialidade; a existência do documento permanece publicamente visível |
| Certificado de destinação final (CDF) | Anexo | Download restrito por confidencialidade; a existência do documento permanece publicamente visível |
| Placa do veículo | Metadados de evento | Dados pessoais — use `sensible: true` com `isPublic: true` para mascaramento parcial |
| Identificador do motorista | Metadados de evento | Dados pessoais — use `sensible: 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 `sensible: 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#visibility-and-privacy)
* [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 — eles são criados inline no seu primeiro envio (nenhuma etapa separada de criação é necessária)
* Familiaridade com os [conceitos fundamentais](/docs/integrations/getting-started/core-concepts) — especialmente o modelo imutável baseado em eventos
## Etapa 1: Criar o documento [#etapa-1-criar-o-documento]
Crie o registro raiz com classificação e campos de visibilidade base. Dados de participante e
endereço podem ser enviados inline como objetos na primeira requisição. Nas requisições seguintes,
você pode reutilizar os IDs retornados pela plataforma.
```json
POST /v1/documents
{
"category": "MassID",
"type": "SEU_TIPO_DE_RESÍDUO",
"measurementUnit": "kg",
"externalCreatedAt": "2026-03-01T10:00:00.000Z",
"isPublic": true,
"isPubliclySearchable": true,
"participant": {
"countryCode": "BR",
"name": "Empresa Exemplo",
"taxId": "11111111111111",
"taxIdType": "CNPJ",
"type": "COMPANY"
},
"address": {
"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
},
"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` | Sim | `kg` para reciclagem, `kg CO₂e` para carbono |
| `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 |
| `participant` | Não\* | Objeto de participante inline (veja os campos obrigatórios abaixo) |
| `participantId` | Não\* | ID de um participante existente — use para requisições subsequentes |
| `address` | Não\*\* | Objeto de endereço inline (veja os campos obrigatórios abaixo) |
| `addressId` | Não\*\* | ID de um endereço existente — use para requisições subsequentes |
| `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 |
\* Envie `participant` (objeto inline) ou `participantId` (ID), não ambos.
\*\* Envie `address` (objeto inline) ou `addressId` (ID), não ambos.
Na sua **primeira requisição**, envie os objetos completos `participant` e `address`. A plataforma
os cria e retorna seus IDs na resposta. Nas **requisições seguintes**, reutilize esses IDs via
`participantId` e `addressId` em vez de reenviar os objetos completos.
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.
**Campos obrigatórios do `participant` inline:**
| Campo | Tipo | Descrição |
| ------------- | ------ | ---------------------------------------------------- |
| `countryCode` | string | Código do país com duas letras (ISO 3166-1 alpha-2) |
| `name` | string | Nome completo ou razão social |
| `taxId` | string | Número do documento (apenas dígitos, sem formatação) |
| `taxIdType` | string | Tipo de documento — ex. `CPF`, `CNPJ` |
| `type` | string | `PERSON` ou `COMPANY` |
Referência: [API de Documentos](/docs/integrations/api/documents).
## Etapa 2: Adicionar eventos à linha do tempo [#etapa-2-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 de um participante e endereço:
```json
POST /v1/documents/{documentId}/events
{
"name": "ACTOR",
"label": "SEU_LABEL_DE_PAPEL",
"externalCreatedAt": "2026-03-01T10:05:00.000Z",
"isPublic": true,
"participant": {
"countryCode": "BR",
"name": "Nome do Participante",
"taxId": "22222222222",
"taxIdType": "CPF",
"type": "PERSON"
},
"address": {
"name": "Ponto de Coleta",
"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
}
}
```
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.
Após a primeira criação inline, você pode usar `participantId` e `addressId` para eventos subsequentes que referenciem o mesmo participante ou endereço.
### 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 /v1/documents/{documentId}/events
{
"name": "NOME_DO_SEU_EVENTO",
"externalCreatedAt": "2026-03-01T11:00:00.000Z",
"isPublic": true,
"participantId": "id-do-participante-da-resposta-anterior",
"addressId": "id-do-endereço-da-resposta-anterior",
"metadata": {
"attributes": [
{ "name": "NOME_DO_SEU_ATRIBUTO", "value": "valor-do-atributo" }
]
},
"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.
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.
**Campos obrigatórios do `address` inline:**
| Campo | Tipo | Descrição |
| -------------- | ------ | --------------------------------------------------- |
| `city` | string | Cidade |
| `countryCode` | string | Código do país com duas letras (ISO 3166-1 alpha-2) |
| `countryState` | string | Estado |
| `latitude` | number | Latitude |
| `longitude` | number | Longitude |
| `name` | string | Nome descritivo para o endereço |
| `neighborhood` | string | Bairro |
| `number` | string | Número |
| `street` | string | Logradouro |
| `zipCode` | string | Código postal (apenas dígitos, sem formatação) |
### 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` são aceitos.
* **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 /v1/documents/{documentId}/events
{
"name": "CLOSE",
"externalCreatedAt": "2026-03-02T16:00:00.000Z",
"isPublic": true,
"participantId": "id-do-participante-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 3: Anexar arquivos de evidência (opcional) [#etapa-3-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 4: Recuperar e validar o estado final [#etapa-4-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. Isso garante semântica at-most-once: se o servidor recebeu sua
primeira requisição mas a resposta foi perdida, a retentativa retornará o resultado original em
vez de criar uma duplicata.
* 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).
* 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.
## 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` para comportamento idempotente em retentativas.
## 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 `sensible: true` nos metadados para que a plataforma aplique mascaramento em superfícies públicas.
* Consulte [Privacidade e Mascaramento](/docs/integrations/guides/privacy-and-masking) para controles de visibilidade.
Referências relacionadas:
* [Conceitos Fundamentais](/docs/integrations/getting-started/core-concepts)
* [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. |
| `RELATED` | Cria vínculos de relação entre documentos. |
| `UPDATE` | Atualiza campos selecionados relacionados à visibilidade do documento. |
| `SPLIT` | Cria um novo documento com parte do valor existente. |
| `OUTPUT` | Cria um documento downstream a partir do contexto atual. |
| `CUSTOM` | Nomes de eventos específicos da metodologia/aplicação. |
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` / `SPLIT` / `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`
* um entre `participant` ou `participantId` (obrigatório)
* um entre `address` ou `addressId` (obrigatório)
* `attachments` (opcional)
* `deduplicationId` (opcional)
Para integrações orientadas por metodologia, eventos `ACTOR` devem incluir um **label** que identifica o papel do participante. 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`.
## 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#framework-rules-vs-application-rules). 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 integrador.
## Limites [#limites]
| Limite | Teste | Produção |
| ------------------------ | ----- | -------- |
| Requisições por segundo | 5 | 10 |
| Eventos por documento | 100 | 100 |
| Tamanho máximo de upload | 10 MB | 10 MB |
## 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) deve ser classificado usando uma hierarquia de três
níveis: **Categoria**, **Tipo** e **Subtipo**. 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. Por exemplo, sob
a categoria `MassID`, os tipos incluem:
* `Organic`
* `Plastic`
* `Paper`
* `Glass`
Cada tipo ajuda a identificar a natureza da massa sendo rastreada.
### 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`, `HDPE`, `Plastic Film`
* Para o tipo `Organic`: `Food Waste`, `Garden Waste`, `Industrial Sludge`
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]
* A combinação de categoria, tipo e subtipo é obrigatória para todo documento.
* 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#supported-waste-codes)
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 — Créditos de Carbono Tokenizados ([TCC](/docs/protocol/credits#tokenized-carbon-credits-tcc))
* **Token on-chain**: `C-CARB.CH4` (reduções de metano)
## A abordagem da Carrot [#a-abordagem-da-carrot]
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.
# 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, evitando emissões de metano relevantes para o mercado de carbono. 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 — e então distribui [recompensas](/docs/protocol/rewards-distribution) para cada participante da cadeia de suprimentos.
O BOLD Recycling gera [Créditos Tokenizados de Reciclagem (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. A receita das compras de créditos é distribuída 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 Explorer](https://explore.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)
# Interoperabilidade
## Projetado para integração [#projetado-para-integração]
Os smart contracts do Ecossistema Carrot são construídos em padrões abertos e implantados em uma blockchain pública, tornando-os inerentemente interoperáveis com o ecossistema blockchain mais amplo. 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 Explorer](/docs/protocol/explorer) 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 transferidos, Recompensas atribuídas |
| **Aposentadoria** | Créditos aposentados, Recibo de aposentadoria emitido |
| **Recompensas** | Recompensas registradas, Saques de notas de crédito |
| **Revogação** | Token revogado, Créditos queimados |
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 totalmente 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.
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 `upgradeTo` é chamado, apenas o endereço de implementação armazenado dentro do proxy muda — a entrada do ContractRegistry (que aponta para o proxy) não precisa ser atualizada, e todos os contratos dependentes continuam operando sem reimplantação.
* **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]
O Ecossistema Carrot é agnóstico 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.
[Saiba mais sobre smart contracts](/docs/protocol/smart-contracts) · [Saiba mais sobre categorias de contratos](/docs/protocol/smart-contracts/contract-categories) · [Acesse o Carrot Explorer](https://explore.carrot.eco)
# 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) do Ecossistema 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 evitação de emissões. On-chain, cada certificado é soulbound (não transferível) e mantido pelo [Vault](/docs/protocol/smart-contracts); quando é emitido, uma quantidade equivalente de tokens de crédito 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]
O Ecossistema 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 da reciclagem |
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#the-role-of-the-recycler), 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 tokens de crédito `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 pela reciclagem de resíduos em vez de enviá-los a um 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 reciclagem com o cenário de linha de base (o que teria acontecido com os resíduos sem a reciclagem).
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 tokens de crédito `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 emitidos** — O contrato inteligente `InventoryManager` emite 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, tokens de crédito 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]
O Ecossistema Carrot transforma trabalho de reciclagem verificado em ativos ambientais por meio de uma estrutura on-chain em camadas. 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#the-role-of-the-recycler)). Implementado como um NFT soulbound (ERC-721).
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 NFT soulbound.
3. **[Crédito](/docs/protocol/credits)** — Uma unidade negociável de impacto ambiental verificado em que 1 crédito = 1 tonelada métrica. Criado automaticamente quando os certificados são gerados, em quantidade equivalente. Cada metodologia emite créditos sob seu próprio símbolo on-chain (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 um token ERC-20 fungível — emitido e transacionado em qualquer quantidade, incluindo frações.
4. **`CreditPurchaseReceipt`** — Um NFT soulbound criado quando créditos são [comprados](/docs/protocol/credit-purchase). Fornece prova imutável de que a transação ocorreu.
5. **`CreditRetirementReceipt`** — Um NFT soulbound criado 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 | Token | Padrão | Transferível? | O que comprova |
| ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- | --------------- | -------------------------------------------------------- |
| Rastreamento | MassID | ERC-721 | Não (soulbound) | Resíduo físico foi coletado, triado e transportado |
| Certificação | [GasID](/docs/protocol/certificates#gasid) / [RecycledID](/docs/protocol/certificates#recycledid) | ERC-721 | Não (soulbound) | Impacto ambiental foi verificado por dMRV |
| Minting | [TRC](/docs/protocol/credits#tokenized-recycling-credits-trc) / [TCC](/docs/protocol/credits#tokenized-carbon-credits-tcc) (ex.: `C-BIOW`, `C-CARB.CH4`) | ERC-20 | Sim (fungível) | 1 crédito = 1 tonelada métrica de impacto verificado |
| Compra | `CreditPurchaseReceipt` | ERC-721 | Não (soulbound) | Créditos foram comprados com pagamento em USDC |
| Aposentadoria | `CreditRetirementReceipt` | ERC-721 | Não (soulbound) | Créditos foram permanentemente queimados e reivindicados |
Todos os tokens são implantados on-chain.
## Por que soulbound? [#por-que-soulbound]
Todos os NFTs no Ecossistema Carrot são **soulbound** — eles não podem ser transferidos entre carteiras. Esta é uma escolha de design deliberada:
* **Trilha de auditoria à prova de adulteração** — Como os tokens 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 NFTs soulbound são mantidos pelo contrato inteligente Vault, que gerencia a custódia em nome da rede.
Apenas créditos (tokens ERC-20) 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 criados proporcionalmente à quantidade verificada de cada certificado. A metodologia BOLD Recycling emite TRCs com o símbolo on-chain `C-BIOW`; outras metodologias de reciclagem podem usar símbolos diferentes. Os TRCs são específicos por material — TRCs de vidro representam vidro reciclado, TRCs de plástico representam plástico reciclado.
### 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 criados proporcionalmente à quantidade verificada de cada certificado GasID. A metodologia BOLD Carbon (CH₄) emite TCCs com o símbolo on-chain `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 Explorer](/docs/protocol/explorer) 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]
O Ecossistema 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 on-chain. 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 atômico on-chain:
| Etapa | Ação | Descrição |
| ----- | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1 | **Ordem de compra assinada** | O comprador (ou um operador autorizado) assina uma ordem de compra usando uma assinatura de dados tipados EIP-712, autorizando a transação com o tipo de crédito, quantidade e detalhes de pagamento. |
| 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 transferidos** | Tokens de crédito (ex.: `C-BIOW`, `C-CARB.CH4`) são transferidos do Vault para a carteira do comprador. |
| 5 | **Recibo mintado** | Um NFT `CreditPurchaseReceipt` é mintado como prova imutável e on-chain 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. |
Saiba mais sobre a [distribuição de recompensas](/docs/protocol/rewards-distribution).
Todas as compras e recibos são publicamente verificáveis por meio do [Carrot Explorer](/docs/protocol/explorer) 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](/docs/protocol/certificates) — 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 por ordem de disponibilidade, priorizando os certificados elegíveis mais antigos.
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**. Quando a flag de aposentadoria integrada é habilitada, os créditos são comprados e imediatamente queimados na mesma operação on-chain. Tanto um NFT `CreditPurchaseReceipt` quanto um `CreditRetirementReceipt` são mintados 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.
Para compradores que preferem manter créditos e aposentá-los posteriormente, a aposentadoria standalone está disponível como uma transação separada. 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]
O Ecossistema 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** — incluindo cartão de crédito e transferência bancária — para compradores que preferem fluxos de pagamento tradicionais. A plataforma realiza a conversão para que os smart contracts sempre liquidem 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 comprador, contratos inteligentes e registros on-chain em uma transação de seis etapas: ordem assinada, USDC transferido, certificado atualizado, créditos transferidos, minting do recibo 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 token é **queimado** (destruído on-chain) 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 na blockchain e visualizável por meio do [Carrot Explorer](/docs/protocol/explorer) ou de qualquer explorador de blockchain (ex.: [PolygonScan](https://polygonscan.com/)).
## Dois caminhos de aposentadoria [#dois-caminhos-de-aposentadoria]
O Ecossistema Carrot suporta dois métodos para aposentar créditos:
### Aposentadoria standalone [#aposentadoria-standalone]
O detentor do crédito aposenta créditos de sua própria carteira a qualquer momento após a compra. Isso é útil para compradores que adquirem créditos antecipadamente e os aposentam de acordo com seus próprios cronogramas de relatórios.
1. O detentor assina uma transação de aposentadoria especificando o tipo de crédito e a quantidade.
2. Tokens de crédito são **queimados** do saldo da carteira do detentor.
3. O valor de aposentadoria do [certificado](/docs/protocol/certificates) correspondente é atualizado.
4. Um NFT **`CreditRetirementReceipt`** (Non-Fungible Token) é mintado como prova permanente.
5. A aposentadoria é registrada na blockchain.
### 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. O comprador assina uma [ordem de compra](/docs/protocol/credit-purchase) com a flag de aposentadoria integrada habilitada.
2. O pagamento em USDC é transferido para o `RewardsVault` para [distribuição de recompensas](/docs/protocol/rewards-distribution).
3. Tokens de crédito são transferidos do [Vault](/docs/protocol/smart-contracts) para o comprador — e imediatamente queimados.
4. Tanto um NFT **`CreditPurchaseReceipt`** quanto um **`CreditRetirementReceipt`** são mintados na mesma transação.
5. A aposentadoria é registrada na blockchain.
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 NFT soulbound que serve como prova permanente e on-chain. 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)
* **Parte aposentadora** — O endereço da carteira do comprador que aposentou os créditos
* **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 soulbound, o recibo não pode ser transferido ou alterado. Ele permanece na carteira da parte aposentadora como uma credencial permanente.
## 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.
No Ecossistema Carrot, a aposentadoria é irreversível. Tokens queimados não podem ser recriados, e o recibo de aposentadoria on-chain fornece prova inequívoca de quem reivindicou a compensação. 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 plástico para compensar 50 toneladas métricas de embalagens plásticas). 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 Explorer](https://explore.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) do Ecossistema 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. On-chain, os créditos são implementados como tokens fungíveis ERC-20 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]
O Ecossistema Carrot suporta duas **categorias** de créditos ambientais. Cada categoria pode ter múltiplos **símbolos on-chain**, 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 token = 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 token = 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 on-chain. 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 tokens de crédito são mintados em quantidade equivalente. A metodologia BOLD Recycling emite TRCs com o símbolo on-chain `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 — TRCs de vidro representam vidro reciclado, TRCs de plástico representam plástico reciclado. Essa granularidade permite que compradores de créditos direcionem fluxos de resíduos específicos 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 da reciclagem. 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 da reciclagem com o cenário 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 on-chain `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 o minting até a aposentadoria:
1. **Mintados** — Quando um Certificado é criado pelo `InventoryManager`, os tokens de crédito são mintados em quantidade equivalente e depositados no contrato inteligente [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), os tokens são transferidos do Vault para a carteira do comprador. O pagamento (em USDC) é enviado ao `RewardsVault` para distribuição aos participantes. Um NFT `CreditPurchaseReceipt` é mintado como prova imutável da transação.
4. **Aposentados** — O comprador pode aposentar permanentemente os créditos para reivindicar a compensação ambiental. A aposentadoria queima os tokens e minta um NFT `CreditRetirementReceipt` como comprovante. 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 token 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 no Ecossistema Carrot — o ativo digital 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. On-chain, cada MassID é [soulbound](/docs/protocol/credit-lifecycle) (não transferível) e mantido pelo [Vault](/docs/protocol/smart-contracts).
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 é criado on-chain. 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), criando um registro imutável e publicamente verificável de 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 Lixeira** | B | Gerencia lixeiras de coleta ou pontos de entrega |
| **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 (coleta local e transporte de longa distância) e dois processadores (centro de acumulação local e a fábrica de envase de vidro).
Cada participante na cadeia de custódia é identificado pelo seu endereço de carteira e é elegível para uma parte das recompensas quando [créditos](/docs/protocol/credits) são emitidos a partir do MassID.
## Como os MassIDs são criados [#como-os-massids-são-criados]
MassIDs são gerados em três cenários principais:
### 1. Entrega em lixeira [#1-entrega-em-lixeira]
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, lixeira identificada** — Peso estimado com base no tipo de lixeira 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.
## Prova de Trabalho e Procedência [#prova-de-trabalho-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, envio, 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 ativo digital rastreável é a tecnologia inovadora 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](/docs/protocol/certificates), ele entra no [processo de minting on-chain](/docs/protocol/on-chain-minting) — onde seus metadados são armazenados no IPFS e o MassID é mintado on-chain.
[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.
# Minting On-Chain
## De dados verificados a ativos on-chain [#de-dados-verificados-a-ativos-on-chain]
Após um [MassID](/docs/protocol/mass-ids) ser aprovado na [verificação de metodologia](/docs/protocol/methodology-execution), ele é mintado — transformado de um registro verificado off-chain em um ativo imutável on-chain. O minting cria um vínculo permanente e publicamente verificável entre o trabalho físico de reciclagem e sua representação digital on-chain.
O minting on-chain é 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 minting [#o-processo-de-minting]
### 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 minting.
### 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 endereço de carteira e função |
| **Timestamps** | Quando cada evento na cadeia de custódia ocorreu |
| **Metodologia** | Quais regras de metodologia foram aplicadas e a versão utilizada na verificação |
| **Referências de verificação** | Links para os registros de verificação que confirmaram a validade do material |
Esses metadados se tornam a descrição permanente e imutável do MassID uma vez armazenados on-chain.
### 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 o registro armazenado à prova de adulteração.
A URI do IPFS é então referenciada pelo token on-chain, vinculando o registro leve na blockchain aos metadados completos armazenados no armazenamento descentralizado.
### 4. Minting on-chain [#4-minting-on-chain]
O NFT do MassID é mintado on-chain. O token é um NFT soulbound ERC-721 — intransferível e mantido permanentemente pelo contrato [Vault](/docs/protocol/smart-contracts). A transação de minting registra a URI dos metadados do IPFS on-chain, criando uma associação imutável entre o token e seus dados de proveniência.
Como os MassIDs são soulbound, eles não podem ser negociados ou transferidos entre carteiras. 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 off-chain com seu ID de token on-chain. Essa vinculação garante que a plataforma, a blockchain e o [Carrot Explorer](/docs/protocol/explorer) 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 garantias fundamentais para MassIDs tokenizados:
* **Imutabilidade** — 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 adulteração. Isso garante que o registro de proveniência vinculado a um MassID não possa ser modificado após o minting.
* **Persistência** — Como o IPFS é uma rede distribuída, os metadados não dependem de nenhum servidor ou organização específica. Os dados permanecem acessíveis enquanto pelo menos um nó estiver ativamente fixando-os (pinning), reduzindo o risco de perda de dados.
Juntas, essas propriedades garantem que os metadados que sustentam cada MassID tokenizado sejam permanentes, verificáveis e resistentes a adulterações — 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 tokenizados são a base sobre a qual o restante do ciclo de vida dos créditos é construído. Uma vez que um MassID existe on-chain:
* **Certificados são gerados** — Quando MassIDs são aprovados na verificação de metodologia em uma instalação credenciada por auditores terceiros independentes, [certificados](/docs/protocol/certificates) (RecycledID ou GasID) são mintados, referenciando os MassIDs tokenizados subjacentes como prova do trabalho físico realizado.
* **Créditos são criados** — Cada certificado gera tokens de [crédito](/docs/protocol/credits) fungíveis (TRC ou TCC), representando 1 tonelada métrica de impacto ambiental verificado. Esses créditos são os ativos 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 tokenizado, 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 Explorer](/docs/protocol/explorer) 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 minting e 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 do [Ecossistema Carrot](/docs/network), abrangendo tanto os [Créditos de Reciclagem Tokenizados (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc) quanto os [Créditos de Carbono Tokenizados (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc).
## Como a verificação funciona [#como-a-verificação-funciona]
A Carrot orquestra a execução de dMRV ao executar critérios de frameworks de metodologia aprovados
contra dados da cadeia de suprimentos e registrar resultados auditáveis. A Carrot não cria
metodologias, frameworks de verificação ou aplicações de dMRV. Ela aprova metodologias, frameworks
e aplicações de terceiros para uso no Ecossistema 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 ao Ecossistema 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#the-role-of-the-recycler) 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.
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 mintam tokens de crédito fungíveis (TCC e TRC). Cada metodologia emite créditos sob seu próprio símbolo on-chain (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** — Atividades on-chain — do minting à [aposentadoria de créditos](/docs/protocol/credit-retirement) — são visualizáveis pelo [Carrot Explorer](/docs/protocol/explorer) ou por qualquer [explorador de blockchain](/docs/glossary#blockchain-block-explorer). Auditores, compradores de créditos, reguladores ou qualquer pessoa podem verificar os dados on-chain de forma independente.
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, embarques, 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)).
## Prova de Autoridade [#prova-de-autoridade]
Prova de Autoridade (Proof-of-Authority, PoA) é o mecanismo que garante a integridade dos dados e a confiança no Ecossistema 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) é uma camada de aprendizado de máquina que monitora continuamente os dados de dMRV, detectando anomalias e padrões suspeitos nos dados da cadeia de suprimentos. Quando irregularidades são identificadas, o sistema sinaliza eventos para revisão adicional ou bloqueia a emissão de créditos até que os problemas sejam resolvidos. 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 on-chain. 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 minting 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.
# Explorer
## O que é o Carrot Explorer? [#o-que-é-o-carrot-explorer]
O Carrot Explorer ([explore.carrot.eco](https://explore.carrot.eco)) é a interface pública da plataforma de verificação da Carrot. Ele apresenta dados públicos, imutáveis e auditáveis de forma amigável — tornando as alegações ambientais do Ecossistema Carrot verificáveis de forma independente, sem depender de ferramentas técnicas ou interfaces brutas de blockchain.
## Seções principais [#seções-principais]
O Explorer é 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 de tokens também estão disponíveis no Explorer.
Nem tudo no Explorer é armazenado na blockchain. Apenas certos dados são escritos on-chain — por exemplo, [MassIDs](/docs/protocol/mass-ids) mintados, [Certificados](/docs/protocol/certificates), tokens de [crédito](/docs/protocol/credits), 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 Explorer apresenta tanto dados on-chain 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 on-chain — MassIDs mintados, Certificados, créditos, recibos de compra e aposentadoria — são respaldados por transações na blockchain e apresentados no Explorer 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.
## 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 Explorer 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 Explorer** | 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 Explorer torna as alegações ambientais do Ecossistema 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)
# 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 on-chain.
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 Explorer](/docs/protocol/explorer) ([explore.carrot.eco](https://explore.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, entregas e remessas — tipo de material, peso e os participantes envolvidos |
| **Auditorias de instalações** | Verificação por terceiros das operações da instalação, status de homologação e produtividade de material |
| **Resultados ambientais** | Confirmações de reciclagem e tratamento biológico, incluindo quantidades certificadas e métodos de processamento |
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. Exemplos dos frameworks atuais:
* **Envio de documento MassID** — Quando um Integrador envia um documento MassID com eventos da cadeia de suprimentos, a plataforma o encaminha para a metodologia aplicável e executa as regras de validação de MassID do framework. 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)).
* **Processamento de ordem de crédito** — Quando um documento de ordem de crédito é processado, as regras de ordem de crédito da metodologia (como distribuição de recompensas) são executadas.
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 Explorer.
### 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 Explorer, para que o progresso da execução e os resultados estejam disponíveis em tempo real.
### 3. Finalizar [#3-finalizar]
Após todas as regras serem concluídas, 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 resultados finais são registrados on-chain de forma imutável e refletidos no Carrot Explorer.
## 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 100% dos critérios aplicáveis do framework por meio de validação em código. Se qualquer critério obrigatório falhar, o MassID não fica elegível para emissão de certificado ou geração de crédito até que o problema seja corrigido conforme o framework aplicável.
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 Explorer, 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
* [Minting On-Chain](/docs/protocol/on-chain-minting) — Como MassIDs verificados se tornam ativos on-chain
* [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) ao [Ecossistema 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 do Ecossistema 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 Lixeiras, Transportadores, Processadores e Recicladores](/docs/protocol/supply-chain). Ao se integrar ao Ecossistema 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 o Ecossistema 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 ao Ecossistema 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 ao Ecossistema 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]
O Ecossistema 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.
* **O Ecossistema 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 do Ecossistema Carrot acontecem em segundo plano. Geradores de Resíduos ganham recompensas pela qualidade da separação, 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 das recompensas geradas quando MassIDs que ajudaram a rastrear chegam a um Reciclador certificado e são convertidos em [Créditos de Reciclagem Tokenizados (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc) ou [Créditos de Carbono Tokenizados (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc). 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 e quanto mais material chega à reciclagem certificada, 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]
O Ecossistema 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#the-mvf-author-role) são incentivados por meio de uma parcela das receitas de compra de créditos, incentivando a inovação em toda a rede.
Essa abordagem distribuída permite que o Ecossistema 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 expertise de domínio e relacionamento com clientes; o Ecossistema 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)
# Distribuição de Recompensas
## Como as recompensas funcionam [#como-as-recompensas-funcionam]
Quando [uma quantidade de créditos é comprada](/docs/protocol/credit-purchase), a receita é distribuída de volta para cada participante que contribuiu para o trabalho ambiental que esses créditos representam. Este é o mecanismo central de incentivo do Ecossistema 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#the-mvf-author-role) e [Desenvolvedores de MvA](/docs/standard/concepts/mva#the-mva-developer-role), e o próprio Ecossistema Carrot sejam todos recompensados por suas contribuições verificadas.
As recompensas são pagas em [USDC](/docs/glossary#usdc) (uma stablecoin atrelada ao dólar americano), proporcionando aos participantes **valor estável** sem exposição à volatilidade de preços de criptomoedas. Os participantes podem sacar suas recompensas em **moeda fiduciária ou cripto** de acordo com suas necessidades. Consulte a [Política de Distribuição de Recompensas](/docs/standard/policies/rewards-distribution#payment-currency-and-withdrawal) 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 peso [#etapa-1-divisão-por-peso]
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)). A receita é dividida entre esses MassIDs proporcionalmente ao peso de cada MassID na alocação. Um MassID representando 10 kg em uma alocação de 1.000 kg (1 tonelada) recebe 1% da receita total daquela compra.
### 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 |
| **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) |
| **Ecossistema Carrot** | N | Fornece o protocolo e a infraestrutura de contratos inteligentes para verificação, emissão, registro e distribuição de recompensas |
Os percentuais totais de todas as categorias sempre somam 100% do valor do MassID. As quatro primeiras categorias (G a R) são os [participantes da cadeia de suprimentos](/docs/protocol/supply-chain) que manuseiam fisicamente os resíduos. As categorias restantes (I, A, D, N) são participantes do ecossistema que fornecem a infraestrutura digital, os [frameworks de metodologia](/docs/standard/concepts/mvf) e [MvAs](/docs/standard/concepts/mva), e a infraestrutura de rede que viabilizam a execução da metodologia e a geração de créditos. Para a lista completa de participantes — incluindo o Fundo de Impacto Comunitário — e os percentuais detalhados 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 — a parcela é dividida entre eles.
## 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.
Quando o Gerador de Resíduos não é identificado:
* **100% da parcela do Gerador de Resíduos** é redirecionada para o **Fundo de Impacto Comunitário** — um fundo coletivo para projetos socioambientais no território onde a reciclagem ocorreu.
* **Todos os outros participantes logísticos e de serviço** (Transportadores, Processadores, Recicladores) 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 Fundo de Impacto Comunitário.
O Fundo de Impacto Comunitário apoia projetos ambientais, sociais e de inovação alinhados com os princípios da economia circular. Com o tempo, o Fundo evoluirá para participação comunitária progressiva em sua governança.
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 — todos os participantes recebem 100% de suas recompensas alocadas. 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]
Os participantes reivindicam recompensas acumuladas por meio de um **mecanismo on-chain com preservação de privacidade**. Durante cada compra de créditos, uma raiz de Merkle é registrada on-chain representando a distribuição completa de recompensas para aquela transação. Essa raiz compromete a distribuição completa sem revelar valores individuais ou identidades publicamente.
As identidades dos participantes são **anonimizadas on-chain**. Nenhum identificador de participante é armazenado publicamente — cada participante é representado por um hash com escopo de compra, impedindo correlação entre compras por observadores externos. Um observador pode verificar que uma distribuição é válida, mas não pode determinar qual participante do mundo real corresponde a uma determinada entrada.
Ao reivindicar, os participantes podem receber pagamentos em moeda fiduciária ou cripto conforme descrito acima. Cada reivindicação é verificada contra a raiz de Merkle on-chain 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. Isso impede que a plataforma movimente fundos unilateralmente.
Nenhuma das partes pode reivindicar recompensas unilateralmente. O backend não pode redirecionar recompensas para uma carteira diferente sem a assinatura do participante, e o participante não pode reivindicar sem passar pela verificação de identidade. Este design garante:
* **Privacidade** — Nenhum identificador de participante é armazenado on-chain; apenas hashes com escopo de compra aparecem na árvore de Merkle.
* **Verificabilidade** — Cada reivindicação é verificada contra a raiz de Merkle comprometida, garantindo a correção da distribuição.
* **Segurança** — Dupla assinatura impede tanto reivindicações não autorizadas quanto movimentação unilateral de fundos.
## 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 e localização para otimizar o desempenho da reciclagem em mercados específicos.
Por exemplo, a Foundation poderia aumentar a parcela do Gerador de Resíduos em um município lançando um novo programa de separação na fonte para impulsionar a participação, ou ajustar a parcela do Transportador em regiões onde os custos de transporte são uma 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 o [Ecossistema 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 do Ecossistema 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]
Seis categorias de papéis definem quem faz o quê na cadeia de suprimentos da reciclagem:
| Papel | Responsabilidade | Elegibilidade para recompensa |
| -------------------------- | ------------------------------------------------------------------- | ---------------------------------------------------------------- |
| **Gerador de Resíduos** | Produz resíduos e realiza a triagem na origem | Sim — recompensado pela qualidade da triagem |
| **Custodiante de Lixeira** | Gerencia lixeiras de coleta e pontos de entrega | Sim — recompensado pela infraestrutura de lixeiras |
| **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 e processamento (duplo papel) |
| **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 sempre recebe crédito por dois papéis: Processador (recebimento e triagem) e Reciclador (execução da reciclagem ou tratamento biológico certificado).
Além dos participantes da cadeia de suprimentos, o Ecossistema 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#the-mvf-author-role), o [Desenvolvedor do MvA](/docs/standard/concepts/mva#the-mva-developer-role) e o próprio **Ecossistema Carrot** (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.
## 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. Um evento de embarque cobre tanto a coleta quanto a entrega, 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) do Ecossistema 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 tokenização em [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.
* **Custodiantes de Lixeiras** abrem caminho para empresas privadas e parcerias público-privadas patrocinarem redes de lixeiras, 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 receita adicional 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 descentralizado 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 da cadeia mostra a sequência de participantes do gerador de resíduos ao gestor de contentor, transportador, processador e reciclador, com o Integrador de Rede conectado abaixo do grupo. A mensagem é que a evidência operacional vem de vários repasses, enquanto o integrador coordena a cadeia como papel voltado à rede, não como outra etapa de processamento.
# 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)** (impacto tokenizado)
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** | Certificado tokenizado representando impacto verificado | TRC (ex.: `C-BIOW` do BOLD Recycling), TCC (ex.: `C-CARB.CH4` do BOLD Carbon (CH₄)) |
## 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 mintados a partir dos Certificados e [recompensas](/docs/protocol/rewards-distribution) são distribuídas 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 no ecossistema 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)) no [Ecossistema 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.
* Regras aprovadas geram uma trilha de auditoria explicando o que foi verificado.
* Os MassIDs que passam na verificação de metodologia geram [Certificados](/docs/protocol/certificates), e os [Créditos](/docs/protocol/credits) correspondentes são mintados.
* [Recompensas](/docs/protocol/rewards-distribution) são distribuídas aos participantes da [cadeia de suprimentos](/docs/protocol/supply-chain) de acordo com a política de distribuição da metodologia.
## 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 determinísticos PASSED ou FAILED com explicações.
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 ou falhou.
Cada regra é uma função determinística: dado o mesmo documento de entrada e a mesma versão da regra, 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 ou FAILED é vinculado aos dados de origem específicos que foram avaliados, tornando os resultados verificáveis de forma independente.
* **Determinismo** — A mesma entrada sempre produz a mesma saída. Sem aleatoriedade, sem estado externo que possa alterar resultados entre execuções.
* **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 ou FAILED 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 ou FAILED.
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 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 APROVADO/REPROVADO com critérios claros |
| **Fórmulas** | Define cálculos de emissões, quantificação de créditos e fórmulas de distribuição de recompensas |
| **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#inputs-evidence--evidence-policy) 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 APROVADO (com uma explicação do que foi verificado) ou REPROVADO (com o motivo específico).
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 mintados.
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**: [Geradores de resíduos](/docs/protocol/supply-chain), [transportadores](/docs/protocol/supply-chain), [processadores](/docs/protocol/supply-chain) e [recicladores](/docs/protocol/supply-chain#the-role-of-the-recycler) homologados com documentação válida
* **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; percentuais de distribuição de recompensas por tipo de ator
* **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#the-role-of-the-recycler)", "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 a quantidade de [Créditos de Carbono Tokenizados (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc) e [Créditos de Reciclagem Tokenizados (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc) que podem ser gerados a partir da compostagem de resíduos orgânicos. Selecione um cenário de referência, tipo de resíduo e volume para ver as projeções de créditos e uma estimativa ilustrativa de receita.
## Recursos relacionados [#recursos-relacionados]
* [Parâmetros de cálculo de emissões](/docs/methodologies/ams-iii-f/bold-carbon#emission-calculation-parameters) — 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 a receita é distribuída 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 o [Ecossistema 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 ou FAILED com uma explicação.
A explicação em `evaluateResult()` é crítica — ela deve declarar o que foi verificado e por que o resultado é PASSED ou FAILED. 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 PASSED ou FAILED 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
* 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 o [Ecossistema 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:
* **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
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#the-mvf-author-role), 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 (TCC ou TRC) vinculado, 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. No ecossistema 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 Explorer](/docs/protocol/explorer) 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
## 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 resíduos orgânicos forem reivindicados tanto para um crédito de reciclagem quanto para um crédito de carbono com base na mesma atividade de compostagem, o impacto ambiental seria contado duas vezes — comprometendo a integridade de todo o sistema de créditos.
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#the-role-of-the-recycler), [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 do [Ecossistema 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 Explorer](/docs/protocol/explorer) e na blockchain.
## 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 o ecossistema 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 a receita de compras de [Créditos Tokenizados de Reciclagem (TRC)](/docs/protocol/credits#tokenized-recycling-credits-trc) e [Créditos Tokenizados de Carbono (TCC)](/docs/protocol/credits#tokenized-carbon-credits-tcc) é distribuída entre os participantes. Os compradores adquirem 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). A receita é dividida entre os MassIDs subjacentes proporcionalmente ao peso de cada MassID na alocação, e depois distribuída 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.
**Versão atual:** v1.0 (Ratificada em 22 de janeiro de 2024)
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.
## Moeda de pagamento e saque [#moeda-de-pagamento-e-saque]
As recompensas são pagas em [USDC](/docs/glossary#usdc) (uma stablecoin atrelada ao dólar americano). Os participantes podem sacar suas recompensas em **moeda fiduciária ou cripto** — pagamentos em moeda fiduciária são realizados off-chain por meio de provedores de pagamento integrados, enquanto saques em cripto utilizam o saldo on-chain em USDC. Usar USDC como moeda de liquidação proporciona aos participantes **valor estável** sem exposição à volatilidade de preços de criptomoedas, mantém a liquidação do protocolo consistente on-chain e permite que os participantes escolham como receber valor (fiduciário ou cripto) 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 |
| 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) |
| CP | Fundo de Impacto Comunitário | Fundo para projetos socioambientais no território local |
| 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) |
| N | Ecossistema Carrot | Fornece o protocolo e a infraestrutura de contratos inteligentes para verificação, emissão, registro e distribuição de recompensas |
## 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%), H (10%), P (10%), R (20%), I (8%), A (1%), D (1%), N (20%)
**Compostagem de lodo de estações de tratamento de resíduos:**
G (25%), H (5%), P (10%), R (30%), I (8%), A (1%), D (1%), N (20%)
**Compostagem de resíduos da indústria do tabaco:**
G (25%), H (5%), P (10%), R (30%), I (8%), A (1%), D (1%), N (20%)
G (20%), H (20%), P (15%), R (15%), I (8%), A (1%), D (1%), N (20%)
G (20%), H (20%), P (15%), R (15%), I (8%), A (1%), D (1%), N (20%)
G (25%), H (10%), P (20%), R (15%), I (8%), A (1%), D (1%), N (20%)
G (25%), H (15%), P (15%), R (15%), I (8%), A (1%), D (1%), N (20%)
Use a [Calculadora de Créditos](/docs/standard/guides/credit-calculator) para ver uma estimativa
ilustrativa de receita para um determinado tipo e volume de resíduo.
## Descontos nas recompensas [#descontos-nas-recompensas]
### Incentivo à digitalização da cadeia de suprimentos [#incentivo-à-digitalização-da-cadeia-de-suprimentos]
Um **desconto padrão de 25%** é aplicado a todos os prestadores de serviços logísticos (Recicladores, Processadores, Transportadores) quando o [Gerador de Resíduos](/docs/protocol/supply-chain) não é identificado na cadeia de custódia. 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%** nas recompensas do Gerador de Resíduos se aplica em dois cenários:
1. **Geradores de Resíduos sem cadastro concluído** — Geradores de Resíduos que ainda não concluíram o processo de cadastro receberão um desconto de 50% nas recompensas de todos os créditos emitidos antes da data de conclusão do cadastro. Uma vez concluído o cadastro, apenas os créditos emitidos a partir dessa data são elegíveis para alocação integral de recompensas; os créditos emitidos antes da data de conclusão do cadastro permanecem sujeitos ao desconto de 50%. Esse desconto garante a aplicação uniforme da política enquanto a formalização e a verificação de registro permanecem pendentes, funcionando como um mecanismo de incentivo para impulsionar a conclusão do cadastro. Em termos práticos, a regra reforça o princípio de que a redistribuição integral de recompensas depende de condições mínimas de elegibilidade e rastreabilidade dentro da rede, assegurando transparência, governança e previsibilidade para todos os stakeholders do ecossistema.
2. **Grandes Empresas** — Geradores de Resíduos classificados como Grandes Empresas (receita superior a USD 4 milhões no ano-calendário anterior) recebem 50% de suas recompensas alocadas após o cadastro. Isso calibra os incentivos proporcionalmente, preservando a motivação para participação.
### Fundo de Impacto Comunitário [#fundo-de-impacto-comunitário]
Os valores descontados de ambos os cenários acima são direcionados ao **Fundo de Impacto Comunitário** — um fundo coletivo para projetos socioambientais no território onde a reciclagem ocorreu. O Fundo apoia projetos ambientais, sociais e de inovação alinhados com os princípios da economia circular. Com o tempo, o Fundo evoluirá para participação comunitária progressiva em sua governança.
[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.
* **Meritocracia** — A melhor proposta vence, independentemente de quem a submete.
* **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 financia a construção de infraestrutura — pátios de compostagem, 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)) no [Ecossistema 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** e o valor a ser enviado como `LOCAL_WASTE_CLASSIFICATION_ID`; a **Descrição** e 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#the-role-of-the-recycler)** — 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 do Ecossistema 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), NFTs de [Certificado](/docs/protocol/certificates) e tokens de [Crédito](/docs/protocol/credits) em uma única operação coordenada. 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
* Minta um `CreditPurchaseReceipt` como prova permanente
* Registra as alocações de recompensas para os participantes
O CreditPurchaseManager também suporta **aposentadoria integrada** — comprar e aposentar créditos em uma única transação, o que elimina a necessidade de uma etapa separada de aposentadoria.
### 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 imutáveis e rastreáveis. 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 e os detalhes individuais de recompensa privados — apenas compromissos hasheados são armazenados publicamente. 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 no Ecossistema Carrot são **soulbound** — não transferíveis e mantidos permanentemente pelo Vault. Isso garante uma trilha de auditoria imutável e à prova de adulteração. Nenhum NFT pode ser movido, vendido ou ocultado após o minting.
### 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 aos seus MassIDs 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 dos outros três). Esse modelo contábil é central para a prevenção de dupla contagem — o contrato garante que créditos não possam ser vendidos ou aposentados além do saldo disponível.
### CreditPurchaseReceipt [#creditpurchasereceipt]
Prova imutá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 Explorer](/docs/protocol/explorer) 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 Explorer](/docs/protocol/explorer) 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. O Ecossistema 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 é fundamental para o modelo de atualização — quando um contrato é atualizado para uma nova implementação, apenas a entrada no registro precisa ser alterada. Todos os contratos dependentes descobrem automaticamente o novo endereço sem necessidade de reimplantação.
### 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 até os lotes específicos de resíduos que ele representa por meio deste registro. 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 ou mais MassIDs lastreiam cada certificado.
* **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é os lotes específicos de resíduos que o produziram.
## 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 blockchain [#por-que-blockchain]
O Ecossistema 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** — Uma vez que um crédito é emitido, seus dados de proveniência não podem ser alterados ou excluídos. Cada emissão, compra e aposentadoria é permanentemente registrada on-chain, enquanto a lógica contratual no nível do protocolo (verificações de uso único, queima de tokens 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 Explorer](/docs/protocol/explorer) 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** — Ativos tokenizados 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 Explorer](/docs/protocol/explorer), 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 do Ecossistema 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 e dados armazenados permanecem os mesmos — apenas a lógica muda. 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: quando um contrato é atualizado para uma nova implementação, apenas a entrada no registry precisa mudar. Todos os outros contratos descobrem automaticamente a nova versão através do registry, sem necessidade de reimplantação própria. Isso significa que contratos individuais podem ser melhorados, corrigidos ou estendidos sem exigir uma reimplantação de todo o sistema.
### NFTs soulbound [#nfts-soulbound]
Todos os NFTs no Ecossistema 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. Cada [MassID](/docs/protocol/mass-ids), [certificado](/docs/protocol/certificates), recibo de compra e recibo de aposentadoria permanece exatamente onde foi criado, formando uma cadeia inquebrável de evidências.
### Meta-transações [#meta-transações]
O sistema suporta **transações sem gas** por meio de relayers de meta-transações. Isso significa que os usuários finais não precisam possuir criptomoedas ou pagar taxas de transação da blockchain — o relayer envia transações em seu nome, removendo uma barreira significativa para adoção por compradores que não são nativos do universo cripto.
### 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. Nenhuma conta individual pode realizar todas as operações. Essa separação de responsabilidades garante que, mesmo se uma chave for comprometida, o dano seja contido.
### Pausabilidade [#pausabilidade]
Operações críticas podem ser pausadas em emergências para interromper toda a atividade enquanto uma vulnerabilidade ou incidente é investigado. Pausas emergenciais **expiram automaticamente após 48 horas** para evitar bloqueios indefinidos — garantindo que a rede não possa ser permanentemente congelada, mesmo nos piores cenários. Consulte [Segurança](/docs/protocol/smart-contracts/security) para o modelo completo de controle de acesso e pausabilidade.
## 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) do Ecossistema Carrot executam cinco fluxos on-chain principais. Cada fluxo é projetado para ser **atômico** — ou todos os passos são concluídos com sucesso ou nenhum deles é, prevenindo alterações parciais de estado.
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 Explorer](/docs/protocol/explorer) 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 uma operação coordenada.
### 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 — Transferência de créditos [#passo-4--transferência-de-créditos]
Tokens de crédito (por exemplo, `C-BIOW`, `C-CARB.CH4`) são transferidos do Vault para o endereço da carteira do comprador. Neste ponto, o comprador detém tokens de crédito fungíveis que pode manter ou aposentar.
### Passo 5 — Minting do recibo [#passo-5--minting-do-recibo]
Um NFT **`CreditPurchaseReceipt`** é mintado para o Vault como prova permanente e imutá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]
Se o comprador optar pela **aposentadoria integrada**, os créditos são queimados (em vez de transferidos ao comprador) na mesma transação, e um `CreditRetirementReceipt` também é mintado. Isso permite que compradores adquiram e aposentem créditos em um único passo — útil para quem pretende reivindicar imediatamente a compensação ambiental.
## 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 são anonimizadas — 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 detentor. 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 Explorer, 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 do Ecossistema Carrot.
### Revogação de MassID [#revogação-de-massid]
Revogar um MassID aciona uma revogação **em cascata**:
* Todos os certificados vinculados ao MassID revogado são automaticamente revogados.
* Quaisquer créditos não vendidos respaldados por esses certificados são queimados.
* **Proteção**: A revogação é bloqueada se quaisquer créditos dos certificados vinculados já tiverem sido vendidos. Isso impede a invalidação retroativa de créditos que compradores já adquiriram de boa-fé.
### 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]
A revogação preserva a trilha de auditoria completa. Os metadados IPFS originais dos ativos revogados permanecem acessíveis, e o motivo da revogação é registrado on-chain. Isso garante que mesmo ativos revogados possam ser examinados por auditores e reguladores — nada é ocultado ou excluído, apenas marcado como inválido.
## 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 no Ecossistema 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 do Ecossistema Carrot implementam múltiplas camadas de segurança:
### Controle de Acesso Baseado em Funções (RBAC) [#controle-de-acesso-baseado-em-funções-rbac]
Cada função de contrato é restrita a funções autorizadas específicas. Nenhuma conta individual pode realizar todas as operações. 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. Pausas emergenciais expiram automaticamente após 48 horas para evitar bloqueios indefinidos, garantindo que mesmo uma conta emergencial comprometida não possa congelar permanentemente o sistema.
As funções de admin, operador, atualizador e pauser são mantidas por **carteiras multi-assinatura** — o que significa que múltiplas partes autorizadas devem aprovar qualquer ação antes que ela seja executada. O pauser emergencial é a exceção: é uma conta individual de propriedade externa para permitir resposta rápida quando cada segundo importa.
### 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 automaticamente após 48 horas — proporcionando uma rede de segurança que equilibra resposta rápida a incidentes com proteção contra negação de serviço permanente.
### 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 no Ecossistema 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** — Rastreia o comportamento dos participantes em toda a rede, identificando padrões que indicam maus atores. Operações sensíveis podem ser restringidas por limites de reputação, garantindo que apenas participantes confiáveis as acessem.
* **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 e podem incluir suspensão da participação no minting de créditos, congelamento de carteira ou restrições de conta.
## 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** ou **FAILED** 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 em três escopos: validação de MassID, emissão de [certificado GasID](/docs/protocol/certificates#gasid) e liquidação de ordem de [crédito](/docs/protocol/credits).
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 Explorer](https://explore.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.
## Regras de GasID [#regras-de-gasid]
Estas regras são executadas após todas as regras de MassID passarem e o [certificado GasID](/docs/protocol/certificates#gasid) ser emitido.
## Regras de ordem de crédito [#regras-de-ordem-de-crédito]
Estas regras são executadas quando documentos de ordem de [crédito](/docs/protocol/credits) são processados.
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.
> 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 ou FAILED 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).
* Todos os participantes ([Gerador de Resíduos](/docs/protocol/supply-chain), [Transportador](/docs/protocol/supply-chain), [Processador](/docs/protocol/supply-chain), [Reciclador](/docs/protocol/supply-chain#the-role-of-the-recycler)) possuem documentos de [homologação](/docs/protocol/network-integrators) válidos.
* 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 (com homologação)
* 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#supported-waste-codes) 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. Executa as regras de GasID (distribuição de recompensas para participantes da [cadeia de suprimentos](/docs/protocol/supply-chain)).
3. Gera 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))) após a liquidação da ordem de crédito.
## 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#common-issues) 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** ou **FAILED** 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 em três escopos: validação de MassID, emissão de [certificado RecycledID](/docs/protocol/certificates#recycledid) e liquidação de ordem de [crédito](/docs/protocol/credits).
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 Explorer](https://explore.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.
## Regras de RecycledID [#regras-de-recycledid]
Estas regras são executadas após todas as regras de MassID passarem e o [certificado RecycledID](/docs/protocol/certificates#recycledid) ser emitido.
## Regras de Ordem de Crédito [#regras-de-ordem-de-crédito]
Estas regras são executadas quando documentos de ordem de [crédito](/docs/protocol/credits) são processados.
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.
> 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 ou FAILED 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).
* Todos os participantes ([Gerador de Resíduos](/docs/protocol/supply-chain), [Transportador](/docs/protocol/supply-chain), [Processador](/docs/protocol/supply-chain), [Reciclador](/docs/protocol/supply-chain#the-role-of-the-recycler)) possuem documentos de [homologação](/docs/protocol/network-integrators) válidos.
## 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`. Cada um deve ter um documento de homologação válido
(regra 4 — Participant Accreditations & Verifications).
| Participante | Obrigatório? | Condições |
| ------------------- | ------------ | -------------------------------------------------------------------------------------------------------- |
| Integrador | Sim | Deve ter homologação válida com datas válidas. |
| 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). |
Cada evento ACTOR deve incluir os dados de homologação e endereço do participante (usados pela regra 7 — Geolocation Precision, que valida endereços de eventos contra endereços homologados usando limiares de distância escalonados).
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. Executa regras de RecycledID (distribuição de recompensas para participantes da [cadeia de suprimentos](/docs/protocol/supply-chain)).
3. Gera tokens de crédito [C-BIOW](/docs/protocol/credits#tokenized-recycling-credits-trc) (Créditos de Reciclagem Tokenizados) após a liquidação da ordem de crédito.
## 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** — Todos os participantes devem ter documentos de homologação válidos e não expirados no momento da submissão do evento.
* **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)