Hold value for a common purpose
Members could pool currency, materials, buildings' operating inputs, and eligible NFTs under transparent custody instead of placing them in one player's personal wallet.
Cooperative systems direction · No DAO is deployed
Build together.
Shared organization layer
Build together.
Own and decide together.
A successful guild or town needs more than chat and ranks. NFTerra's planned DAO layer would let players hold eligible assets together, define member rights, make proposals, vote, commission work through contracts, protect deals with escrow, and verify what was executed.
Shared ownershipContracts & escrowMember voting
What DAO means in NFTerra
A cooperative operating system for persistent player organizations.
Guilds, trade groups, and towns could combine resources without surrendering everything to one leader or trusting an informal promise.
The organization records who may propose, vote, approve, spend, withdraw, receive proceeds, or act for the group. Its contracts and ledgers make those decisions inspectable and auditable.
The DAO governs the organization—not the game engine.
It can authorize eligible shared-asset, contract, market, and settlement operations. The authoritative server still decides loot, skills, combat, territory capture, construction validity, and every other game rule.
What a functioning town needs
Share value, hire specialists, and make binding decisions.
These capabilities form one organization system. A guild may adopt only the modules it needs, but each enabled module must define its assets, members, rights, limits, execution path, and exit rules.
Commission work with clear terms
A town could hire builders, smiths, guards, suppliers, couriers, or other specialists with defined inputs, milestones, payment, expiry, and failure conditions.
Protect both sides of an agreement
Currency, materials, or eligible items could remain locked until the server verifies a result, the parties approve a milestone, or a published dispute process resolves the contract.
Decide under visible rules
Members could propose budgets and policies, delegate voting power, meet a quorum, use role- or share-defined rights, and inspect the exact action before it executes.
Record who owns what together
An eligible asset may be held collectively or through explicit member shares that define voting, withdrawal, proceeds, transfer, exit, and dissolution rights.
Turn collective decisions into work
A settlement could coordinate upkeep, construction priorities, service operators, storage, defence budgets, and fee policy inside limits enforced by the game server.
Guild and town operating model
Rights enter at the top. Verified outcomes leave at the bottom.
A DAO is useful when it connects membership, shared custody, collective decisions, enforceable agreements, and a complete record of the result.
Planned organization modules
Practical tools for groups that become economically important.
The product direction is confirmed; implementation is expected to progress through reviewed modules rather than one contract with unlimited authority.
Budgets and distributions
Pool eligible value, fund recurring costs, approve payments, collect supported income, and distribute proceeds according to explicit rights.
Collective or share-defined ownership
Record eligible pooled NFTs and ledger items, custody, usage permissions, economic rights, withdrawal rules, and what happens when the group dissolves.
Services, supplies, and milestones
Publish work, appoint a provider, lock inputs and payment, verify delivery, handle failure, and preserve one auditable agreement history.
Roles, shares, and permissions
Make governance, economic, custody, and operational rights explicit instead of assuming that every member or deposit has the same claim.
Buy or commission together
Approve an exact asset, construction, service, price ceiling, executor, custody destination, ownership model, and failure behaviour.
Operate a living town
Choose budgets, upkeep, approved fees, service operators, defence priorities, storage policy, and reinvestment inside server-enforced game limits.
Ownership must be deliberate
Personal, shared, and world state are different things.
Joining a guild does not hand over a character's inventory. Depositing an asset does not silently create equal transferable shares. Every ownership transition and right must be explicit.
The player's property
Currency, sealed loot, and NFTs remain in the character inventory-wallet until the owner deliberately lists, escrows, lends under an approved module, or contributes them.
- No automatic guild claim
- Clear consent and return conditions
- Character and wallet recovery still apply
Collective or share-defined property
An eligible asset can belong to the organization collectively or carry explicit member shares and rights defined by its charter and custody module.
- Ownership and usage rights recorded
- Proceeds and distributions follow the charter
- Exit, transfer, dispute, and dissolution defined
Operated, not tokenized
Territory, totems, and building placement remain authoritative game state. The DAO may govern the organization operating them, but land control is not an NFT.
- Conquest stays server-validated
- Town budgets may be collectively governed
- No vote overrides world rules
One possible town cycle
A forge becomes a collective project, not a leader's promise.
A prosperous town may need dozens of contributions and several specialist services. DAO modules give that work a common budget, enforceable responsibilities, and a recorded outcome.
- 01
Fund
Members contribute currency and materials under stated ownership and return conditions.
- 02
Decide
Eligible members approve the forge, budget, site priority, operator, fee policy, and rights.
- 03
Contract
A builder accepts milestones while payment and required materials enter escrow.
- 04
Validate
The game server confirms that skills, location, inputs, construction rules, and territory state are valid.
- 05
Operate
Supported fees return to the town treasury; members later vote to reinvest or distribute them according to explicit rights.
The governed-action lifecycle
Proposal to reconciliation in six controlled stages.
The human-readable decision and executable payload remain bound together. Retries must be idempotent; rejected, expired, paused, or failed actions transfer nothing.
- 01
Propose
State the action, budget, rights, destination, conflicts, expiry, and exact executable payload.
- 02
Verify
Check membership, authority, ownership, custody, balances, policy, law, and module limits.
- 03
Vote
Apply the published rule version for voting power, delegation, quorum, threshold, and minority protections.
- 04
Commit
Lock required assets or payment in escrow and pass any timelock or multi-approval period.
- 05
Execute
Run only the approved purchase, contract, distribution, or server-validated town operation.
- 06
Reconcile
Match the decision, rights, asset custody, payment, game result, and public or private ledger records.
The authority boundary
Powerful cooperation without a back door into game rules.
A DAO can make a binding decision only inside a module that has authority to perform it.
Potentially organization-governed
- Shared treasuries and eligible pooled assets
- Charter-defined member roles, shares, and rights
- Service, supply, employment-like, and construction contracts
- Escrow, milestones, disputes, and approved distributions
- Cooperative purchases, sales, and marketplace activity
- Town budgets, upkeep, operators, storage, defence, and fees within game limits
Never DAO-controlled
- Loot creation, drop eligibility, or mint randomness
- Skill, XP, combat, quests, or anti-cheat decisions
- Invalid conquest, construction, or territory changes
- Quest-item binding or item-class authority
- Precise player location or private account state
- NFTerra's project treasury, token issuance, security, fraud, safety, or legal controls
Shared power needs safeguards
The charter must answer the hard questions before assets move.
Shared ownership is a real product direction. It still requires explicit rules for custody, capture resistance, proceeds, minority rights, failure, and exit.
Who owns what?
Collective title, member shares, use rights, proceeds, distributions, withdrawal, transfer, inheritance, and dissolution must be recorded.
Who can take control?
Vote buying, borrowed stake, sybil membership, delegation concentration, inactive majorities, and minority protections need module-specific controls.
Who can move the assets?
Contracts, multisignature approvals, protected keys, limits, recovery, escrow, and emergency pauses must match the value at risk.
Did the vote authorize this?
Approved text must match the executable payload, destination, amount, rights, expiry, and exact operation that runs.
Who benefits from the deal?
Related-party contracts, self-dealing, price manipulation, collusion, and undisclosed interests require visible policy and records.
Rights have real consequences
Custody, economic rights, distributions, marketing, tax, employment, and jurisdiction must be reviewed before a monetized module launches.
A necessary promise
Shared ownership requires explicit rights, not vague claims.
Every shared asset or project must state the owner, custodian, member shares if any, voting and usage rights, proceeds and distributions, transferability, withdrawal, disputes, exit, inheritance, and dissolution. Membership alone does not silently create equal, transferable, or yield-bearing ownership.
Still to be decided.
- Which organization module ships first
- Membership credentials, share classes, and transferability
- Voting power, snapshots, quorum, delegation, and minority protections
- Proposal cost, spam controls, timelocks, and emergency authority
- Custody, multisignature, deposits, withdrawals, and recovery
- Contract milestones, server proofs, disputes, cancellation, and appeals
- Proceeds, distributions, exit, inheritance, and dissolution
- Launch jurisdictions, tax treatment, and legal structure
Put cooperation into the world
Organizations provide the people. Settlements create the work.
See how persistent guilds and clans form, then how conquest, buildings, resources, upkeep, fees, and town operation give cooperative systems something meaningful to coordinate.