Transparency and Auditability
HYFY combines off-chain social and commercial activity with on-chain token settlement. Transparency therefore requires more than publishing blockchain transactions: the system must also show how a finalized monthly result connects to its recorded inputs without exposing private user data or commercially sensitive details.
Monthly Evidence
Each monthly cycle produces a defined close state. Depending on the evidence available, a period may complete, complete with no claims, be skipped under an allowed rule, or stop for investigation. Finalized close packages and attestations are append-only, and protected source facts cannot be silently changed after closure.
Monthly Karma and claim allocations are summarized through Merkle commitments. These commitments allow a user to verify that a specific balance was included without publishing every user's identity and activity history. Claim roots are activated only after the required review stage.
On-Chain Evidence
The following actions produce independently verifiable contract records when they occur:
- HYFY supply and completed burns;
- funded claim pools and monthly claim roots;
- individual wallet claims;
- monthly Karma commitments;
- liquidity-position changes; and
- queued and executed governance actions.
Off-chain revenue, identity, and abuse-prevention inputs cannot be made fully public without creating privacy and security problems. HYFY instead records reconciled results, source references, close states, and operational attestations, while limiting sensitive raw data to authorized systems.
HYFY maintains an official deployment registry and public reporting that link contract addresses, transaction history, supply, claims, burns, liquidity, and governance activity. A dashboard is a convenience; Polygon and the verified contract addresses remain the primary source for on-chain facts.
Transparency enables scrutiny, but it does not eliminate smart-contract, data-provider, operational, or governance risk.
What a Monthly Close Should Explain
A useful transparency record should answer more than “did the job run?” It should make the period understandable without exposing private user-level data.
For a completed month, the public summary can include:
- the period and final close status;
- reconciled revenue at an appropriate aggregate level;
- whether claims, burns, and liquidity were eligible;
- total claimable Karma and number of included claimants;
- published Karma and claim commitment identifiers;
- completed transaction hashes for on-chain actions;
- whether reserve, market-data, or capacity safeguards limited or blocked a dependent action;
- skipped or blocked actions and the category of reason; and
- governance changes that affected the period.
The public report does not need to reveal anti-abuse thresholds, individual purchase history, identity records, or every internal service log.
Example: Verifying a Claim
Suppose Alice submitted a claim and later receives an active proof in the app. She can verify several layers independently:
- The official deployment registry identifies the distributor contract.
- The contract shows the active root and funded amount for the month.
- Her proof is bound to her account identity and allocation without exposing other users.
- Her completed wallet transaction shows the HYFY transfer.
- The distributor marks that month's claim as used, preventing replay.
This does not require the public to download every user's Karma history. The commitment proves inclusion while the individual proof reveals only what is needed for that claim.
| Verification layer | Example fact | Best evidence |
|---|---|---|
| Deployment | Correct distributor contract | Production registry plus Polygon bytecode |
| Monthly close | Period is finalized | Append-only close package and attestation |
| Allocation | Alice is included for 500 HYFY | Alice's Merkle proof against the active root |
| Settlement | 500 HYFY reached Alice's wallet | Polygon transaction and token transfer event |
| Replay protection | The claim cannot run twice | Distributor's claimed state |
Append-Only Financial Evidence
Monthly close packages, attestations, burn records, and liquidity records are designed to become append-only after finalization. Corrections should appear as new, attributable adjustments or resolution records rather than silent edits to closed facts.
That distinction is important in real operations. A payment provider may report a late refund, or an operator may need to document why a scheduled burn was skipped. Preserving the original close and adding the correction creates an audit trail; overwriting the old value destroys one.
The allocation path also keeps settlement amounts in their defined currency and token units until a result is finalized. Public dashboards can round an aggregate for readability, but the close record, funded pool, and Merkle commitment must reconcile at settlement precision. This makes a displayed total convenient without making it the accounting source of truth.
What Is On-Chain and What Is Not
Token supply, burns, claim roots, completed claims, governance actions, and liquidity-position events can be checked on Polygon. Social actions, payment reconciliation, account-risk signals, identity verification, and the full monthly calculation remain off-chain because they involve scale, privacy, or external providers.
HYFY therefore should not claim that “no trust is required.” The stronger and more accurate claim is that final token actions are publicly verifiable and the off-chain process produces controlled evidence that can be audited.
Dashboard Limitations
A dashboard can make contract events easier to read, but it can lag, mislabel an address, or fail entirely. Users should treat it as an interface over the source data. The official contract registry and Polygon records remain the authority for on-chain facts, while signed or append-only monthly records support the off-chain side.