ProtocolContracts & InteroperabilitySmart Contracts

Security

Security model — smart contract architecture, governance security, and anti-manipulation mechanisms.

Last updated on

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

The Carrot Network's smart contracts implement multiple security layers:

Role-Based Access Control (RBAC)

Privileged functions are gated by role, and separation of duties is validated when each contract is initialized, so the five roles start on five distinct addresses. That check runs at initialization only: DEFAULT_ADMIN_ROLE can grant any role afterwards, so keeping them separate is a governance discipline rather than something the contract re-enforces. Public entry points such as purchase and retire are open to any caller but execute only against an order signed by an authorized backend signer (see EIP-712 below). The system defines five standard roles:

  • DEFAULT_ADMIN_ROLE — Contract ownership and role management. This role can grant or revoke any other role.
  • UPGRADER_ROLE — Can upgrade contract implementations via UUPS proxy. Separated from admin to limit blast radius.
  • OPERATOR_ROLE — Day-to-day operations such as minting MassIDs, issuing certificates, and executing revocations.
  • PAUSER_ROLE — Standard pause mechanism for orderly operational halts.
  • EMERGENCY_PAUSER_ROLE — Circuit breaker for critical failures. An emergency pause carries a 48-hour expiry, but it does not lift itself: once the expiry passes, any account — not only a role holder — can call checkAndUnpause() to end it. A compromised emergency account can pause again as soon as a pause is lifted, so containment is revoking EMERGENCY_PAUSER_ROLE, not waiting the window out.

Governance is distributed across these distinct roles, each currently held by a separate holder, so day-to-day operation requires more than one party. Critical operations — contract upgrades and changes to critical parameters — require multi-party approval before they execute.

Pausability

Contracts can be paused in standard or emergency mode, halting operations if a vulnerability or attack is detected. Standard pauses require the PAUSER_ROLE and persist until explicitly unpaused. Emergency pauses, triggered by the EMERGENCY_PAUSER_ROLE, expire after 48 hours, so an emergency responder acting alone cannot hold a pause open indefinitely. While an emergency pause is active, the PAUSER_ROLE can extend it into an indefinite pause (extendPause), which is how a real incident is held open past that window.

UUPS upgradeability

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

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

All NFTs (MassIDs, certificates, receipts) are soulbound and held by the Vault 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 stays traceable. A MassID or certificate can be revoked while none of the credits issued from it has been sold, but its issuance, its revocation, and its original metadata URI stay in the public on-chain record.
  • 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

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

The Carrot Foundation implements systematic reward and punishment mechanisms that scale the cost of malicious behavior faster than any revenue it could generate:

  • Participant reputation tracking (planned) — A future mechanism to track participant behavior across the network, surfacing patterns that indicate bad actors, so that sensitive operations can be gated by reputation thresholds. It is not implemented today.
  • Wallet verification — Additional verification steps can be enacted if needed to increase security, which may trade ease of onboarding for stronger protections.
  • Moderation — The Foundation's oversight team can flag behavior violating community guidelines and limit access to reduce risk. Moderators also work to detect and penalize automated manipulation attempts (anti-botting).
  • Punitive measures — When violations are confirmed, penalties are issued through governance decisions. The Foundation can revoke a participant's platform membership, removing dashboard and API access; the operator role can revoke an issued MassID or certificate. There is no per-wallet freeze or blocklist in any contract — a pause halts every balance movement on the contract at once, never one holder's balance on its own.

Design philosophy

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 · Learn about governance

On this page