PLATFORM Constitution

Version 1.2 — the binding, primary source document of the protocol. Every rule enforced on-chain in this codebase traces back to an article here; see docs/CONSTITUTION_MAPPING.md in the repository for the article-by-article trace.

CONSTITUTION

PLATFORM

Community-Governed Attention Marketplace

Version: v1.2

This document is the binding, primary source document of the PLATFORM protocol.

The whitepaper and all other communication materials are subject to this Constitution.

Chapter 1 — Vision, Mission & Philosophy

1.1 Mission

The purpose of the Platform is to transform the attention economy of the internet into an open and transparent marketplace governed by the community.

In traditional models, visibility is distributed through advertising budgets, sponsored content, influencer deals, and centralized platform algorithms. This structure makes it possible to buy visibility while limiting the community's say over whether that visibility is earned.

The Platform aims to reverse this model. Projects may request attention. But the final right to decide on attention belongs to the community alone.

1.2 Vision

The Platform's long-term vision is to become the largest community-governed, on-chain attention marketplace, operating at a global scale. In this system: projects request visibility, the community decides, those who decide correctly are rewarded, and economic value flows back to the protocol and its participants.

1.3 Core Philosophy

The Platform is built on the following core principles:

Projects pay.

Community decides.

Voters earn.

Tokens burn.

Treasury grows.

Platform improves.

These principles form the foundation of all of the protocol's economic and governance decisions.

1.4 Community-Governed Attention

The Platform is not an advertising network. The Platform is not an influencer network. The Platform is not a sponsored-posting system. The Platform is defined as a Community-Governed Attention Marketplace.

In this model, a project may say "Share me." But it may not say "You must share me." The final decision always belongs to the community.

1.5 Attention Cannot Be Bought

One of the Platform's core principles is this: attention may be requested. Payment may be made for attention. But the authority to decide on attention cannot be purchased.

Therefore, paying a proposal fee, submitting a partnership offer, or holding a large amount of tokens does not guarantee that a piece of content will be published. Only the community renders that decision.

1.6 Transparency

All critical processes on the Platform are carried out on-chain. Examples include: proposal creation, voting, reward distribution, burn transactions, treasury movements, and vesting unlocks.

The system is designed to provide the highest possible level of verifiability and transparency.

1.7 Creator Philosophy

The Platform's founders:

are not arbiters,

are not a bank,

do not pick winners,

cannot change outcomes.

The founders' role is limited to developing the protocol, ensuring its security, and building its infrastructure.

1.8 Creator Alignment

The founders' success depends on the community's success. The system is therefore designed so that founders can benefit only when the platform grows.

Founders:

cannot vote,

cannot take a share of the reward pool,

cannot take a share of partnership revenue,

cannot change outcomes.

In return, they are incentivized through the Creator Reserve and the vesting mechanism.

1.9 No Creator Fee Principle

The Platform contains no Creator Fee mechanism of any kind. Revenue generated by the protocol is distributed among the community, the treasury, and burn mechanisms. There is no automatic revenue stream directed to the Creator Wallet.

1.10 Community First

The Platform's ultimate purpose is not to enrich the team, but to build a sustainable economic system governed by the community.

Therefore, throughout the protocol's design, community benefit, economic sustainability, trust, and transparency have been adopted as priority design principles.

1.11 Treasury Independence

The Treasury is not owned by the Creator Wallet. Treasury funds are designed to be used for the benefit of the protocol, the community, and long-term sustainability.

The Treasury may never be treated as a revenue source belonging to the Creator Wallet, under any circumstances.

Chapter 2 — Participants & Roles

2.1 Purpose

This chapter defines all participants in the Platform ecosystem, their authority, their responsibilities, their restrictions, and their roles within the system.

2.2 Participant Categories

The Platform consists of the following core participant groups:

Community Members

Projects

Creator Wallet

Treasury

Partnership Participants

Each participant holds only the authority defined for it by this Constitution. No participant may exercise an authority not explicitly granted to it.

2.3 Community Members

Definition

Community Members are users who hold the required minimum amount of the Platform token and participate in proposal processes. The community is the platform's core decision-making body.

Rights

Community members:

May vote on proposals.

May determine proposal outcomes.

May earn rewards.

May earn reputation.

May decide on treasury use.

Equality Principle

All eligible wallets within the community are equal. Every eligible wallet has 1 vote. There is no vote weighting. Token quantity does not confer additional voting power.

Community Sovereignty

Final decision-making authority on the Platform belongs to the community. No individual, institution, team member, or the Creator Wallet may change a decision made by the community.

2.4 Projects

Definition

Projects are individuals and organizations that seek visibility on the Platform, want to have content published, or want to obtain the community's opinion.

Rights

Projects:

May create proposals.

May pay proposal fees.

May submit content to the community.

May request the community's opinion.

Restrictions

Paying a proposal fee does not guarantee publication. Creating a proposal cannot influence the community's decision. Projects cannot change voting outcomes.

Attention Principle

Projects may request attention. But they may not claim a right to attention.

2.5 Creator Wallet

Definition

The Creator Wallet is the protocol's founding wallet. This wallet:

Holds the Creator Reserve.

May open a Governance Proposal.

May initiate an Emergency Pause.

Purpose

The purpose of the Creator Wallet is to:

propose protocol improvements,

protect security,

ensure system continuity.

Restrictions

The Creator Wallet:

cannot vote,

cannot earn rewards,

cannot change proposal outcomes,

cannot interfere with reward distribution,

cannot change proposal rankings,

cannot see the blind-voting process,

cannot take a share of partnership revenue.

Governance Restriction

Governance Proposals opened by the Creator Wallet may only benefit the protocol. They cannot create an economic advantage for the Creator Wallet.

Creator Alignment

The Creator Wallet's economic incentive is limited solely to:

the Initial Creator Allocation,

the Vesting Allocation.

2.6 Treasury

Definition

The Treasury is a shared capital pool that belongs to the protocol. The Treasury does not belong to any individual or organization.

Ownership Principle

The owner of the Treasury:

is not the Creator.

is not the team.

is not the proposal owners.

The Treasury is held in the name of the protocol.

Purpose

The Treasury may be used for the following purposes:

development

infrastructure

security audits

hiring

buyback transactions

strategic growth activities

Restrictions

Treasury funds cannot be transferred to the Creator Wallet, cannot be converted into team income, and cannot be used for the direct benefit of the founder.

Community Authority

Final decision-making authority over the Treasury belongs to the community.

2.7 Partnership Participants

Definition

Partnership Participants are institutions and projects that wish to form an economic or strategic partnership with the protocol.

Examples

Example participants:

Wallet providers

Exchanges

Launchpads

Infrastructure providers

Protocols

Institutional partners

Rights

Partnership Participants may create a Partnership Proposal and may present an economic offer to the community.

Restrictions

Making an economic offer does not guarantee an outcome. Partnership payments do not go to the Creator Wallet.

Community Approval Requirement

No partnership agreement may take effect without community approval.

2.8 Rule of Limited Authority

All authority within the Platform is limited. No participant:

can change outcomes,

