DAO Governance

What you’ll get here

how Smart Engines is governed by its token holders — how a rule or parameter change goes from a proposal to a published, enforced change, all recorded publicly on Hedera HCS.

Smart Engines’ protocol DAO is governed by HSUITE holders, not by a central team. The DAO is built into the validator: rule amendments and marketplace pricing changes are carried out after a passed vote, and a passed proposal is the authorization the validators check before co-signing an operation on a DAO-governed token or account. The same machinery is also offered as a product — any community can run its own DAO on it.

The protocol DAO and the HSuite DUNA

The protocol DAO is the protocol’s on-chain governance. The HSuite DUNA (Project X Suite - Wyoming DUNA, also called the HSuite DAO) is a separate layer: the legal entity for community coordination, education, ecosystem programs and its own Treasury, stewarded for now by a nine-member Transitional Board. Holding HSUITE does not, by itself, make you a member of the DUNA. See HSuite DUNA governance.

🧠 For Normies

A DAO is “an organization run by a public vote of its token holders.” Important decisions become proposals; members vote in proportion to the tokens they held when the proposal opened; if enough vote yes, the decision takes effect and the whole trail is public.

---

Where governance lives

Governance records — proposals, votes, vetoes — are written to Hedera Consensus Service (HCS) topics. HCS gives ordered, immutable, publicly-readable messaging, which is exactly what a transparent decision trail needs. The protocol DAO’s voting token is HSUITE on XRPL; the audit log lives on Hedera.

🧠 For Normies

Hedera’s consensus service is like a public, tamper-proof bulletin board with timestamps. Every proposal and vote gets posted there, so anyone can later verify exactly what was decided and when.

This is the platform’s “rules are public” property: the governing rules and their changes are on-chain, not in a private admin panel.

---

The proposal lifecycle

Proposals move through a strict state machine:

stateDiagram-v2
    [*] --> awaiting_signature : prepare
    awaiting_signature --> active : proposer signs, published to HCS
    active --> passed : quorum met and approval reached
    active --> failed : quorum met, approval not reached
    active --> expired : quorum not met
    passed --> executed : execution delay elapsed
    passed --> vetoed : veto council blocks it
    executed --> [*]
    failed --> [*]
    expired --> [*]
    vetoed --> [*]

1. Prepare — the cluster builds the unsigned proposal for the proposer.
2. Sign — the proposer signs it with their own wallet, and the proposal is published to the DAO’s governance HCS topic. Its HCS consensus time pins the voting-power snapshot.
3. Active — members vote for / against / abstain; each vote is signed by the voter’s wallet and published to the same HCS topic. A vote counts only if it lands within the voting period, measured from the proposal’s own consensus time.
4. Tally — at period end, the service checks quorum (votes cast, abstentions included, as a share of total voting power) and approval (for as a share of votes cast). A tie at the threshold passes. Missing quorum ends the proposal as expired; missing approval ends it as failed.
5. Executed — once the DAO’s execution delay (timelock) has passed with no veto, the proposal is executed: the cluster applies the actions it carries out itself, and records the rest as authorized (see What proposals can do).

The protocol DAO, created at genesis, uses these settings: a 50% approval threshold, a quorum of 10% of total voting power, a 14-day voting period, a 48-hour execution delay, and at most 20 active proposals at a time. The 10% quorum and the 48-hour delay are floors fixed in the genesis tokenomics.

🧠 For Normies

Propose → sign → vote → tally → wait → act. The key trick is the snapshot: the moment a proposal is published, everyone’s voting weight is fixed at what they held then, so nobody can buy tokens mid-vote to swing it.

Snapshots stop late vote-buying

When a proposal is published, its HCS consensus time becomes the snapshot point. Your vote weight is the token balance you held at that moment, not now. Tokens acquired after the snapshot carry no weight — this prevents an attacker from buying influence in an already-open vote. Vote weight is token balance only; there is no other weighting model.

A veto is a signed, on-chain block on a passed proposal

A DAO may carry a veto council — a named set of accounts that can block a proposal after it has passed but before it executes. A DAO without a veto council has no vetoes. A veto is not a convenience switch; it is held to the same authentication bar as a vote:

The vetoer must sign

Naming a council account authenticates nothing — any session could type a council member’s address. The veto must carry the vetoer’s own vetoerPublicKey and a signature over the canonical dao-veto payload, and that key must derive to the vetoer account on the DAO’s governance chain. Missing or unbound material fails closed (400).

Only a passed proposal can be vetoed

Vetoing one that is still active, already executed, or already vetoed is refused.

The on-chain record is the act

A veto is real only when a proposal-vetoed message lands on the DAO’s governance HCS topic. A local (database-only) marker would be invisible to every other validator’s sign gate, so if the HCS publish fails, the veto fails. Once the record lands, execution refuses the proposal with a vetoed verdict, and the sign gate observes the same block.

🧠 For Normies

