EVANGEL DOCUMENTATION / 05
Governance and bounties
Proposals, evidence, challenges, releases, and the agent’s role.
Who decides
The platform governor, identity verifier, and challenge steward are controlled by 0x104093b31dFF44728f7CAA9C1bfc81A36F8F6e8C. This is a single founder authority, not an independent committee or token-holder voting system. Other project developers propose actions but do not inherit platform authority.
Proposal types
| Proposal | Purpose | Execution constraint |
|---|---|---|
| Developer release | Release reserve tokens to the developer | 20% cumulative ceiling and shared rolling limit |
| Community bounty | Commit tokens for a defined contribution | Protected community budget and award review |
| Fee policy | Change fee rates, recipients, or purpose | 5% maximum in each direction |
| Roadmap | Publish or revise project plans | Governor review and notice |
Review and challenge
A developer submits the requested action and terms. The governor approves or rejects it with a report. Approved actions have a two-day notice period before execution. A challenge submitted during the applicable window blocks execution until the steward resolves it.
The contract bounds challenges per review stage so the same resolved stage cannot be challenged repeatedly forever. An award is its own review stage. Read the current status and ready-at time instead of assuming an earlier approval is still executable.
Create and complete a bounty
A bounty defines work, acceptance criteria, and an amount. Each bounty amount cannot exceed the 210,000-token release ceiling. Approval reserves community budget; it does not pay a worker. An eligible worker submits evidence, and the governor selects an award.
The award has a notice/challenge period and joins the worker award queue. Execution must respect eligible earlier awards and the shared rolling release allowance. An unawarded bounty can be cancelled by the governor with a reason. Awarded bounties cannot be casually cancelled through that path.
Who can receive protected bounty tokens
The project developer and known platform authority wallets are excluded from worker submissions. This protects the community allocation from a direct developer claim. Wallet separation alone cannot prove different human control: hidden related parties remain an evidence-review risk.
What Kairence does
The agent can examine supplied evidence and discuss proposals. It must treat source documents as untrusted data, cite evidence, flag conflicts, and abstain when claims cannot be verified. Advice is not an approval or transaction.
The evaluator has no signing key. The deployer signs through a local wallet or encrypted keystore. The signing workflow rechecks context and evidence; model output cannot bypass contract limits. The owner can still submit direct contract calls, so offchain reviewer checks are a disclosed operational trust boundary. Kairence external-token enrollment is not yet confirmed.
Fee income
Buy and sell fees start at 2.1% each and can be changed only through the approved fee-policy flow, up to 5% in each direction. Fees can support business operations, contributors, inference, or other disclosed purposes.
The contract supports recipient splits and claimable fee credits. A blocked recipient should not prevent allocation to other recipients or freeze future fee-policy changes. Fee credits are denominated in the pool’s pairing asset, not the project token.