Concept & Specification

Version: 1.0
Status: Canonical
Scope: All Kambria DAOs
Applies to: Phase-based DAO operations (starting with Phase-1 pilots)

1. Purpose & Scope

The KAT Reward & Privilege Framework 1.0 defines how KAT is used across Kambria DAOs as a derived recognition, privilege, and long-term ownership signal, rather than as a payment or yield instrument.

The framework is designed so that:

• The Dev team builds one reusable, rule-based system
• Each DAO configures its own contribution logic, quality rules, and privileges
• DAO operations can run safely with no per-DAO custom code

This framework intentionally separates:

• Contribution
• Quality & trust
• Token-based privileges

to avoid common token-incentive failures.

2. Canonical Principle (Non-Negotiable)

Contribution is recorded first.
Trust and quality are evaluated second.
KAT is derived last to unlock privileges and long-term ownership signals.

This order must never be bypassed.

3. Canonical Layers (Framework-Level)

All DAOs using this framework share the same three conceptual layers.

3.1 Kambria Credits (KC) - Contribution Accounting Layer

Purpose
Record what contribution actually happened inside a DAO.

Characteristics

• Non-tokenized
• Non-transferable
• Immutable (append-only ledger)
• DAO-scoped
• Never spent, burned, or revoked

Role

• Acts as the ground truth of contribution
• Independent of quality or reward

Credits answer one question only: “What verified contribution occurred?”

3.2 Kambria Karma (KK) - Quality & Trust Layer

Purpose
Evaluate how much the system should trust those contributions.

Characteristics

• Non-tokenized
• Stateful (level-based, not additive)
• Changes slowly
• DAO-scoped
• Can increase or decrease

Role

• Weights contribution quality
• Gates or nullifies downstream rewards

Karma answers: “How trustworthy and reliable is this contributor’s participation?”

3.3 KAT - Derived Reward & Privilege Token

Purpose
Represent trusted contribution at the DAO and ecosystem level.

Characteristics

• Tokenized and scarce
• Never issued per action
• Derived periodically from Credits × Karma
• DAO-scoped accounting, ecosystem-level asset

Role

• Unlocks access, privileges, and influence
• Signals long-term ownership potential
• Not used as payment in early phases

KAT answers: “What privileges and long-term standing does the DAO grant to this contributor?”

4. Canonical Derivation Formula

This formula is framework-level and shared by all DAOs:

KAT_issued = Σ(Credits in settlement period)  × KAT_per_Credit   × Karma_Multiplier

Where:

• Credits = verified Kambria Credits earned in the period
• Karma Multiplier = contributor’s Karma level at settlement time
• KAT_per_Credit = DAO-defined parameter

KAT is:

• Derived
• Batch-issued
• Capped

5. Framework vs DAO Responsibilities

5.1 What the Framework Defines (Fixed)

The framework defines:

• The three-layer model (Credits → Karma → KAT)
• The derivation formula
• The settlement lifecycle
• Safety constraints (caps, batch minting, no per-action minting)
• Required data structures

These are not configurable per DAO.

5.2 What Each DAO Defines (Configurable)

Each DAO defines its own:

1. Contribution rules
   • What actions generate Credits
   • Credit values
   • Verification requirements
2. Karma rules
   • Quality signals
   • Mapping from signals → Karma levels
   • Promotion / downgrade policies
3. Parameters
   • KAT_per_Credit
   • Global and per-user caps
   • Settlement frequency
   • Inactivity decay thresholds
4. Privilege surfaces
   • What each tier unlocks
   • Access, economic, and governance privileges
   • Product-level interpretation of privileges

No DAO changes the framework logic itself.

6. DAO Configuration Model (Abstract)

Each DAO operates via a configuration object conceptually structured as:

6.1 Core Parameters

• Settlement period (e.g. monthly)
• KAT_per_Credit
• Global KAT cap per period
• Per-user KAT cap
• Inactivity decay rules

Parameter Ranges & Guardrails

To preserve cross-DAO consistency, prevent early inflation, and maintain the long-term signaling value of KAT, the Framework defines recommended operating ranges for key parameters.