can change reward distribution,

can change the burn mechanism,

can invalidate proposal results.

This principle is a cornerstone of the platform's decentralization goal.

2.9 Final Principle

The Platform's power comes not from the Creator Wallet, the team, or any institution, but from the community.

Therefore, all critical decisions are made by the community and implemented on-chain.

Chapter 3 — Proposal System

3.1 Purpose

The Proposal System forms the foundation of all decision-making processes on the Platform.

No content published on the Platform, no partnership executed, no treasury funds used, and no governance change applied can occur outside the proposal process.

The proposal system is designed to measure and implement the will of the community.

3.2 Proposal Definition

A proposal is a formal voting request created for the purpose of a community decision. Every proposal:

addresses a single subject,

asks a clear question,

produces a YES or NO result.

Single Decision Principle

A proposal may contain only a single decision.

Example — Correct: "Should PLATFORM publish Project X's post?"

Example — Incorrect: "Should PLATFORM publish Project X's post, and should a new logo be used?"

A proposal cannot contain more than one independent decision.

3.3 Proposal Lifecycle

Every proposal follows the lifecycle below: Stage 1 — Proposal Creation → Stage 2 — Voting Period → Stage 3 — Finalization → Stage 4 — Automatic Settlement → Stage 5 — Archival.

Once this process is complete, the proposal cannot be changed.

3.4 Proposal Duration

Proposal duration must be a minimum of 2 hours and a maximum of 24 hours.

Invalid Durations

Proposals under 2 hours cannot be created. Proposals over 24 hours cannot be created.

Tie Exception

These minimum and maximum duration limits apply except for proposals reopened as a result of a tie. The duration of a proposal reopened after a tie is subject to Section 4.17 and may be under 2 hours.

Purpose

This rule is applied to ensure sufficient participation, prevent endless voting periods, and reduce spam.

3.5 Proposal Finality

The moment a proposal is created, it:

cannot be changed,

cannot be edited,

cannot be updated,

cannot be deleted,

cannot be cancelled.

Finality Principle

Creating a proposal is an irreversible action. The proposal continues even if its owner later changes their mind.

Reasoning

This rule is applied to prevent manipulation, build trust, and protect community confidence.

3.6 Proposal Cancellation

The Platform contains no proposal-cancellation mechanism of any kind. Once a proposal is created, voting is completed regardless of outcome.

No Emergency Cancellation

No party, including the Creator Wallet, may cancel an active proposal.

3.7 Active Proposal Capacity

The Platform supports an unlimited number of simultaneous active proposals.

Economic Principle

More proposals produce more fees, more rewards, more burn, and more participation. There is therefore no artificial limit on active proposals.

3.8 Wallet Proposal Limit

A single wallet may create only 1 active proposal at a time.

Purpose

This rule is applied to reduce spam, prevent proposal monopolization, and distribute visibility fairly.

3.9 Proposal Categories

The Platform supports the following proposal types:

Content Proposal

Poll Proposal

Treasury Proposal

Governance Proposal

Partnership Proposal

Proposals cannot be created outside these categories.

3.10 Content Proposal

Purpose

To determine whether a piece of content is published.

Example

"Should PLATFORM publish Project X's post?"

Outcomes

YES → The content is published. NO → The content is not published.

When the Platform hosts hundreds of proposals, ranking is based on the level of participation and competitiveness.

Ranking Priority

Total Vote Count

Closeness of Outcome

Reasoning

The community should see the most important and most contested proposals first.

3.16 Scheduled Proposals

Proposal owners may determine in advance when a proposal will be published.

Purpose

This feature enables marketing planning, announcement preparation, and community coordination.

3.17 Upcoming Proposal Visibility

Users holding sufficient tokens may see upcoming proposals.

Visible Information

Proposal owner

Project name

Publication time

Hidden Information

Proposal content

Voting subject

Proposal text

Purpose

This mechanism allows projects to build hype in advance.

3.18 Proposal Confidentiality

The content of scheduled proposals remains confidential until publication time.

Information Symmetry

No user, no team member, and no partner has early access rights.

3.19 Proposal Immutability Principle

From the moment a proposal is created:

its content cannot be changed,

its duration cannot be changed,

its category cannot be changed,

its outcome cannot be influenced.

This principle applies to all proposal types.

3.20 Final Principle

Every decision on the Platform begins with a proposal. The community's decision is measured through proposals. The system's will is determined by proposal outcomes. The proposal system is the platform's core governance mechanism.

Chapter 4 — Voting System

4.1 Purpose

The Voting System is designed to measure and implement the will of the community. All binding decisions on the Platform are determined as a result of the voting process.

The voting system is built on the principles of equality, transparency, resistance to manipulation, and long-term participation.

4.2 Voting Authority

Final decision-making authority on the Platform belongs to the community. No individual, institution, project, or partner may invalidate a decision made by the community.

4.3 Eligible Voters

To vote, a user must meet the minimum token requirement and maintain eligibility throughout the proposal's duration. Votes cast by users who lose eligibility are considered invalid.

4.4 Equal Voting Principle

All eligible wallets on the Platform are equal. Every eligible wallet has 1 vote.

No Vote Weighting

There is no vote weighting. Holding more tokens does not confer more votes, greater voting power, or extra representation rights.

Purpose

This mechanism is applied to reduce whale influence, increase participation, and create a community-centered decision-making process.

4.5 Vote Types

Every proposal offers only two voting options: YES, which supports the proposal, and NO, which opposes it. No other vote types exist.

4.6 Blind Voting System

All proposals use the Blind Voting model.

Hidden Information

While a proposal is active, the following cannot be displayed:

total vote count,

YES ratio,

NO ratio,

intermediate results,

the temporary leading side.

Disclosure

This information is disclosed only after the proposal concludes.

Purpose

Blind Voting is applied to reduce the following risks: herd psychology, last-minute manipulation, social pressure, and strategic voting behavior.

4.7 Vote Privacy

Although the act of voting is verifiable on-chain, aggregate visibility that could affect outcomes is not provided while a proposal is active.

Principle

Decisions should be made based on opinions, not on results.

4.8 Voting Eligibility Thresholds

The minimum token amount required to vote is determined according to the protocol's market-cap level.

Market Cap

Minimum Holding

≤ $500,000

$10

> $500,000

$50

> $2,500,000

$100

> $12,500,000

$250

> $67,500,000

$500

> $312,500,000

$1,000

Purpose

This mechanism is applied to make sybil attacks more difficult, improve vote quality, and strengthen economic commitment.

4.9 Early Holder Principle

As the Platform grows, the voting threshold rises. However, users who hold tokens at an early stage naturally gain an advantage.

Example

A user who buys $10 worth of tokens while market cap is $100,000 may continue to meet higher thresholds as the token appreciates in value.

Principle

Early participation should produce a long-term advantage.

4.10 Long-Term Holder Protection

Once market cap rises above $2,500,000, additional security rules take effect.

Requirement A

To vote, a user must have held the required minimum token amount for at least 7 days before the proposal begins.

Requirement B

Eligibility must be maintained after voting until the proposal concludes.

