Become an issuer

An issuer is an account that holds ISSUER_ROLE on CarbonCreditNFT. It is the only kind of account that can create credits (mintCredit, batchMint). There is no public mint, no faucet and no starter pack. This page is the onboarding policy for issuers and explains what the contracts do and do not check.

What an issuer can and cannot do

ORACLE_ROLE (a separate role, not held by issuers by default) can rewrite the proof hash and satellite CID of an existing credit with updateVerification; it cannot change the serial, tonnes or owner.

Onboarding policy

The operator of a deployment decides who becomes an issuer. The recommended policy is:

An admin can revoke ISSUER_ROLE at any time. Revocation stops new issuance; it does not affect credits that already exist.

Two ways to become an issuer

Honest caveats:

• A bond is a deterrent, not verification. Locking CARB does not prove that your credits are real. An open bond path lets anyone willing to lock the bond create credits, so the recommendation is to keep it closed until off-chain verification and an appeals process exist.
• Slashing is real loss. A slash proposal opens a dispute window (default 7 days), during which you cannot unbond or withdraw. You may dispute with an evidence hash; a disputed proposal needs an explicit slasher decision. Slashed CARB is burned by default.
• Exit takes time. startUnbond revokes the bond-granted role at once; withdrawal follows after the unbond delay (default 30 days).
• Bonded CARB carries no votes, and the bond pays nothing.
• A direct grant can be revoked by the multisig at any time, and an address revoked that way can be barred from the bond path.
• CARB is not launched yet. See Issuer bond and Risks and legal. Not investment advice; not an offer.

Evidence an issuer must supply

Every credit carries an oracleProofHash (bytes32). In this deployment it is the SHA-256 of the evidence bundle for that credit (or for the batch it belongs to). The Issuer page can compute it in your browser from a file; the file is never uploaded. Keep the bundle: the hash only proves what the bundle contained when you issued.

The evidence bundle for a credit must contain at least:

1. Registry record of the serial(s): registry name, serial number or block, status, quantity (tonnes), vintage and holding account, as exported from the source registry.
2. Project documentation: project identifier, methodology and the validation and verification report that covers the vintage.
3. Lock or cancellation proof from the source registry showing that the credit was taken out of circulation there (or is held in an account that will not be used) before it was tokenized. Without this, the same tonne could be sold twice, once in the source registry and once on Carbonized. The contracts cannot check this; it is the issuer's obligation.
4. Issuer attestation: a signed statement from the issuer's legal entity that the information is true, with the date.
5. Optional satellite or monitoring data (stored as an IPFS CID in satelliteDataCID).

Publish the bundle (or a redacted version plus the hash) at a location referenced by the credit's metadata URL (tokenURI), so buyers can check it.

Serial rules (one credit, one serial)

• A credit has exactly one serial string and a serial can be tokenized once, ever. mintCredit and batchMint revert with Credit already tokenized if the canonical form was used before, and the serial key is never cleared, not even after retirement.
• The canonical form trims ASCII whitespace and upper-cases a-z. vcs-123 and VCS-123 are the same serial. The methodology label is not part of the key, so relabelling does not create a new credit.
• Write the full serial with the registry prefix as the registry shows it (for example VCS-...). Different spellings of the same registry serial (with or without prefix, extra separators) are different strings to the contract.
• Serial blocks: if you tokenize a block of credits as one NFT, the serial string must identify the whole block, and blocks must never overlap. The contract compares whole strings only; it cannot detect overlapping ranges, so preventing overlap is the issuer's job.
• An empty or whitespace-only serial reverts with Serial required.
• The Issuer page checks isSerialTokenized live while you type and checks every serial of a CSV before sending anything.

Credit fields

After issuance: transfer, wrap, retire

• The recipient owns a normal ERC-721. It can be transferred, retired (burned with a public retirement certificate) or wrapped into the pooled CCT of its methodology.
• Wrapping succeeds only if the credit is not retired, has non-zero tonnes, a non-empty serial, a non-zero evidence hash and the methodology matches the pool exactly. The Tokenize page shows these reasons before any transaction is sent. See Tokenize.
• A wrapped NFT is locked in the CCT contract and must be unwrapped before it can be retired.
• Retirement is final and public: see Retire credits. A retired serial can never be issued again.

Batch issuance

Use the CSV tab on the Issuer page for more than a few credits. Columns: projectId, projectName, serialNumber, methodology, tonnes, vintageYear, geography, oracleProofHash, satelliteDataCID (optional), tokenURI. The page validates every row, flags serials repeated in the file or already tokenized onchain, groups rows by project and sends transactions of at most 25 credits (one credit costs roughly 0.5M gas, and a transaction is limited to about 16.7M gas). Each transaction is signed separately, and progress is stored in the browser so a failed or interrupted run can be resumed with the same CSV. Nothing is skipped silently: all rows must be valid before the first transaction is sent.

Recommended controls

What buyers should check

Before buying or retiring a credit: who issued it (verificationSource and the public issuer list), the serial in the source registry, the evidence hash and bundle, and the vintage and methodology. A retirement certificate proves that a token was burned, not that the project is real.

Issuer page · CarbonCreditNFT reference · Roles and security