Governance Delegation of HTS Fungible Tokens, NFTs (with Rarity Weighting), and HCS Topics

[lennynerowuzhere]

title: Governance Delegation of HTS Fungible Tokens, NFTs (with Rarity Weighting), and HCS Topics
author: Lenny Nero lennynero722@gmail.com
working-group: Native Hedera Economic Stack
requested-by: Hedera Community
type: Standards Track
category: Service
status: Draft
needs-hiero-approval: Yes
needs-hedera-review: Yes
created: 2025-09-05
updated: 2025-12-12
requires: 206, 218, 336, 632, 1081, 1195

Abstract

This HIP introduces a native Hiero mechanism for accounts (delegators) to delegate governance voting power—derived from HTS fungible tokens, NFTs with rarity weighting, and HCS topics—to another account (delegate) without transferring or approving tokens. The proposal defines new HAPI transactions (CryptoApproveGovernanceDelegation, CryptoRevokeGovernanceDelegation, TokenSetWeightRule, CryptoRecordSelfVote, SubmitVote), queries (GetGovernanceWeight, GetDelegationsByDelegate, GetDelegators, GetVoteTally), and weight calculation rules for FT balances, NFT counts/rarities/traits, and HCS topic scopes.

Key innovations include Progressive Immutability via rule_admin_key, Event-Based Self-Vote Exclusion (L1 records events to the stream; L2 Block Nodes compute exclusions—no unbounded lists on L1), HIP-1195 Hook Integration for custom validation logic, State Bloat Prevention through strict delegation limits and mandatory state rent, and adherence to the Layer Architecture where L1 consensus nodes handle only delegation anchoring while L2 Block Nodes (HIP-1081) manage historical weight calculations and tally logic.

Delegation is non-custodial: no spend rights, no token approvals, no content-decryption rights are granted.

---

Motivation

Current governance systems on Hedera face several challenges that this HIP addresses:

Multi-wallet governance complexity: Users holding governance tokens and NFTs across multiple cold wallets find it impractical to sign transactions from each wallet for every vote. This creates friction in DAO participation and reduces engagement. A user with holdings split across five hardware wallets would need to perform five separate signing ceremonies for each proposal.

Unsafe workarounds: The existing HIP-336 allowance mechanism grants spending rights, which is inappropriate and unsafe for pure governance delegation. Users should not need to risk their assets to participate in voting. Current workarounds require users to either consolidate tokens (gas costs, tax implications) or grant dangerous permissions.

NFT rarity matters: Many NFT collections have inherent rarity hierarchies where certain serials carry more governance weight (grail pieces, founder editions, trait combinations). Without standardization, each project implements ad-hoc logic leading to fragmentation, poor user experience, and potential manipulation. A "Legendary" NFT should carry more governance weight than a "Common" one.

Cross-ecosystem governance: DAOs and councils operating on Hedera Consensus Service (HCS) need a native way to honor voting delegation that works consistently across all token types. Currently, each DAO must build custom delegation logic.

Institutional requirements: Enterprises and institutions need compliant, auditable delegation mechanisms that preserve custody while enabling participation in network governance. Current solutions don't meet enterprise compliance requirements.

Double-counting vulnerability: Existing delegation patterns fail to prevent delegators from voting with their own tokens AND having their delegate vote with the same delegated power, effectively doubling their influence. This undermines governance integrity.

Inflexible immutability: Binary "immutable" flags force projects to choose between complete flexibility (risky—rules can change arbitrarily) or permanent lock-in (inflexible—no path to improvement). Progressive immutability via admin key removal provides a path from managed to trustless governance.

Smart contract overhead: EVM-based governance contracts (OpenZeppelin Governor, Compound) cost $2-10+ per vote and introduce vulnerability surface. The 2022 Beanstalk governance attack resulted in $182M in losses due to flash loan manipulation of governance contracts. Native protocol implementation reduces costs to $0.05 per delegation while eliminating entire vulnerability classes.

A native governance delegation primitive with event-based self-voting prevention, strict state limits, and progressive immutability solves these problems by providing a secure, standardized, and user-friendly mechanism that works uniformly across wallets, explorers, and dApps.

---

Rationale

Design Decisions

Non-custodial by design: Unlike spending allowances (HIP-336), governance delegation grants zero transfer rights. The delegator retains full custody and control of assets. Even if a delegate's keys are compromised, the delegator's assets remain safe.

Progressive Immutability via rule_admin_key: weight rules include a rule_admin_key field:

Key rule_admin_key = 8;  //