Purpose

This mechanism is applied to reduce temporary vote-buying, short-term manipulation, and proposal-based speculation.

4.11 Continuous Eligibility

A user who falls below the required minimum token amount during a proposal's duration loses eligibility.

Result

In that case, the corresponding vote is considered invalid.

4.12 Sybil Resistance Framework

The Platform's aim is to make it difficult for a single individual to artificially increase their voting power by creating a large number of wallets.

Protection Layers

Layers of protection:

Minimum holding requirement

Market-cap-based thresholds

A 7-day holding requirement (only once market cap exceeds $2,500,000, see 4.10)

Continuous eligibility checks

Principle

The system does not promise flawless sybil resistance. However, it aims to continuously raise the economic cost of manipulation.

4.13 Vote Finality

A cast vote cannot be withdrawn.

Restrictions

A vote:

cannot be changed,

cannot be cancelled,

cannot be resubmitted.

Purpose

This rule is applied to reduce manipulation and increase the reliability of outcomes.

4.14 Proposal Outcome

At the conclusion of a proposal, one of the YES or NO sides wins.

Winning Side

The winning side determines the proposal's outcome.

Losing Side

The losing side does not take a share of the reward pool.

4.15 Reward Eligibility

To receive a reward, a user must:

be on the winning side,

maintain eligibility requirements.

Equal Distribution

Reward distribution is made equally per wallet.

No Reward Weighting

Holding more tokens does not confer a right to a larger reward.

4.16 Equal Reward Principle

The Platform rewards participation, not voting power.

Formula

Every eligible wallet on the winning side receives an equal reward.

Example

Reward Pool: 700 tokens. Winning vote count: 70. Each winner receives 10 tokens.

4.17 Tie Resolution

If the YES and NO sides end in an exact tie, the proposal is not considered concluded.

Immediate Effect

No rewards are distributed.

Reopening

The proposal is reopened free of charge.

Duration

The new proposal duration is 20% of the original proposal's duration.

Example

If the first proposal lasted 10 hours, the second proposal lasts 2 hours.

This reopening duration is an exception to the 2-hour minimum proposal duration defined in Section 3.4, and may be under 2 hours.

4.18 Tie Participation Requirement

To be eligible for a reward in a reopened proposal, a user must have voted in both the first and the second round.

Purpose

This rule is applied to protect first-round participants.

4.19 Final Reward Eligibility

In the second vote held after a tie, only users on the final winning side receive a reward.

Additional Requirement

However, to receive a reward, a user must have voted in the first round, regardless of which side they chose.

Example

First round: YES. Second round: NO. If a user voted YES in the first round and NO in the second round, and NO won, that user may receive a reward.

4.20 Creator Restrictions

The Creator Wallet cannot vote.

Reasoning

Founders are infrastructure providers, not decision-makers.

4.21 Governance Neutrality Extension

The Creator Wallet's inability to vote is the balancing counterpart to its authority to open Governance Proposals.

Principle

The right to propose and the right to decide are kept separate.

4.22 Final Principle

On the Platform, voting power comes not from capital, but from participation. Every eligible wallet is equal. Every vote is equal. Every decision is made by the community.

Chapter 5 — Token Economics & Fee Distribution

5.1 Purpose

This chapter defines the economic flows within the protocol, reward mechanisms, burn mechanisms, treasury growth, and economic incentives.

The Platform economy is designed to pursue the following goals:

Reward participation

Make spam costly

Build the treasury

Reduce supply

Protect community interests

5.2 Economic Philosophy

The Platform's economic model is built on this principle: requesting attention is costly; deciding is rewarded. The party creating a proposal therefore bears the cost, while the community earns a reward in return for participation.

5.3 No Creator Fee Principle

The Platform contains no Creator Fee mechanism of any kind.

Definition

A Creator Fee is the automatic transfer of a fixed percentage of protocol-generated revenue to the Creator Wallet.

Restriction

The Platform contains none of the following: Creator Tax, Creator Fee, Founder Fee, Platform Fee.

Purpose

This rule is applied to center community interests, not founder interests.

5.4 Proposal Fee Requirement

Creating any proposal requires a fee to be paid.

Purpose

Proposal fees reduce spam, build the reward pool, generate burn, and grow the treasury.

Economic Principle

Creating a proposal is costly. Voting is free.

5.5 Market Cap Based Fee Scaling

Proposal fees increase as the platform grows.

Fee Schedule

Market Cap

Proposal Fee

≤ $500,000

$50

> $500,000

$100

> $2,500,000

$150

> $12,500,000

$200

> $67,500,000

$250

> $312,500,000

$500

> $1,250,000,000

$1,000

Purpose

As the Platform grows, proposal value, visibility value, and the cost of spam all rise.

5.6 Proposal Fee Settlement

The fee is collected the moment a proposal is created.

Non-Refundable Rule

The fee is not refunded even if the proposal is rejected.

Purpose

A proposal owner does not purchase an outcome. They purchase only the right to a vote.

5.7 Standard Fee Distribution

Every proposal fee is distributed as follows:

70% Reward Pool

20% Burn

10% Treasury

Formula

When a 100-token fee is paid:

70 tokens to reward

20 tokens to burn

10 tokens to treasury

5.8 Reward Pool

The Reward Pool is distributed to community members who voted on the winning side.

Ownership

The Reward Pool does not belong to the Creator Wallet. It does not belong to the Treasury. It does not belong to the proposal owner.

Purpose

Its purpose is to incentivize participation.

5.9 Equal Reward Distribution

Reward distribution is made equally.

Principle

Holding more tokens does not confer a right to a larger reward.

Example

For a calculation example, see Section 4.16, Equal Reward Principle.

5.10 Treasury Allocation

10% of every proposal fee is transferred to the treasury.

Purpose

To ensure long-term sustainability.

Growth Principle

The treasury grows as the Platform is used.

5.11 Burn Allocation

20% of every proposal fee is burned.

Purpose

To reduce supply. To create long-term value. To support community interests.

5.12 Automatic Settlement

When a proposal concludes, reward distribution, the burn transaction, and the treasury transfer are all carried out automatically.

Human Intervention

No individual can change the distribution, change the burn amount, or change the treasury share.

5.13 Economic Neutrality

Proposal fees do not affect the outcome.

Principle

Paying more does not create a higher chance of success.

Result

Economic power does not translate into voting power.

5.14 Participation Economy

The Platform's economic model aims to turn token holders into active participants, not merely investors.

Philosophy

Participation is economically rewarded. Passivity is not rewarded.

5.15 Treasury Revenue Sources

To limit economic privileges.

5.20 Sustainable Economics

The Platform economy does not depend on a continuous inflow of new users.

Revenue Source

Value creation occurs through proposal demand, partnership demand, and community participation.

Principle

Economic activity is more important than speculation.

5.21 Final Principle

The Platform economy is designed to reward participants, not founders.

Creating a proposal is costly. Deciding is valuable. Participation is rewarded. Supply is reduced. The treasury grows. The protocol becomes stronger.

Chapter 6 — Treasury System

6.1 Purpose