Some DAOs appoint a small council that can halt a proposal that already passed but hasn’t been carried out yet. To do it, a council member has to cryptographically sign the veto with their own key — typing someone’s name isn’t enough — and the veto only counts once it’s posted to the public ledger. A veto that only exists in a private database doesn’t count, so nobody can quietly claim a proposal was blocked.

---

What proposals can do

A proposal carries one or more typed actions. Only two kinds are carried out by the cluster itself:

Action	Effect when the proposal executes
dao_parameter_change	Amend a single field of an entity’s canonical rules. The cluster publishes the amended rule.
marketplace_pricing_override	Override the marketplace fee/pricing config — listing fee, featured-slot fee and cap, and the platform cut. The cluster validates the payload against the known fields and applies it.
Token, treasury, transfer and membership actions	Authorization only. Mint, burn, pause, freeze, KYC, wipe and transfer actions on a DAO-governed token, transfers from a DAO-governed account, and member or detail changes are recorded as approved. The passed proposal on the governance topic is the approval the validators’ sign gate looks for before co-signing the matching operation, which is then submitted through the normal transaction path.
dao_custom	Authorization only; records the decision.

Admitting or removing a validator is not a DAO proposal: the validators vote on that among themselves.

🧠 For Normies

A passed vote either changes a rule or a marketplace price directly, or it becomes the signed permission slip the validators require before they will co-sign a specific action, like minting a DAO’s token. If it fails to pass, nothing happens.

---

Treasury: no backdoor

The protocol Treasury is not a DAO-controlled account, and no vote can spend it. It is an autonomous protocol fee-payer: a validator multisig account that pays the network’s own costs, such as opening deposit accounts, funding the runner pool and paying Hedera fees for rule publication. Its published rule is the only authority over it:

• it may pay only protocol destinations — itself, cluster operators, the token issuer, the testnet faucet, deposit accounts, the runner pool and bridge lock wallets — each confirmed by every co-signing validator from its own reads, never from a field in the request;
• every asset has a spending cap per monthly period, and the account must keep a minimum balance;
• any other destination is denied.

A DAO’s own treasury, for DAOs built on the platform, is moved through that DAO’s transfer proposals, under the authorization model above.

🧠 For Normies

The protocol’s treasury is a locked expense account. It can only pay the network’s own running costs, to a short list of protocol accounts, within monthly limits. Nobody can point it at their own wallet — not a validator, not a vote.

---

How rule and price changes get enforced

This is the link between governance and the rest of the economy. Operation prices and subscription tiers are part of the software release; no vote changes them. Marketplace pricing is the exception: a passed marketplace_pricing_override proposal changes it.

Revenue settlement reads its distribution split per-entity from the deposit account’s own canonical rule — the distribution policy pinned in that rule — falling back to the default only when no governed policy is present (see Settlement & migration). A governed split is not a hardcoded constant but a rule field, and a rule field changes only through a published rule amendment.

sequenceDiagram
    autonumber
    participant Pr as Proposer
    participant DAO as DAO service
    participant HCS as HCS topic
    participant M as Members
    participant Exec as Executor
    participant Reg as Rules / marketplace config

    Pr->>DAO: prepare, then sign the proposal
    DAO->>HCS: publish signed proposal (snapshot pinned)
    loop voting period
        M->>DAO: cast signed vote
        DAO->>HCS: record vote
    end
    DAO->>DAO: tally quorum + approval
    alt passed and not vetoed
        DAO->>Exec: dispatch each action after the delay
        Exec->>Reg: apply rule amendment or pricing override
    else failed or expired
        DAO->>DAO: no action
    end

🧠 For Normies

Nobody can quietly change a governed rule or the marketplace prices. It takes a vote, and the change only takes effect when the cluster applies it after the vote passes — with a public receipt.

---

Amending an entity’s rules through governance

A dao_parameter_change proposal can amend the canonical rules bound to an entity — change a single field, like a daily mint limit or an approval threshold. When such a proposal passes, the cluster doesn’t edit anything in place. It publishes a new rule version to the entity’s Hedera HCS rules topic and advances the entity’s pointer to it. The old version stays in the public log forever.

The dangerous part of “let governance change the rules” is the gap between what was voted on and what actually got published. A naïve implementation lets whoever publishes the new rule slip in extra changes nobody approved. Smart Engines closes that gap with content-binding: the amendment is published wrapped in an on-chain envelope that names the proposal that authorized it, and the field path it was allowed to touch.

flowchart LR
    P["Passed dao_parameter_change proposal (fieldPath + value)"] --> A["Apply single field change to current rule"]
    A --> E["Wrap in amendment envelope (names proposal + daoId + fieldPath + prior rule ref)"]
    E --> H["Publish envelope to entity rules topic (Hedera HCS)"]
    H --> B["Advance entity rule pointer (BFT-signed binding update)"]

