Herena Protocol

Decentralized Sustainability Verification on Hedera

Technical Whitepaper v1.1.0

Abstract

Herena is a decentralized protocol built on the Hedera network that incentivizes and verifies real-world sustainability actions through community-driven governance. Volunteers complete environmental tasks, submit cryptographic proof of completion to IPFS, and undergo a quadratic voting process where staked community members validate the work. Upon approval, rewards are autonomously distributed: 80% to the task completer and 20% to the verifying voters. The protocol's native token, HRN, serves as the medium of reward, staking, and governance participation, and is exchangeable with HBAR through a built-in constant-product automated market maker.

1. Introduction

Climate change and environmental degradation demand coordinated action at scale. While individuals and organizations increasingly seek to contribute, a fundamental trust problem persists: there is no widely accepted, tamper-proof mechanism to verify that environmental actions have actually occurred. Self-reporting is prone to fraud, centralized auditing is expensive and unscalable, and existing carbon credit markets are opaque.

Herena addresses this gap by constructing a transparent, blockchain-based verification pipeline. Sustainability tasks are published on-chain, completed by volunteers in the physical world, documented with rich-media proof stored on IPFS, and validated through decentralized community governance. Every step — from task creation to reward distribution — is recorded immutably on the Hedera ledger.

The protocol is composed of six interconnected smart contracts deployed on Hedera's EVM-compatible layer: a Treasury, an ERC-20 token (HRN), a TaskManager, a ProofManager, a VotingManager, and a SwapPool. Together, they form a self-contained economy for sustainability verification.

2. Protocol Architecture

The Herena protocol consists of six core contracts that interact in a defined lifecycle:

Treasury: Custodian of the protocol's HRN reserves. Funds are transferred to the TaskManager when tasks are created.
Herena (HRN): An ERC-20 token with a fixed initial supply of 1,000,000 HRN, minted entirely to the Treasury at deployment.
TaskManager: Stores task definitions on-chain, holds pre-funded reward budgets, and tracks completion counts.
ProofManager: Accepts proof submissions referencing IPFS URIs and automatically triggers governance proposals.
VotingManager: Runs time-bounded quadratic voting on each proof submission and distributes rewards upon approval.
StakingManager: Manages HRN staking positions and computes quadratic voting power.
SwapPool: A constant-product AMM enabling HRN/HBAR exchange with LP token mechanics.

3. Task Lifecycle

3.1 Task Creation

The protocol administrator publishes sustainability tasks through the TaskManager contract. Each task is defined by six parameters stored on-chain:

Description: A concise summary of the required action (e.g., “Plant 100 trees in community park”)
Metadata URI: An IPFS-hosted document containing detailed requirements, acceptance criteria, and supplementary media, rendered as rich text on the platform
Reward per completion: The HRN amount awarded for each verified completion
Maximum completions: The total number of participants that can complete the task
Deadline: The UNIX timestamp after which submissions are no longer accepted

At creation time, the full reward budget ( $\text{reward} \times \text{maxCompletions}$ ) is transferred from the Treasury to the TaskManager, ensuring that approved submissions are always fully funded. If a task is cancelled before all slots are filled, unused funds are returned to the Treasury.

3.2 Proof Submission

Volunteers complete the real-world action and submit proof through the ProofManager. The proof artifact — which may include photos, text, and other evidence — is structured as a TipTap rich-text JSON document, uploaded to IPFS, and referenced on-chain by its content identifier (CID).

The protocol enforces a one submission per user per task constraint on-chain, preventing duplicate claims. Upon successful submission, the ProofManager automatically calls the VotingManager to create a governance proposal for community review.

3.3 Verification & Resolution

Each proof submission triggers a time-bounded voting period (default: 48 hours). Community members with staked HRN review the proof and cast either an approval or rejection vote. Voting power is determined by the quadratic formula described in Section 4.

After the voting period ends, anyone may call the permissionless resolveProposal function. If approval votes exceed rejection votes, the task completion count is incremented and rewards are distributed. If the proposal is rejected, no rewards are paid and the completion slot is not consumed.

4. Quadratic Voting

Herena employs quadratic voting to prevent plutocratic capture of the verification process. Rather than using a one-token-one-vote model where large holders can unilaterally control outcomes, the protocol computes voting power as the square root of staked tokens:

P(s) = \lfloor\sqrt{s}\rfloor

where $s$ is the amount of HRN staked (in token units)

This creates a diminishing-returns curve: each additional unit of influence requires quadratically more capital. The practical effect is that many small stakeholders collectively outweigh a single large stakeholder.

Voting Power Table

HRN Staked	Voting Power	Marginal Cost
1	1	1 HRN per vote
4	2	3 HRN for 2nd vote
100	10	19 HRN for 10th vote
10,000	100	199 HRN for 100th vote

Voters must maintain a minimum stake of 1 HRN to participate. Each voter may cast a single vote (approve or reject) per proposal, and their full quadratic voting power is applied. Staked tokens are not consumed by voting — they remain staked and continue accumulating power across proposals.