The Treasury is a shared capital pool created to ensure the Platform's long-term sustainability.

The purpose of the Treasury is to: develop the protocol, increase security, support growth, and finance decisions made for the community's benefit.

The Treasury is not a revenue-sharing mechanism.

6.2 Treasury Definition

The Treasury is a shared asset pool that belongs to the protocol and is held in the name of the community.

Ownership Principle

The owner of the Treasury: is not the Creator Wallet, is not the team, is not the proposal owners, is not the partnership participants. The Treasury belongs to the protocol alone.

6.3 Treasury Independence

The Treasury is independent. There is no ownership relationship between the Creator Wallet and the Treasury.

Principle

The Creator Reserve is different. The Treasury is different. These two structures are entirely separate from one another.

Purpose

This separation is applied to increase investor confidence, reduce conflicts of interest, and lower centralization risk.

6.4 Treasury Revenue Sources

The Treasury grows from the following sources:

Proposal Fees

10% of every proposal fee.

Partnership Proposals

The treasury share from accepted partnership offers.

Monthly Vesting Allocation

The treasury share from Creator Reserve unlocks.

Future Community Approved Sources

New sources approved by the community in the future.

6.5 Treasury Asset Policy

The Treasury holds only the platform token.

External Assets

Incoming SOL, USDC, USDT, ETH, BTC, and all other assets are immediately converted into the platform token.

Purpose

To ensure the Treasury remains directly tied to the platform's success.

6.6 Treasury Usage Categories

The Treasury may be used for the following purposes:

Development

Software development.

Security

Security audits.

Infrastructure

Server and infrastructure expenses.

Hiring

Hiring approved by the community.

Buybacks

Token buybacks.

Strategic Growth

Activities that support the Platform's growth.

6.7 Treasury Restrictions

The Treasury cannot be used for the following purposes:

Creator Compensation

Payments to founders.

Team Bonus

Team bonuses.

Personal Expenses

Personal expenses.

Undisclosed Transfers

Non-transparent transfers.

6.8 Community Authority

Final decision-making authority over the Treasury belongs to the community.

Requirement

Treasury use is possible only through a Treasury Proposal.

No Manual Spending

No individual may spend treasury funds directly, withdraw funds from the treasury, or move treasury assets.

6.9 Treasury Proposal Requirement

A Treasury Proposal must be created for treasury use.

Execution Categories

Approved Treasury Proposals fall into two categories depending on the type of execution they require:

On-Chain Execution (Requires No Human Intervention)

Carrying out a buyback

Carrying out a burn from treasury funds

Off-Chain Execution (Requires Human Intervention)

Approval is finalized on-chain and the relevant funds are released, but the actual work (audit process, contracting, hiring, etc.) is carried out off-chain by parties authorized by the community.

Commissioning a security audit

Hiring a new developer

Expanding server infrastructure

Principle

Treasury spending must be based on the will of the community.

6.10 Treasury Transparency

All treasury movements must be verifiable on-chain.

Visibility

The community can see: the treasury balance, treasury inflows, treasury outflows, buyback transactions, and spending history.

6.11 Treasury Buyback Authority

A buyback may be carried out through a Treasury Proposal.

Purpose

The purpose of a buyback is to reduce supply, increase community confidence, and support protocol value.

6.12 Buyback Settlement

Tokens purchased by the Treasury do not return to free circulation.

Locked Treasury Vault

Buyback tokens are transferred to the Locked Treasury Vault.

Restrictions

These tokens cannot be sold, cannot be transferred, and cannot be distributed as rewards.

6.13 Buyback Neutrality

Buyback transactions cannot be used to benefit the Creator Wallet.

Principle

The purpose of a buyback is to strengthen the protocol, not the founder.

6.14 Treasury Sustainability Principle

The Treasury is not an unlimited source of spending.

Long-Term Objective

The Treasury must be managed in a way that can support the Platform for years to come.

Reasoning

The treasury must not be depleted for short-term benefit.

6.15 Treasury Risk Management

Security, sustainability, and transparency must be the priority evaluation criteria in treasury decisions.

Priority Order

Security

Continuity

Growth

6.16 Treasury and Governance Separation

A Governance Proposal and a Treasury Proposal are different from one another.

Governance

Protocol rules.

Treasury

Protocol resources.

Principle

Changing a rule and using a resource are not the same process.

6.17 Treasury Cannot Override Governance

The size of the treasury does not create decision-making power.

Result

A larger treasury does not mean greater voting power.

6.18 Governance Cannot Seize Treasury

A Governance Proposal cannot be used to take over the treasury, transfer it to the creator, or place it under team control.

Protection

This rule protects treasury independence.

6.19 Treasury Integrity Principle

The Treasury exists to finance the protocol's future.

Therefore

The Treasury is not a reward pool. It is not a team budget. It is not a revenue-sharing mechanism.

6.20 Final Principle

The Treasury is the Platform's shared capital. It is owned by neither the Creator Wallet, the team, nor any investor. The Treasury exists solely for the protocol's long-term success.

Chapter 7 — Creator Reserve & Vesting

7.1 Purpose

This chapter defines the structure of the Creator Reserve, the vesting mechanism, the founder-incentive model, and investor-protection rules.

The purpose of this chapter is to provide sufficient incentive for founders to develop the Platform, while protecting the community's trust.

7.2 Total Supply

The total supply of the Platform token is fixed at 1,000,000,000 tokens.

Fixed Supply Principle

Total supply is fixed. No new tokens can be minted.

Inflation Restriction

The Platform contains no inflation mechanism of any kind.

7.3 Creator Reserve

200,000,000 tokens of total supply is allocated as the Creator Reserve.

Composition

The 200,000,000-token Creator Reserve is divided as follows:

180,000,000 tokens — Locked Creator Reserve (see 7.5),

10,000,000 tokens — Initial Liquid Allocation (see 7.4),

10,000,000 tokens — Genesis Security Reserve (see 7.5A).

The Genesis Security Reserve is not a separate additional allocation from total supply; it is a sub-component of the Creator Reserve.

Allocation

This amount corresponds to 20% of total supply.

Purpose

The purpose of the Creator Reserve is to create development motivation, ensure long-term commitment, and tie founder incentives to community success.

7.4 Initial Liquid Allocation

Only 10,000,000 tokens of the Creator Reserve is free at genesis.

Purpose

This amount may be used for development costs, infrastructure expenses, initial operations, security audits, legal expenses, and the covering or reimbursement of reasonable and verifiable costs incurred by the Creator during the development and setup of PLATFORM.

Creator Discretion

The decision on the use of this portion belongs to the Creator Wallet.

7.5 Locked Creator Reserve

180,000,000 tokens of the Creator Reserve is locked on-chain at genesis as the Constitutional Vesting Reserve.

On-Chain Lock

This lock is enforced on-chain.

Visibility

The community can verify the locked amount, the remaining duration, and the unlock schedule.

Constitutional Protection

This reserve can be unlocked only according to the vesting rules defined in this Constitution.

7.5A Genesis Security Reserve

10,000,000 tokens from within the Creator Reserve (see 7.3 Composition) is allocated as the Genesis Security Reserve.