Each DAO must select values within these ranges and document the rationale in its DAO configuration.
Values outside the ranges require explicit justification and review.

Parameter	Recommended Range	Default Reference (DEP2)	Purpose
KAT_per_Credit	1 – 10 KAT	5 KAT	Controls sensitivity and visibility of recognition
Global KAT cap / month / DAO	1,000 – 10,000 KAT	5,000 KAT	Controls inflation and scarcity of recognition
Per-user KAT cap / month	20 – 100 KAT	50 KAT	Prevents concentration and farming

These parameters apply to derived KAT only.
Credits and Karma remain independent and uncapped.

Design Intent

• Ranges, not fixed values: preserve DAO autonomy while keeping comparability
• Scarcity by design: KAT is a reputation signal, not points
• Future-proofing: conservative issuance in early cohorts protects future utility

 

6.2 Credit Rules

Each rule defines:

• Trigger event
• Applicable role(s)
• Verification requirement
• Credit amount

Credits are always issued first.

6.3 Karma Rules

Each rule defines:

• Quality signal(s)
• Evaluation window
• Resulting Karma level

Framework enforces:

• Karma is level-based
• Manual downgrade allowed
• No uncontrolled auto-promotion (unless DAO explicitly enables it)

6.4 Tier & Privilege Rules

Each DAO defines:

• Tier thresholds (based on DAO-earned KAT)
• Privileges unlocked per tier

The framework:

• Computes tiers
• Exposes privilege flags
• Does not interpret business meaning

7. Operational Lifecycle (Shared by All DAOs)

All Kambria DAOs operate the KAT Reward & Privilege Framework using two parallel but compatible operational tracks, depending on contributor type.

7.1 Track A - Application Contributors (Automated)

Applies to: Product or platform users whose contributions are system-verifiable (e.g. service providers, users, participants).

Automated Credit Generation

• Credits are generated automatically based on predefined rules
  (e.g. activity completion, attendance, feedback, journeys, referrals)
• Credits are:
  • Calculated per event
  • Logged automatically
  • Visible to contributors
• No DAO self-reporting is required

Automated Karma Evaluation

• Karma signals are collected automatically (e.g. ratings, no-shows, cancellations, reports)
• Default Karma = Normal
• Auto-downgrade applies for clear violations
• Auto-suggestions may be generated for higher levels
• Trusted Karma remains manual-only

Automated Periodic KAT Calculation

• System aggregates Credits
• Applies Karma multipliers and caps
• Generates KAT preview
• Executes settlement automatically
• DAO Organizer oversight is exception-based only

7.2 Track B - DAO Stakeholders (Monthly Self-Submission)

Applies to: DAO Members and ecosystem stakeholders whose contributions require human judgment.

DAO Monthly Reward Submission

• DAO submits proposed:
  • Credits
  • Karma levels
  • KAT calculations

DAO Organizer Audit & Execution

• DAO Organizer audits submissions
• Adjusts if needed
• Imports approved data
• Executes settlement

7.3 Unified Settlement & Ledger

Across both tracks:

• Credits are recorded in the same DAO-scoped ledger
• Karma uses shared level definitions
• KAT derivation follows the same canonical formula
• Global and per-user caps apply

The framework does not distinguish how data is sourced - only that it is verified.

 

7.4 Exception Handling

• Severe violations → immediate Karma downgrade
• Misreporting → audit correction and governance action
• Disputes → resolved in the next settlement cycle unless urgent

8. Safety & Guardrails (Framework-Level)

The framework enforces:

• ❌ No KAT minted per action

❌ No automatic irreversible payouts

❌ No market-bought KAT affecting DAO tiers

❌ No direct KAT ↔ cash equivalence in early phases

✅ Full auditability

✅ DAO-controlled parameters

✅ Pause & resume capability

 

9. Phase Awareness

The framework supports phased evolution.

Phase-1 (Default / Pilot)

• KAT used for recognition & privileges
• No revenue sharing
• Conservative caps
• Manual oversight

Phase-2+

• Economic participation may be introduced
• Cross-DAO privilege portability may be enabled
• Advanced governance integration possible

Phase logic is DAO-defined, framework-supported.

10. What This Framework Is Not

This framework is not:

• A payroll system
• A bounty engine
• A yield mechanism
• A speculation-driven token model

It is a trust-weighted contribution recognition framework.

11. Canonical Summary

The KAT Reward & Privilege Framework uses Credits to record contribution, Karma to evaluate trust and quality, and derives KAT to unlock privileges and long-term ownership signals across Kambria DAOs.

12. Governance Tokens (GT) - Council Rotation Model

GT represents time-bound governance responsibility, not reward or ownership.
GT is assigned through Council rotation, based on recent, trusted contribution, and is reassigned periodically rather than accumulated indefinitely.

GT is derived downstream of the KAT Reward & Privilege Framework using the same signal:

Governance Signal = Credits × Karma

 

12.1 Core Principles (Invariants)

• GT supply is fixed at DAO level
• GT is assigned to Council seats, not permanently owned by individuals
• GT is reassigned, not minted or burned
• Eligibility is based on recent contribution quality, not historical status
• No punitive slashing; inactivity results in non-renewal, not penalties

 

12.2 Council Rotation Policies (By DAO Type)

A. Ongoing DAO (e.g. CED)

• Evaluation Window: Year X
• Metric: cumulative Credits × Karma
• Council Selection: Top Active Members (max 50)
• Council Term: 1 year (Year X+1)
• GT Allocation: 8 GT per Council member
• GT Reassignment: GTs are reassigned from the previous Council cohort
• Total GT Supply: fixed (e.g. 400 GT)

This model prioritizes stability and continuity.

 

B. DEP DAO (Short-Cycle Variant)

• Evaluation Window: rolling last 2 months
• Metric: cumulative Credits × Karma
• Council Selection: Top Active Members (max 15)
• Council Term: 1 month (Month X+1)
• GT Allocation: 4 GT per Council member
• GT Reassignment: GTs are reassigned from the previous Council cohort
• Total GT Supply: fixed (e.g. 100 GT)

This model prioritizes responsiveness and participation.

 

12.3 Eligibility Requirements (Shared)

To qualify for Council consideration, a member must:

• Have Karma ≥ Normal
• Meet the minimum activity threshold (defined below)
• Not be under governance restriction or active dispute

 

12.4 Governance Effects

• Only current Council members hold GTs
• Governance voting power reflects recent trusted contribution
• Inactive members lose governance weight automatically and neutrally
• New members can qualify without rebalancing or redistribution

 

12.5 Operational Lifecycle - GT Council Rotation Execution

GT Council rotation is executed as part of the periodic DAO Organizer Audit & Execution process, using the same verified contribution signals as the KAT settlement.

This ensures governance assignment remains auditable, predictable, and aligned with actual contribution activity.

Periodic Execution (per cycle)

At the end of each governance evaluation period (monthly for DEP DAOs, yearly for ongoing DAOs), the DAO Organizer performs the following steps:

1. Freeze Contribution Signals
   • Freeze the relevant Credits × Karma data for the evaluation window
   • Ensure all contribution records and Karma reviews are finalized
2. Rank Eligible Members
   • Rank DAO members by Credits × Karma over the defined rolling window
   • Apply eligibility filters:
     • Karma ≥ Normal
     • Minimum activity threshold met
3. Determine Council Cohort
   • Identify the Top Active Members (up to the maximum Council size)
   • Confirm no governance restrictions apply
4. Execute GT Reassignment
   • Reassign GTs from the outgoing Council cohort to the incoming cohort
   • Assign the fixed GT amount per Council seat (e.g. 8 GT per member)
   • Enforce total GT supply invariants
5. Finalize Governance State
   • Publish the new Council roster
   • Update governance permissions and voting weights
   • Record the execution in the DAO governance log

Authority & Accountability

• The DAO Organizer is responsible for:
  • Correct execution of GT rotation
  • Ensuring compliance with framework rules
  • Maintaining an auditable record of decisions
• GT execution:
  • Is deterministic, not discretionary
  • Follows predefined rules
  • Does not require DAO-wide voting each cycle

Separation from Rewards

GT execution:

• Does not affect Credits, Karma, or KAT balances
• Does not introduce financial rewards
• Serves governance assignment only