1. Apply — the cluster resolves the entity’s current canonical rule, applies the single voted field change, enforces invariants (immutable fields, governance floors), and validates the result against the rule schema. Any violation → the amendment is refused.
2. Envelope — the mutated rule is wrapped in an amendment envelope. The envelope carries an authorizing-proposal record: the proposal ID, the governing DAO ID, the governance HCS topic, the voting snapshot pin, the authorized field path, and a pointer to the prior rule version. (Genesis rules stay published bare; only amendments are enveloped — both decode through one entry point.)
3. Anchor — the envelope is published to the entity’s HCS rules topic. The submit fee is paid by the protocol Treasury (see below), not a per-validator operator key.
4. Advance — the entity’s rule pointer is advanced to the new version with a BFT-signed binding update, so the validators resolve the amended rule from then on.

Crucially, the pointer is treated as an untrusted hint. Whether an amendment is honored is decided later, independently, by the sign gate — see how the sign gate verifies an amendment for the mechanics.

🧠 For Normies

A passed vote can change one specific rule — say, “raise the daily limit to X.” The new rule is published on the public ledger in a sealed envelope that says which vote authorized it and exactly which field it was allowed to change. Nobody can use a real vote as cover to sneak in other changes — the envelope pins it to the one thing that was actually approved.

Anchored on Hedera, paid by the Treasury

Every rule version — genesis or amendment — is anchored on a Hedera HCS topic, the same public consensus log the rest of governance uses. For amendments published at runtime, the HCS submit fee is charged to the protocol Treasury, a DKG-multisig account whose payer authority is threshold-signed by the validators — never a single validator’s operator key. The same Treasury-as-fee-payer path also backs runtime epoch anchoring and subscription audit submits.

🧠 For Normies

Writing the rule change to the public ledger costs a tiny network fee. That fee is paid out of the shared protocol Treasury — which itself can only move with the validators’ collective sign-off — not by any one operator footing the bill or holding the keys.

---

Who can administer a DAO

A proposal is how the membership governs. The DAO’s own administrative routes — editing its config (voting rules, governance token, governance topic, veto council, status, treasury), adding or removing members, and manually dispatching execution — are creator-gated: only the account that created the DAO, signed in as the authenticated session wallet, may call them; anyone else gets 403. The DAO’s creator is bound to the authenticated caller at creation, and the protocol DAO was created by the genesis ceremony, which no session can match — so the protocol DAO is admin-frozen: it has no human administrator and moves only through passed proposals.

🧠 For Normies

The housekeeping controls of a DAO (its settings, its member list) belong to whoever created it, proven by a signed-in wallet — not to anyone who knows its name. The protocol’s own DAO is deliberately locked out of this door entirely: it has no admin account, so the only way to change it is a vote.

---

Governing the marketplace

The protocol DAO also governs the app marketplace, and two of its levers are pure governance surfaces:

• Lifting a takedown takes a vote. When a marketplace app has been taken down by moderation, the only way to lift it is to cite a passed protocol-DAO proposal on the governance HCS topic. There is no admin override: the validator verifies the cited proposal on-chain and refuses fail-closed — 503 if the governance topic can’t be read, a refusal if the proposal hasn’t passed. Only on a verified pass is the takedown lifted.
• Governance is readable from the edge, writes are not. The gateway exposes membership, DAO and governance state through a read-only door (/api/v3/gov): a fixed allow-list of GET-only routes proxied from the cluster’s own validator. It forwards no write verb and no Authorization header, so a gateway caller can never mint a session, cast a vote, or mutate membership through it, and it fails closed with 503 rather than serve a stale guess. Every write stays wallet-signed on the validator’s session-guarded surfaces.

🧠 For Normies

If a marketplace app gets pulled, putting it back isn’t a button an admin can press — it takes a passed vote, checked on the public ledger. And while anyone can read governance and membership data through the public gateway, that same gateway can’t be used to change anything: it only passes through read requests, never writes.

---

Sovereign DAOs and vote weighting

Two properties matter for serious users:

• Prepare endpoints — the cluster only prepares the unsigned proposal or vote; the member signs it with their own wallet. The cluster orchestrates, but the signature is the member’s.
• Token-balance weighting — a vote weighs the voter’s token balance at the snapshot, nothing else. The rules engine’s governance model also defines reputation weighting and multi-hop delegation, but DAO voting does not use them.

Customers can also rehearse governance rules before publishing via a public POST /api/v3/governance/simulate endpoint, which runs the rules engine’s governance checks as a pure function over a supplied config and context without touching state. It does not simulate reputation weighting or delegation.

🧠 For Normies

You sign your own proposals and votes; the cluster just does the plumbing. One token, one unit of voting weight. And anyone can “dry-run” governance rules to see how they behave before posting for real.

---

Next steps

Value flowsWhere the money goes.

Staking & node-runnersHow node runners stake and earn.

HSUITE tokenThe token behind the votes.