Purpose

This reserve was created to reward participants who identify security vulnerabilities, economic exploits, governance exploits, treasury exploits, and sybil attack scenarios.

Beta Phase

The Genesis Security Reserve may be used only during the Beta Phase.

Maximum Reward

The maximum reward that can be granted to a single participant is set at 100,000 tokens.

Restriction

The Genesis Security Reserve: cannot be transferred to the Creator Wallet, cannot be transferred to the Treasury, cannot be used in partnership payments, and cannot be redirected to any other purpose.

Burn Requirement

Upon the end of the Beta Phase, all undistributed Genesis Security Reserve tokens are permanently burned.

7.6 Vesting Schedule

5,000,000 tokens unlock from the locked reserve every month.

Fixed Schedule

The unlock amount is fixed.

Predictability Principle

The community knows future unlocks in advance.

7.7 Monthly Unlock Distribution

Each monthly unlock is distributed as follows:

Treasury

50% → 2,500,000 tokens

Burn

25% → 1,250,000 tokens

Team Allocation

25% → 1,250,000 tokens

Purpose

This model balances treasury growth, supply reduction, and founder incentive.

7.8 Creator Alignment Principle

Founders obtain meaningful benefit only when the Platform grows.

Reasoning

The bulk of the Creator Reserve is not immediately accessible.

Result

Founders' interests lie not in short-term sales, but in long-term growth.

7.9 Vesting Immutability

The vesting system cannot be changed.

Governance Restriction

A Governance Proposal cannot be used to accelerate unlocks, increase the unlock amount, or create a new reserve.

Purpose

To protect the community's trust.

7.10 Vesting Reduction Rule

Future unlocks may only be reduced.

Allowed Actions

Example: 5M → 4M, 5M → 3M, 5M → 2M.

Forbidden Actions

5M → 6M, 5M → 7M, 5M → 10M.

Principle

Risk must not be increased — only decreased.

Additional Restriction

A Governance Proposal cannot increase the Genesis Security Reserve, create a new Genesis Security Reserve, or extend the Beta Phase.

7.11 Creator Reserve Protection

The Creator Reserve is not the Treasury.

Separation Principle

The Creator Reserve and the Treasury are two different economic structures.

Result

Treasury funds cannot be transferred to the Creator Reserve. The Creator Reserve cannot be converted into the Treasury (except for the vesting distribution separately accepted by the community).

7.12 Creator Wallet Definition

The Creator Wallet is the Platform's official founding wallet.

Authority

The Creator Wallet: may open a Governance Proposal, may initiate an Emergency Pause, and holds the Creator Reserve.

7.13 Creator Wallet Visibility

The Creator Wallet is not hidden.

Transparency Principle

The community can see the Creator Wallet's address, its balance, and its transactions.

Purpose

To ensure transparency.

7.14 Creator Wallet Replacement

The Creator Wallet may be replaced.

Requirement

Replacing the Creator Wallet is possible only with community approval.

Mechanism

A Governance Proposal must be created for this purpose.

Approval Threshold

Standard Governance Proposal rules apply.

7.15 Creator Wallet Continuity

Even if the Creator Wallet changes, the vesting rules do not change.

Principle

The person may change. The rules do not change.

7.16 Creator Vote Restriction

The Creator Wallet cannot vote.

Purpose

To separate founder interests from community decisions.

7.17 Creator Reward Restriction

The Creator Wallet cannot take a share of the reward pool.

Result

The founder cannot access participation rewards.

7.18 Creator Partnership Restriction

The Creator Wallet cannot take a share of Partnership Proposal revenue.

Principle

Institutional agreements are made for the benefit of the protocol, not the founder.

7.19 Economic Fairness Principle

The Creator Reserve exists to incentivize the founder. It is not a community fund.

The Treasury, on the other hand, exists for the community's benefit. It is not a founder fund.

This separation is a fundamental economic balance of the system.

7.20 Long-Term Commitment Principle

The purpose of the Creator Reserve is to keep founders committed to the Platform over the long term.

Therefore

Founders' economic success depends on the Platform's success.

Alignment

If the community wins, the founder wins. If the community loses, the founder also loses.

7.21 Final Principle

The Creator Reserve is not a privilege — it is a long-term responsibility mechanism.

The vesting system must be predictable, transparent, on-chain, and immutable.

This principle is one of the cornerstones of investor confidence.

Chapter 8 — Governance System

8.1 Purpose

The Governance System ensures the management of the protocol's core rules, its operating mechanisms, and its future direction of development.

The purpose of Governance is to develop the protocol, increase security, and protect sustainability — not to generate economic privilege.

8.2 Governance Philosophy

Governance exists not for founders to establish dominance over the community, but to protect the long-term health of the protocol.

Principle

Governance's role is not to accumulate power, but to constrain it.

8.3 Governance Proposal Authority

A Governance Proposal can be created only by the Creator Wallet.

Exclusive Authority

No other wallet may create a Governance Proposal.

Reasoning

Protocol changes require coordination, technical expertise, and system integrity. For this reason, the authority to open a Governance Proposal is limited.

8.4 Governance Proposal Scope

A Governance Proposal may be used on the following subjects:

Protocol Improvements

Protocol improvements.

Security Enhancements

Security improvements.

Infrastructure Upgrades

Infrastructure updates.

Operational Improvements

Operational improvements.

Community Requested Improvements

Improvements requested by the community.

Community Request Mechanism

The community can request a change via a standard proposal (for example, a Poll Proposal). However, only the Creator Wallet decides whether that request is converted into a formal Governance Proposal.

Purpose

This mechanism prevents fixed rules under constitutional protection (such as the 70% Reward Pool ratio) from being effectively altered through a bad-faith standard proposal. Here, the Creator Wallet acts as a filter that evaluates the request's constitutional compliance; it does not determine the content or outcome of the request.

8.5 Governance Proposal Restrictions

A Governance Proposal cannot be used for the following purposes:

Creator Enrichment

Providing an economic advantage in favor of the Creator.

Team Compensation

Making payments to the team.

Treasury Extraction

Transferring treasury funds for the team's benefit.

Vote Manipulation

Changing the voting system in favor of a particular group.

Reward Manipulation

Changing the reward system in favor of particular individuals.

8.6 Governance Neutrality Principle

A Governance Proposal may only benefit the protocol.

Requirement

It is forbidden for a Governance Proposal to provide an economic advantage to the Creator Wallet, whether directly, indirectly, or covertly.

Purpose

To prevent abuse of the governance mechanism.

8.7 Community Benefit Requirement

Every Governance Proposal must clearly produce a benefit for the community.

Burden of Proof

Disclosing the benefit to be provided to the community is mandatory.

Invalid Governance Proposal

Proposals that benefit only the team are considered invalid.

8.8 Governance Approval Threshold

For a Governance Proposal to be accepted, it must reach an 80% YES ratio.

Definition

At least 80% of valid votes cast must be YES.

Purpose

To prevent protocol rules from being changed easily.

8.9 Supermajority Principle