5. Reward Distribution

When a proposal is approved, the task's reward per completion is distributed according to a fixed 80/20 split:

R_{\text{submitter}} = \left\lfloor\frac{R \cdot 80}{100}\right\rfloor

R_{\text{voters}} = R - R_{\text{submitter}}

80% to the proof submitter — the volunteer who completed the sustainability task
20% to approving voters — distributed proportionally to each voter's quadratic voting power

The voter reward for each approving voter $i$ is:

r_i = \left\lfloor\frac{R_{\text{voters}} \cdot P_i}{\sum_{j \in A} P_j}\right\rfloor

where $A$ is the set of approve voters and $P_i$ is voter $i$ 's quadratic voting power

This mechanism incentivizes honest verification: voters are financially rewarded for correctly validating genuine sustainability work, while approving fraudulent submissions risks reputation damage and loss of future rewards if the broader community catches on.

6. HRN Token

6.1 Token Specification

Name	Herena
Symbol	HRN
Standard	ERC-20 (with ERC-20 Burnable extension)
Decimals	18
Initial Supply	1,000,000 HRN
Minting	Fixed supply — no additional minting function exposed

6.2 Token Utility

Task rewards: Distributed to volunteers upon verified completion of sustainability tasks
Voter rewards: Earned by stakers who participate in governance verification
Staking: Required to participate in DAO governance; minimum stake is 1 HRN
Burn: Token holders may permanently burn HRN, reducing total supply

6.3 Staking Mechanics

Users stake HRN into the StakingManager contract to gain voting power. Staking and unstaking are immediate with no lockup period, except that unstaking is blocked while the user has active (unresolved) proposals to prevent vote manipulation. The minimum stake threshold of 1 HRN ensures a meaningful economic commitment from all participants.

6.4 Token Distribution

The entire supply of 1,000,000 HRN is minted to the Treasury contract at deployment. Tokens flow into the economy through two initial channels:

Task Rewards — 79.2%

Voter Rewards — 19.8%

AMM Liquidity — 1%

Allocation	Amount	Description
Task Rewards	792,000 HRN (79.2%)	Paid to volunteers who complete and verify sustainability tasks (80% of the 990,000 disbursable pool)
Voter Rewards	198,000 HRN (19.8%)	Distributed proportionally to stakers who approve valid proofs (20% of the 990,000 disbursable pool)
AMM Liquidity	10,000 HRN (1%)	Seeded into the HRN/HBAR SwapPool at genesis alongside 100 HBAR, establishing an initial exchange rate

Tokens remain in the Treasury until tasks are created. At task creation, the full reward budget ( $\text{reward} \times \text{maxCompletions}$ ) is transferred to the TaskManager. Upon approval, 80% flows to the volunteer and 20% is split among approving voters proportionally to their quadratic voting power. If a task is cancelled before all slots are filled, unused funds are returned to the Treasury, ensuring no tokens are lost.

This model ensures that every HRN token entering circulation is backed by a verified sustainability action. There is no team allocation, no vesting schedule, and no inflationary mechanism — the fixed supply is distributed purely through participation in the protocol.

7. HRN / HBAR Swap Pool

The protocol includes a built-in constant-product automated market maker (AMM) enabling users to exchange between HRN and native HBAR. This facilitates frictionless onboarding without dependence on external exchanges.

7.1 Pricing Formula

The swap pool maintains the constant-product invariant:

x \cdot y = k

where $x$ = HBAR reserve, $y$ = HRN reserve, $k$ = invariant constant

A 0.3% fee is collected on each swap by applying a 997/1000 multiplier to the input amount before computing the output:

\Delta y = \frac{(\Delta x \cdot 997) \cdot y}{x \cdot 1000 + \Delta x \cdot 997}

7.2 Liquidity Provision

Liquidity providers deposit HRN and HBAR in equal proportion and receive HRN-LP tokens representing their pool share. The initial LP mint uses the geometric mean:

LP_{\text{initial}} = \sqrt{\Delta x \cdot \Delta y}

Subsequent deposits must maintain the exact reserve ratio. Withdrawal is proportional: burning LP tokens returns the corresponding share of both HBAR and HRN reserves.

8. Off-Chain Data Layer

The protocol uses IPFS as its decentralized storage layer for all content that is too large or complex for on-chain storage:

Task metadata: Detailed task descriptions, requirements, and acceptance criteria are stored as structured TipTap JSON documents on IPFS and referenced on-chain via a metadataURI field in the Task struct
Proof artifacts: Rich-text documents containing photos, descriptions, and evidence of task completion, stored on IPFS and referenced via proofURI in the Proof struct

All IPFS references use content-addressed identifiers (CIDs), ensuring data integrity: the hash of the content serves as its address, making tampering detectable. The platform resolves these URIs through an IPFS gateway and renders the content as rich text with embedded images.

9. Protocol Governance

The protocol includes administrative functions gated by OpenZeppelin's Ownable pattern. The contract owner (deployer) has the ability to:

Create and cancel sustainability tasks
Adjust the voting duration for future proposals
Delete unresolved proposals in exceptional circumstances
Update the minimum staking threshold
Pause task creation in emergencies
Withdraw funds from the Treasury

These administrative capabilities are exposed through authenticated API endpoints protected by ES256 JWT verification. Proposal resolution, by contrast, is fully permissionless — any address may trigger reward distribution after the voting period concludes.

10. Hedera Consensus Service Audit Trail

Beyond the on-chain smart contract state, Herena leverages the Hedera Consensus Service (HCS) to maintain an immutable, timestamped audit log of all significant protocol events. While smart contracts record state transitions, HCS provides a sequential, human-readable narrative of platform activity that is independently verifiable by any third party.

10.1 How It Works

The Herena backend operates a Hedera native account that acts as the audit trail publisher. When the event synchronization service detects on-chain events (proof submissions, votes, proposal resolutions, badge awards), it submits a structured JSON message to a dedicated HCS topic via TopicMessageSubmitTransaction. Each message receives a consensus timestamp from the Hedera network, providing a cryptographic proof of when the event was recorded.

10.2 Logged Events

proof_submitted: Records proof ID, task ID, and submitter address when a volunteer submits evidence of task completion
voted: Records proposal ID, voter address, vote direction (approve/reject), and quadratic voting power applied
proposal_resolved: Records proposal ID and final outcome (approved or rejected) when a governance vote concludes
badge_awarded: Records user address, badge type, and badge name when an impact badge is earned

10.3 Design Principles

HCS logging is non-blocking and best-effort — failures in audit trail submission never interrupt core protocol operations such as event processing or reward distribution. The HCS topic is configured with a submit key restricted to the server's operator account, preventing unauthorized message injection while keeping all messages publicly readable. Any observer can independently query the HCS topic on a Hedera mirror node to reconstruct the complete history of protocol activity.

11. Impact Badges

Herena rewards sustained participation through a system of Impact Badges — non-fungible tokens (NFTs) minted on the Hedera Token Service (HTS) that serve as permanent, on-chain credentials of a user's contributions to sustainability verification.

11.1 Badge Criteria

Badge	Trigger	Description
First Submission	Submit 1st proof	Awarded when a user submits their first proof of impact
First Approval	1st proof approved	Awarded when a user's proof is approved by the community for the first time
First Stake	Stake ≥ 10 HRN	Awarded when a user's net staked balance reaches 10 HRN
First Vote	Cast 1st vote	Awarded when a user casts their first governance vote

11.2 Minting Process

When a badge trigger is detected during event synchronization, the server awards the badge through a three-step process:

Database record: The badge is persisted to MongoDB with the user's wallet address, badge type, and timestamp. This serves as the authoritative source of truth for badge ownership.
HCS audit log: A badge_awarded message is published to the audit trail topic.
HTS NFT mint: A non-fungible token is minted on the Hedera Token Service under the “Herena Impact Badge” (HBADGE) collection. The NFT metadata encodes the badge type and description. The resulting transaction ID and serial number are stored alongside the database record, providing a direct link to the on-chain asset viewable on HashScan.

HTS minting is best-effort — if the Hedera native service is unavailable or unconfigured, the badge is still awarded in the database and displayed in the user interface. Each badge type can only be earned once per user, enforced by a unique compound index on (user, badgeType).

12. Why Hedera

Herena is deployed on the Hedera network for its alignment with the protocol's sustainability mission and technical requirements:

Carbon-negative consensus: Hedera's hashgraph consensus mechanism is energy-efficient and carbon-negative, directly aligning with the protocol's environmental objectives
EVM compatibility: Full Solidity support via the Hedera JSON-RPC relay, enabling standard tooling (Hardhat, ethers.js, viem)
Transaction finality: Near-instant finality ensures a responsive user experience for proof submissions and voting
Low fees: Predictable, low-cost transactions make micro-rewards and frequent governance participation economically viable
Immutable audit trail: All task completions, votes, and token transfers are permanently recorded on the Hedera ledger. Additionally, every significant event is logged to the Hedera Consensus Service (see Section 10), creating a sequential, independently verifiable record of verified environmental impact
Native token services: HTS enables Impact Badges to be minted as true Hedera-native NFTs (see Section 11) without deploying custom NFT contracts

13. Core Formulas

Quadratic Voting Power

P(s) = \lfloor\sqrt{s}\rfloor \quad \text{where } s = \text{staked HRN}

Reward Distribution

R_{\text{submitter}} = 0.8R, \quad R_{\text{voters}} = 0.2R, \quad r_i = \frac{R_{\text{voters}} \cdot P_i}{\sum_{j \in A} P_j}

AMM Constant Product

x \cdot y = k, \quad \Delta y = \frac{0.997 \cdot \Delta x \cdot y}{x + 0.997 \cdot \Delta x}

Initial LP Mint

LP = \sqrt{\Delta x \cdot \Delta y}