When present, this key can modify the rules. When set to an empty KeyList, the rules become permanently immutable. This allows projects to start with admin control and progressively decentralize by removing the key—providing a migration path from managed to trustless governance.

Event-Based Self-Vote Exclusion (Zero L1 State Growth): Previous designs stored self_voted_proposal_ids on L1, creating unbounded list growth. The corrected design:

1. L1 records CryptoRecordSelfVote as an event in the record stream (not state)
2. L1 updates only last_vote_timestamp on the account (O(1) state)
3. L2 Block Nodes query the event stream to identify self-votes
4. L2 applies exclusion logic: "If SelfVote event exists for Proposal X, exclude delegation weight"

This eliminates the "zombie list" risk entirely—zero state growth on L1 for voting activity.

Strict Delegation Limits (Anti-DoS): To prevent state bloat attacks:

CONSTRAINT: An account may delegate to a maximum of 3 distinct delegates simultaneously.
CONSTRAINT: A delegation record may contain a maximum of 10 GovernanceScope entries.
CONSTRAINT: GovernanceDelegation objects are subject to mandatory State Rent.

These limits ensure bounded state growth even under adversarial conditions.

HIP-1195 Hook Integration: Every state-changing transaction includes a hook_id field for custom governance rules (quorum requirements, voting windows, proposal validation) without consensus node complexity.

Layer Architecture Compliance:

• L1 (Consensus/Anchor): Stores only delegation records (bounded), weight rule Merkle roots, admin keys. O(1) complexity per operation. No loops, no aggregation, no unbounded lists.
• L2 (Execution/Block Nodes): Computes historical weight snapshots, queries event stream for self-votes, validates Merkle proofs, aggregates delegation graphs, performs self-vote exclusion calculations.

Prior Art and Compatibility

This HIP builds on existing standards: HIP-206/218 (HTS-EVM integration), HIP-336 (allowances—the anti-pattern we avoid), HIP-632 (signature validation), HIP-1081 (Block Nodes), HIP-1195 (Hiero Hooks), and draws from OpenZeppelin Governor and Compound Governor patterns while eliminating EVM overhead.

---

User Stories

DAO Member: "I want to delegate my cold wallet holdings to a hot wallet so I can vote without moving funds or exposing my keys."

NFT Collector: "I want to delegate my rarity-weighted NFT collection to a trusted delegate for community votes, knowing they can't transfer or sell my assets."

Institution: "I want to consolidate governance power from multiple custodial accounts without moving tokens between accounts or compromising security."

Project Founder: "I want to configure my NFT collection so that legendary traits carry 10x voting weight compared to common traits, and later remove the admin key to make these rules permanent."

Voter: "I want my wallet to show me all the delegated voting power I have from others, broken down by token and source."

DAO Operator: "I want to query total voting weight at a historical consensus timestamp to ensure votes are counted fairly, without double-counting delegators who voted directly."

Delegator Who Votes: "I want to vote on a specific proposal myself, and have the system automatically exclude my tokens from my delegate's voting power for that proposal only."

AI Agent Operator: "I want to delegate limited governance power to an AI agent with HIP-1618 safety controls, allowing automated participation within defined bounds."

---

Specification

Layer Architecture

Layer	Component	Complexity	Responsibilities
L1	Consensus Nodes	O(1)	Store delegation records (bounded), weight rule roots, emit self-vote events to stream
L2	Block Nodes	O(n)	Compute weight snapshots, query event stream for self-votes, validate proofs, tally votes
L4	HCS/IPFS	Storage	Full Merkle trees, proposal definitions, vote history

L1 Prohibited Operations: Loops, delegation graph traversal, weight aggregation, division, file storage, Merkle tree iteration, unbounded list storage.

State Limitations (Anti-Bloat)

Constraint	Limit	Rationale
Max delegates per delegator	3	Prevents delegation spam
Max scopes per delegation	10	Bounds transaction complexity
Max active delegations per account	10	Total state cap
Delegation record lifetime	Subject to State Rent	Purged if account depleted

Block Node Role

The Block Node (HIP-1081) is REQUIRED for this HIP and handles:

Function	Description
computeWeightSnapshot	Calculate aggregate voting weight at any timestamp
querySelfVoteEvents	Read event stream to find self-votes for a proposal
calculateExclusions	Apply self-vote exclusion logic using event data
validateMerkleProof	Verify NFT weight proofs against stored roots
computeVoteTally	Aggregate votes with exclusion logic applied
generateStateProof	Create SHA-384 audit proofs