Governance changes are not evaluated like ordinary proposals.

Reasoning

Protocol rules require a higher level of protection than day-to-day operations.

Therefore

A simple majority is not sufficient.

8.10 Governance Rejection

A Governance Proposal that fails to reach the 80% threshold is rejected.

Effect

The existing rules remain in effect.

8.11 Governance and Voting Separation

The right to create a Governance Proposal and the right to vote are kept separate.

Creator Limitation

The Creator Wallet may create a Governance Proposal. However, it cannot vote.

Purpose

To separate the power to propose from the power to decide.

8.12 Governance and Treasury Separation

The Governance system cannot substitute for the Treasury system.

Restriction

A Governance Proposal cannot be used to spend treasury funds, transfer treasury funds, or redistribute treasury resources.

Requirement

These transactions require a Treasury Proposal.

8.13 Governance and Vesting Separation

The Governance system cannot override the Creator Vesting system.

Forbidden Actions

A Governance Proposal cannot increase the monthly unlock, create a new reserve, remove locks, or accelerate vesting.

8.14 Vesting Protection Principle

The Creator Reserve rules cannot be eroded by Governance.

Purpose

To protect investor confidence.

8.15 Governance and Reward Separation

A Governance Proposal cannot direct the reward pool to particular individuals, cannot manipulate reward distribution, and cannot remove the equal-distribution principle.

Principle

Participant equality must be preserved.

8.16 Governance and Voting Equality

A Governance Proposal cannot be used to create vote weighting, introduce a whale advantage, or grant privileges to particular wallets.

Purpose

To protect the 1 Wallet = 1 Vote principle.

8.17 Governance and Creator Wallet

The existence of the Creator Wallet may be removed by Governance.

Requirement

Community approval is required.

Example

Replacing the Creator Wallet. Appointing a new Creator Wallet.

Restriction

However, this change does not change the Creator Reserve rules.

8.18 Governance Transparency

All Governance Proposals must be public, verifiable, and traceable on-chain.

Visibility

The community can review the proposal text, the outcome, and its implementation status.

8.19 Governance Immutability Principle

Accepted Governance Proposals take effect automatically.

Result

No individual can halt the outcome, change the outcome, or block its implementation.

8.20 Governance Integrity Principle

The purpose of Governance is not to change the rules, but to develop them while preserving them.

Therefore

Every Governance Proposal must be compatible with the protocol's core principles.

8.21 Constitutional Protection Layer

The following principles cannot be violated by Governance:

Community Sovereignty

Community supremacy.

Voting Equality

1 Wallet = 1 Vote.

Creator Vote Restriction

The Creator cannot vote.

Treasury Independence

The Treasury is independent.

Vesting Protection

Vesting cannot be increased.

Proposal Finality

A proposal cannot be cancelled.

These principles are under constitutional protection.

8.22 Final Principle

The Governance system is designed not for founders to gain power over the community, but for the community to be able to safely develop the protocol.

The purpose of Governance is not to grant authority, but to constrain it.

For this reason, the Governance system has high thresholds, strict restrictions, and constitutional protections.

Chapter 9 — Partnership System

9.1 Purpose

The Partnership System is the formal mechanism that allows third-party organizations to engage with the community.

This system aims to establish transparent, on-chain collaborations between the community and wallet providers, exchanges, protocols, infrastructure companies, brands, and institutional partners.

9.2 Partnership Philosophy

The community's attention and behavior on the Platform is a valuable resource. However, this resource does not belong to the Creator Wallet, cannot be sold by the team, and cannot be transferred through private agreements.

Principle

Access to the community's attention may be requested. However, this access can be granted only with the community's approval.

9.3 Partnership Participants

A Partnership Participant is an individual or organization that wishes to establish an economic or strategic engagement with the platform community.

Examples

Example participants:

Wallet providers

Centralized exchanges

Decentralized exchanges

Launchpad platforms

Data providers

Security firms

Infrastructure providers

Commercial brands

9.4 Partnership Proposal Requirement

Any institutional offer directed at the community must be submitted as a Partnership Proposal.

Restriction

Offers made outside a Partnership Proposal are considered invalid.

Purpose

To bring all collaborations on-chain.

9.5 Partnership Proposal Fee

The cost of creating a Partnership Proposal is 20 times the standard proposal fee.

Example

If the standard proposal fee is 100 tokens, the Partnership Proposal fee is 2,000 tokens.

9.6 Premium Access Principle

Institutional access is more valuable than standard proposal access. It therefore requires a higher cost.

Purpose

This mechanism reduces spam, encourages serious institutions, and protects the community's time.

9.7 Partnership Proposal Scope

A Partnership Proposal may be used for the following purposes:

Community Actions

Requesting specific behavior from the community.

Strategic Cooperation

Offering strategic collaboration.

Ecosystem Integration

Presenting integration proposals.

9.8 Community Action Example

Example: a wallet provider might present an offer such as, "We want voting users to use Solflare. In return, we will pay $50,000."

Important Principle

This offer is not made to the Creator Wallet. It is made to the community.

9.9 Community Sovereignty

No institution can buy the community's behavior.

Requirement

Every offer must be approved by the community.

Result

Offering payment does not guarantee approval.

9.10 Partnership Approval

Partnership Proposals are subject to standard voting rules.

Outcome

YES → The offer is accepted. NO → The offer is rejected.

9.11 Partnership Settlement

Payment is received for accepted offers.

Principle

The payment does not go to the Creator Wallet. It does not go to a team wallet. It does not become founder revenue.

9.12 Treasury Asset Policy Extension

All assets received under a partnership are first converted into the platform token.

Examples

SOL, USDC, USDT, ETH, BTC, and all other assets.

Purpose

So that the Treasury holds only the platform token.

9.13 Partnership Distribution Formula

Once the token conversion is complete:

50% Burn

Is burned.

50% Treasury

Is transferred to the treasury.

Formula

If 100,000 tokens are obtained: 50,000 tokens Burn, 50,000 tokens Treasury.

9.14 No Creator Revenue Principle

The Creator Wallet cannot take a share of partnership revenue.

Restrictions

The Creator Wallet cannot receive payment, cannot receive commission, and cannot receive a fee.

Purpose

To ensure that institutional agreements are made for the community's benefit.

9.15 No Hidden Agreements

Secret agreements made outside the Platform are not valid.

Requirement

Every agreement that affects the community must be submitted through a Partnership Proposal.

Purpose

To protect transparency.

9.16 Transparency Requirement

All Partnership Proposals must be public, verifiable, and traceable on-chain.

Visibility

The community can review the offering institution, the terms of the offer, the payment amount, and the outcome.

9.17 Institutional Equality Principle

Institutional size does not create voting power.

Example

One of the world's largest companies and a small startup are subject to the same voting process.

Result

All institutions are equal before the community.

9.18 Community First Principle

The economic size of an offer is not more important than the community's benefit.

Therefore

The community may reject even highly valuable offers.

Reasoning

The Platform's purpose is community interest, not maximum revenue.

9.19 Long-Term Alignment Principle

The purpose of the Partnership System is not to sell the community's attention, but to create value from the community's attention.

Difference

Traditional advertising model: buy a placement. Platform model: submit an offer — let the community decide.

9.20 Final Principle

No institution on the Platform can directly own the community's attention. Institutions may only submit offers. The community decides.

If value is created: supply decreases, the treasury grows, the protocol becomes stronger.

The Creator Wallet, meanwhile, takes no direct economic share from this process.

Chapter 10 — Security, Emergency Powers & Constitutional Protections

10.1 Purpose

This chapter was prepared to protect the security of the protocol, establish an intervention mechanism against critical attacks, and ensure the protection of constitutional principles.

The purpose of this chapter is to protect the system in extraordinary situations — not to manage the system.

10.2 Security Philosophy

The Platform's security model rests on the following principle: minimum authority in normal times, limited intervention in emergencies.

Principle

Security powers exist to limit harm, not to grant power.

10.3 Emergency Security Framework

The Platform contains special protection mechanisms for critical security events.

Examples

The following situations may be considered emergencies:

Critical Smart Contract Vulnerability

A critical contract vulnerability.

Active Exploit

An ongoing attack.

Treasury Compromise

Risk of the treasury being compromised.

Governance Exploit

Abuse of the governance system.

Reward Exploit

Exploitation of the reward system.

Infrastructure Breach

A critical infrastructure breach.

10.4 Emergency Pause Authority

An Emergency Pause can be initiated only by the Creator Wallet.

Purpose

Not to stop the system, but to prevent harm from escalating.

10.5 Emergency Pause Scope

During an Emergency Pause, the following transactions may be temporarily suspended:

New Proposal Creation

Creating new proposals.

New Partnership Submission

Creating new partnerships.

Reward Distribution

Reward distribution.

Treasury Execution

Treasury transactions.

Governance Execution

Governance execution.

10.6 Emergency Pause Restrictions

An Emergency Pause cannot suspend the following:

Creator Reserve Visibility

Visibility of the Creator Reserve.

Treasury Visibility

Visibility of the Treasury.

Historical Data Access

Historical records.

Blockchain Verification

On-chain verifications.

Principle

Transparency can never be switched off.

10.7 Emergency Pause Duration

An Emergency Pause is a temporary tool.

Requirement

A disclosure must be published within a reasonable time.

Principle

An Emergency Pause is not a permanent management tool.

10.8 Mandatory Public Disclosure

Whenever an Emergency Pause is used, a disclosure must be made to the community.

Disclosure Requirements

The disclosure must include the following information:

The nature of the issue

The systems affected

The risk level

The planned resolution

Purpose

To protect community confidence.

10.9 No Secret Emergency Powers

The Creator Wallet has no secret powers.

Restriction

The Creator Wallet: cannot change proposal outcomes, cannot change votes, cannot move treasury funds, and cannot rewrite reward distribution.

Result

Emergency powers can only halt. They cannot alter.

10.10 Emergency Neutrality Principle

Emergency powers cannot be used to obtain an economic advantage.

Forbidden Uses

Using an Emergency Pause: cannot be used to benefit the Creator, cannot be used to benefit the team, and cannot be used to protect particular investors.

10.11 Constitutional Protection Layer

Certain rules are under constitutional protection.

Protected Rules

Community Sovereignty

Community supremacy.

Voting Equality

1 Wallet = 1 Vote.

Creator Vote Restriction

The Creator cannot vote.

Treasury Independence

The Treasury is independent.

Proposal Finality

A proposal cannot be cancelled.

Blind Voting

Votes are invisible until concluded.

Creator Fee Prohibition

No Creator Fee may exist.

10.12 Constitutional Modification Standard

Rules under constitutional protection carry a higher level of protection than ordinary rules.

Principle

Core principles cannot be changed frequently.

Purpose

To protect investor confidence.

10.13 Security Over Growth

Security is more important than growth.

Priority Order

Security

Integrity

Sustainability

Growth

Reasoning

Growth becomes meaningless once trust is lost.

10.14 Economic Attack Resistance

The protocol must be designed to be resistant to economic manipulation.

Examples

Vote buying

Temporary token accumulation

Sybil attacks

Governance abuse

Objective

To continuously raise costs.

10.15 Transparency as Security

Transparency is a security mechanism.

Therefore

The following information must remain continuously visible:

Treasury

Creator Wallet

Vesting schedule

Proposal outcomes

Burn history

10.16 No Trusted Individuals Principle

The system cannot be built on trusting particular individuals.

Principle

Rules must rest on mechanisms, not on individuals.

Therefore

The Creator Wallet may change. The rules must not change.

10.17 Failure Containment Principle

A failure in one component must not be able to affect the entire system.

Examples

A treasury problem must not affect the voting system. A voting-system problem must not affect the vesting mechanism.

Purpose

To reduce systemic risk.

10.18 Security Disclosure Principle

Critical security events cannot be concealed.

Requirement

Security events that could affect the community must be disclosed.

Purpose

To reduce information asymmetry.

10.19 Protocol Before Individuals

The Platform's interests are superior to the interests of any individual.

Applies To

Creator

Team

Partners

Large Holders

Institutions

Principle

No one is bigger than the protocol.

10.20 Final Principle

The security system is designed not to give founders unlimited power, but to protect the protocol.

Emergency powers are limited, transparent, and temporary.

Community supremacy, by contrast, is permanent.

Chapter 11 — Reputation System

11.1 Purpose

The Reputation System was created to make community members' contributions within the Platform visible.

Reputation is not a measure of wealth. Reputation is not voting power. Reputation is not a governance privilege. Reputation is intended solely to measure standing within the community.

11.2 Reputation Philosophy

The Platform adopts the following principle: Wealth and Reputation are different.

A user holding a large number of tokens does not mean they have high reputation. Likewise, having high reputation does not confer additional economic rights.

Purpose

To preserve the separation between economic power and community standing.

11.3 Reputation Definition

Reputation is a recorded indicator of a user's past contributions and participation within the Platform.

Examples

Reputation may be affected by the following behaviors:

Creating proposals

Voting

Proposal Creator

A user who creates proposals.

Community Veteran

A long-term participant.

Note

Badges exist for prestige purposes only.

11.9 Reputation and Identity

Reputation is tied to a wallet.

Principle

Reputation is tied to a history of participation, not to a person.

Result

New wallets start with zero Reputation.

11.10 Reputation Persistence

Reputation accumulates over time.

Purpose

To make long-term participation visible.

Principle

Long-term contribution should be encouraged over short-term speculation.

11.11 Reputation Abuse Prevention

The Reputation system must be protected against manipulation.

Examples

The following behaviors may be considered abuse:

Artificial activity generation

Creating spam proposals

Bot participation

Fake interactions

Purpose

To keep Reputation meaningful.

11.12 Reputation and Governance

Reputation does not create a direct effect on Governance.

Restrictions

High Reputation: does not grant the right to open a Governance Proposal, does not change a governance outcome, and does not grant special governance authority.

11.13 Reputation and Treasury

Reputation does not create a special right over the Treasury.

Result

Users with high Reputation do not gain additional treasury authority.