Core Type Changes

NftWeightRule with Progressive Immutability:

message NftWeightRule {
  NftWeightMode mode = 1;
  bytes merkle_root_sha384 = 2;
  uint64 max_per_serial_weight = 3;
  uint64 max_per_account_weight = 4;
  Timestamp valid_from = 5;
  Timestamp valid_until = 6;
  string proof_url = 7;
  
  // Progressive Immutability: Empty KeyList = permanently locked
  Key rule_admin_key = 8;  // REPLACES: bool rule_immutable
}

GovernanceDelegation (Optimized - No Unbounded Lists):

message GovernanceDelegation {
  AccountID delegator = 1;
  AccountID delegate = 2;
  repeated GovernanceScope scopes = 3;  // Max 10
  Timestamp not_before = 4;
  Timestamp expiry = 5;
  uint64 nonce = 6;
  string memo = 7;
  Timestamp created_at = 8;
  
  // REMOVED: repeated bytes self_voted_proposal_ids
  // Self-votes tracked via event stream, not L1 state
}

Transaction Bodies with Hooks

All state-changing transactions include hook_id:

SubmitVoteTransactionBody:

message SubmitVoteTransactionBody {
  bytes proposal_id = 1;
  TopicID voting_topic = 2;
  VoteChoice choice = 3;
  TokenID token_id = 4;
  repeated NftWeightProof nft_proofs = 5;
  string memo = 6;
  bytes hook_id = 7;  // HIP-1195 Trigger
}

CryptoApproveGovernanceDelegationTransactionBody:

message CryptoApproveGovernanceDelegationTransactionBody {
  AccountID delegate = 1;
  repeated GovernanceScope scopes = 2;  // Max 10
  Timestamp not_before = 3;
  Timestamp expiry = 4;
  uint64 nonce = 5;
  string memo = 6;
  bytes hook_id = 7;  // HIP-1195 Trigger
}

CryptoRecordSelfVoteTransactionBody (Event-Based):

message CryptoRecordSelfVoteTransactionBody {
  bytes proposal_id = 1;
  TopicID voting_topic = 2;
  bytes vote_message_hash = 3;
  bytes hook_id = 4;  // HIP-1195 Trigger
  
  // L1 Behavior: Log event to record stream, update last_vote_timestamp
  // L1 does NOT store proposal_id in any list
}

Event-Based Self-Vote Exclusion Algorithm (L2)

The Block Node executes this algorithm—never L1:

function calculateEffectiveWeight(delegate, proposal_id, token_id, timestamp):
    base_weight = 0
    excluded_weight = 0
    
    // Get all delegations to this delegate
    delegations = getDelegationsTo(delegate, token_id)
    
    // Query EVENT STREAM for self-votes (not L1 state)
    self_vote_events = queryEventStream(
        type = "CryptoRecordSelfVote",
        proposal_id = proposal_id,
        timestamp_range = [proposal_start, proposal_end]
    )
    
    self_voters = extractAccountIds(self_vote_events)
    
    // ITERATION: Only at L2
    for each delegation in delegations:
        delegator = delegation.delegator
        delegator_weight = getTokenWeight(delegator, token_id, timestamp)
        
        if delegator in self_voters:
            excluded_weight += delegator_weight
        else:
            base_weight += delegator_weight
    
    own_weight = getTokenWeight(delegate, token_id, timestamp)
    
    return {
        effective: base_weight + own_weight,
        excluded: excluded_weight
    }

Progressive Immutability Workflow

Phase 1: rule_admin_key = project_key         → Full flexibility
Phase 2: rule_admin_key = multisig_key        → Governance control  
Phase 3: rule_admin_key = dao_council         → Decentralized
Phase 4: rule_admin_key = KeyList { keys: [] } → Permanently locked

Weight Calculation Semantics

Fungible Tokens: weight = token_balance (in smallest denomination)

NFTs (COUNT): weight = number_of_NFTs_owned

NFTs (PER_SERIAL): Block Node validates Merkle proofs: merkleVerifySHA384(root, serial, weight, proof)

NFTs (TRAIT_BASED): Block Node validates: merkleVerifySHA384(root, sha384(traits), weight, proof)

Fee Schedule

Operation	Fee (USD)	Notes
CryptoApproveGovernanceDelegation	$0.05	Creates new state object (like TokenAssociation)
CryptoRevokeGovernanceDelegation	$0.001	Removes state
TokenSetWeightRule	$0.01	Updates token config
SubmitVote	$0.001	Event only
CryptoRecordSelfVote	$0.001	Event only
GetGovernanceWeight (complex)	$0.001	L2 query