11.14 Community Recognition Principle

The core purpose of Reputation is to secure recognition by the community.

Philosophy

Reputation is not a mechanism of power — it is a mechanism of recognition.

11.15 Future Evolution Clause

The community may in the future consider expanding the scope of the Reputation system.

Requirement

Such changes must go through the Governance process.

Restriction

No change may automatically create an economic advantage.

11.16 Constitutional Reputation Protection

The following principles must be preserved:

Reputation ≠ Voting Power

Reputation ≠ Reward Multiplier

Reputation ≠ Treasury Access

Reputation ≠ Governance Authority

These principles form the foundation of the Reputation system.

11.17 Final Principle

Reputation represents participation, not wealth. It represents standing, not power.

The way to earn respect within the Platform is not to hold more tokens, but to contribute more to the community.

Chapter 12 — Prohibited Content & Proposal Standards

12.1 Purpose

This chapter defines the content standards for proposals that may be created on the Platform, prohibited content, and content-eligibility rules.

The Platform is governed by the community. However, community governance does not mean unlimited content freedom. Certain content may never appear on the Platform, under any circumstances.

12.2 Content Philosophy

The Platform supports freedom of expression. However, freedom of expression cannot be used to legitimize criminal activity, exploitation, violence, or fraud.

Principle

The community may decide. However, not every subject may be put to a vote.

12.3 Proposal Eligibility Standard

For a proposal to be created, it must comply with applicable law, comply with platform rules, and not threaten community safety.

Requirement

The proposal owner is responsible for the content.

12.4 Illegal Content Prohibition

Content that supports or promotes illegal activity is prohibited.

Examples

Criminal organizations

Money laundering

Human trafficking

Fraudulent activity

Illegal financial activity

Community support for a piece of content does not automatically make it legitimate.

Therefore

A community vote cannot substitute for legality.

12.11 Proposal Format Standard

All proposals must be created in a standard format.

Required Elements

Title

The proposal title.

12.12 Clarity Requirement

A proposal must be clear and understandable.

Restriction

Vague wording may not be used.

Example

Incorrect: "What do you think about this?" Correct: "Should PLATFORM publish Project X's post?"

12.13 Single Decision Requirement

Every proposal must contain only a single decision.

Examples

For the correct/incorrect example, see Section 3.2, Proposal Definition.

Purpose

To ensure outcomes are unambiguous.

12.14 Transparency Requirement

A proposal owner may not conceal the following information:

The requested action

The impact of the outcome

Economic obligations

Purpose

To enable the community to make an informed decision.

12.15 Partnership Disclosure Requirement

Partnership Proposals are subject to an additional disclosure requirement.

Required Information

Institution name

Value offered

Requested behavior

Duration

Possible effects

Purpose

To ensure institutional transparency.

12.16 Treasury Proposal Disclosure Requirement

Treasury Proposals must include the following information:

Amount requested

Purpose of use

Expected benefit

Risks

Purpose

To make resource use visible.

12.17 Governance Proposal Disclosure Requirement

Governance Proposals must include the following information:

Rule to be changed

Rationale

Expected benefits

Possible risks

Purpose

To ensure governance transparency.

12.18 Community Protection Principle

The Platform's purpose is not to maximize the number of pieces of content, but to create high-quality and safe decision-making processes.

Therefore

Content quality is more important than content quantity.

12.19 Constitutional Content Standard

The following principles are the Platform's core content standards:

Legality

Legal compliance.

Transparency

Transparency.

Clarity

Clarity.

Safety

Safety.

Accountability

Accountability.

These principles apply to all proposal types.

12.20 Final Principle

The Platform supports the community's freedom to decide. However, this freedom cannot be used to legitimize illegality, fraud, exploitation, or violence.

The community is powerful. But constitutional limits apply to everyone.

Chapter 13 — Beta Phase & Roadmap

13.1 Beta Phase Definition

PLATFORM enters the Beta Phase the moment its token launches.

The Beta Phase is a constitutional transition period during which the protocol is tested under real users, real economic incentives, and real governance processes.

The protocol operates at full capacity throughout the Beta Phase.

13.2 Beta Phase Duration

The duration of the Beta Phase is fixed at 90 days.

This period begins from the block at which the token launch occurs.

13.3 Protocol Status During the Beta Phase

Throughout the Beta Phase:

Governance is active.

Treasury is active.

Partnership Proposals are active.

Voting is active.

The reputation system is active.

The proposal system is active.

The Beta Phase is not a limited-function version of PLATFORM — it is the fully functioning version.

13.4 Purpose of the Beta Phase

The purpose of the Beta Phase is defined as the identification of:

Security vulnerabilities

Economic exploits

Governance exploits

Treasury exploits

Sybil attack vectors

Partnership manipulation scenarios

Constitutional weaknesses

13.5 Genesis Security Reserve Relationship

Security contributions made during the Beta Phase may be rewarded under the Genesis Security Reserve.

Use of the Genesis Security Reserve is subject to the provisions of Chapter 7.

13.6 Security Contributions

The following contributions may be rewarded:

Critical security vulnerabilities

Critical economic exploits

Treasury exploit scenarios

Governance exploit scenarios

Sybil attack methods

Partnership manipulation methods

Constitutional loopholes

Protocol design flaws

13.7 Responsible Disclosure Principle

Critical vulnerabilities identified during the Beta Phase must be reported to PLATFORM before being disclosed publicly.

Purpose: the protection of users, the protection of the Treasury, the protection of the governance system, and the protection of protocol security.

13.8 Constitutional Updates During the Beta Phase

Constitutional deficiencies identified during the Beta Phase may be corrected using existing constitutional procedures.

The Beta Phase does not mean that constitutional protections are suspended. All constitutional provisions remain in effect.

13.9 End of the Beta Phase

Upon completion of the 90-day period:

The Beta Phase ends.

The Genesis Security Reserve ends.

Unused Genesis Security Reserve tokens are burned.

PLATFORM transitions to its permanent operational phase.

13.10 Beta Extension Prohibition

No Governance Proposal:

can extend the Beta Phase.

can restart the Beta Phase.

can create a new Genesis Security Reserve.

can expand the existing Genesis Security Reserve.

13.11 Genesis Security Reserve Protection

During or after the Beta Phase, tokens within the Genesis Security Reserve:

cannot be transferred to the Treasury.

cannot be transferred to the Creator Wallet.

cannot be directed toward partnership payments.

cannot be redefined as another reserve.

13.12 Mandatory Burn

The moment the Beta Phase ends, all undistributed tokens remaining in the Genesis Security Reserve are permanently burned.

This burn cannot be reversed.

13.13 Declaration of PLATFORM v1.0

Following successful completion of the Beta Phase, PLATFORM may be declared PLATFORM v1.0.

This declaration does not create a new governance authority and does not change the constitutional provisions.

13.14 Constitutional Protection

The following, as defined under this Chapter, are under constitutional protection:

The duration of the Beta Phase

The Genesis Security Reserve relationship

The mandatory burn rules

The security reward limits

No Governance Proposal can change, suspend, or nullify these provisions.