---

Security Considerations

Non-custodial guarantee: Delegation grants zero spending or transfer rights. Tokens remain fully controlled by the delegator. Even if a delegate's keys are compromised, delegated assets cannot be stolen.

Event-based self-vote exclusion: Self-votes are recorded as events in the record stream, not as unbounded lists in L1 state. Block Nodes query the event stream to compute exclusions. This eliminates the "zombie list" attack vector entirely.

State bloat prevention: Strict limits (max 3 delegates, max 10 scopes, mandatory state rent) prevent DoS attacks via cheap delegation spam. The $0.05 fee aligns with TokenAssociation costs.

Progressive immutability security: The rule_admin_key pattern provides verifiable immutability status (users check before trusting), gradual transition path (not all-or-nothing), and accountability (key removal is visible on-chain).

Replay protection: Each delegation includes a unique nonce preventing replay attacks.

Merkle commitment security: SHA-384 merkle_root is committed at rule configuration time, preventing retroactive weight manipulation.

Non-transitive delegation: Delegates cannot re-delegate to third parties, maintaining delegator control.

Access separation: Governance delegation does NOT grant access to encrypted NFT content (HIP-1612) or redeemable reserves (HIP-1613).

O(1) L1 Complexity: Consensus nodes never iterate or store unbounded data. All loops, aggregations, and historical queries are offloaded to Block Nodes.

---

Backward Compatibility

This HIP is fully additive with no breaking changes. Existing tokens, NFTs, and HCS topics continue functioning unchanged. Legacy wallets ignore new fields. No state migration required. rule_admin_key is optional; if absent, weight rules use token's admin_key.

---

How to Teach This

For Token Holders: "Delegation is like giving someone your voting proxy, but not your wallet keys. If you vote directly, your tokens are automatically excluded from your delegate's count—tracked via events, not stored on-chain."

For DAO Operators: "Configure NFT weights with COUNT, PER_SERIAL, or TRAIT_BASED modes. Start with admin key, transition to multisig, then lock permanently. Max 10 scopes per delegation."

For Developers: "All heavy computation happens at Block Nodes. Self-vote exclusion uses the event stream—no L1 state growth. Your consensus interactions stay O(1)."

---

Reference Implementation

See assets/hip-1611/governance.proto for complete protobuf definitions.

---

Rejected Ideas

• Transitive delegation: Rejected for complexity and loss of control
• Boolean immutability: Rejected for inflexibility; rule_admin_key enables gradual transition
• L1 iteration: Rejected for O(1) requirement
• Storing self_voted_proposal_ids on L1: Rejected—creates unbounded "zombie list"; use event stream instead
• Unlimited delegations: Rejected—DoS vector; bounded to 3 delegates, 10 scopes
• Low fees ($0.001): Rejected—doesn't cover state rent; aligned to $0.05 like TokenAssociation

---

Open Issues

1. Should there be a maximum proof_url length to prevent abuse?
2. Should delegation records auto-expire after a configurable period to reduce stale state?

---

References

• HIP-206: Hedera Token Service API
• HIP-336: Approval and Allowance API
• HIP-1081: Block Nodes
• HIP-1195: Hiero Hooks
• OpenZeppelin Governor Contracts
• Compound Governor Alpha/Bravo

---

[kpachhai]

Some feedback here:

1. What is the scope of this HIP?
   Is this HIP only adding “delegate voting power + compute voting weight”, or is it also trying to define a full governance system (proposals, voting rules, quorum, execution)? Please clearly say what is in scope vs out of scope.
2. How are proposals defined and anchored?
   What exactly is a proposal_id, and where does the proposal live so everyone agrees on what people are voting on (HCS message, file hash, on-ledger record, etc.)?
3. Who decides voting start/end and pass/fail rules?
   How are voting periods determined? How is quorum calculated? How is “passed/failed” decided? If this is left to each app, say that clearly.
4. How does it prevent double counting (double voting)?
   If someone delegates to another account but also votes themselves, how does the system ensure their tokens are not counted twice for the same proposal?
5. How do hooks apply given HIP-1195’s current limits?
   HIP‑1195 currently defines only ACCOUNT_ALLOWANCE_HOOK. If governance needs hooks, what new hook types/extension points are required, when are they called, and who pays for them? If these hook types don’t exist yet, this HIP should say that explicitly or defer hooks to a separate HIP.