Cenaca Blockchain White Paper

22 October 2026 · Original documents in Simplified Chinese and English

This paper describes the current design rules of Cenaca and the boundaries through which the NA wallet and external applications use them. Development and validation are ongoing. It does not claim a production mainnet, live real-asset wallet, bridge or bank, and makes no issuance, return, price or security guarantee.

1 Product boundaries

The New World game (NW), official website, SD account service, Cenaca blockchain and its native coin Cenaca (CNC), and New Assets wallet (NA) are five independent modules connected by interfaces, with separate code, deployment and operational responsibilities. The website presents information; SD supplies general login identity; NW runs the game; Cenaca maintains the ledger and on-chain governance; NA provides wallet operations.

Cenaca consensus, nodes, RPC, ordinary-address transfers and on-chain governance must operate without NW, the website or SD being online. A game outage must not stop Cenaca blocks or transfers from compatible wallets. NW is an external client of public Cenaca interfaces. Characters, inventories, buildings, movement and combat remain off-chain NW state. Continued chain operation alone does not establish offline redemption of game items or Spirit Stones.

2 Native chain and engineering targets

The first generation of Cenaca follows an independent native Layer 1 design using Cosmos SDK and CometBFT, prioritizing native CNC, gas, public RPC, independent nodes and wallet access. CNC uses nine decimal places. EVM compatibility is a later direction and is not a first-generation acceptance requirement.

Initial engineering targets are seven permissioned validators operated by distinct entities and an approximately two-second block interval. Operator independence, software compatibility, actual finality, capacity and operating cost require testing. These figures are not claims of deployed scale or guaranteed performance.

3 CNC supply and network fees

The globally effective CNC supply is fixed at 21,000,000 units with nine decimal places; the smallest unit is 0.000000001 CNC. Procurement, trade and service payments use existing CNC. Validator compensation and game rewards do not create additional supply. Newly registered players receive no free CNC. Genesis allocation and the initial release into the game economy belong to the later government setup.

Cenaca transactions pay CNC gas for computation, signatures and block resources, rather than a percentage transfer tax. Current indicative parameters are approximately 0.005 CNC for an ordinary transfer under normal load and a floor of approximately 0.002 CNC. Target block-resource utilization is 50%, with base-fee adjustment capped at 12.5% per block and optional priority fees. These parameters require validation; actual fees depend on resource use and load.

The fee design allocates 90% to a shared validator reward pool and 10% to an eligible block proposer, without routine CNC burning. Whether fees cover validator costs requires operational evidence. Every organization proposal type must successfully debit initiation gas before creation; unsuccessful payment must not produce an effective proposal. The debited initiation fee is not refunded because a proposal passes, is rejected, expires or fails during execution.

4 Ordinary addresses and keys

Both ordinary and organization Cenaca addresses use the lowercase sd Bech32 human-readable prefix and appear as sd1…. An address is distinct from an SDID, NWID or username. An ordinary address is controlled by its private key and is usable when created, with no activation, activation fee or self-issued credential. Its payments require authorization by its private-key signature.

Each ordinary address created in NA receives its own newly generated mnemonic and private key; a shared seed must not be exported for multiple people to use. Users retain long-term keys and mnemonics locally, without uploading them to NW servers. SD registration does not create a wallet. SD login, username lookup and NWID binding cannot replace an address signature or recover a lost private key.

NA must support wallet operations through independent Cenaca interfaces while NW is unavailable. SD login or game binding grants neither private-key control of an ordinary address nor a bypass of organization governance.

5 Organization addresses and credential classes

Each organization has one official Cenaca organization address, which is its unique identifier. It has no private key or mnemonic. Its asset and governance actions execute through proposals. The creator retains no permanent control or governance bypass.

At creation, the wallet specifies initial equity and director voting rights, their quantities and recipient addresses, and affirmative thresholds and durations. Both on-chain credential classes are allocated to the designated addresses. Their minimum unit is one credential and balances can accumulate. Only ordinary addresses may hold director credentials; ordinary or organization addresses may hold equity credentials.

At organization creation, the option "Prohibit early end of notice" may be selected and is unchecked by default. Both modes allow shareholders to cast affirmative signatures and have their votes recorded. If unchecked, reaching T affirmative votes permits early passage. If selected, even reaching T requires waiting for full notice expiry before the proposal can take effect. During the applicable active voting stage, reaching R opposing votes immediately rejects it in either mode. The configured notice period remains at least 24 hours. On-chain proposal rules enforce when approval takes effect; backends merely choosing not to sign are insufficient.

Director voting weight and equity are calculated against their own respective valid totals, never a combined denominator. A balance determines its current share, not a permanent percentage. For example, 700 of 10,000 equity credentials represents 7%; increasing the total through governance dilutes that percentage.

6 Proposal approval and shareholder notice

Organization payments and governance actions follow board proposal approval and then shareholder notice. The board approval window and shareholder notice period use the same duration D; each D is at least 24 hours, with exactly 24 hours allowed. The configured director affirmative threshold must be met before notice begins. Mere expiry cannot approve a proposal that has not obtained board approval.

Director and equity credentials have separately calculated thresholds, using each class's own total rather than combining classes or counting only participating votes. Let N be the valid integer credential total for a class and T its configured integer affirmative threshold. It must satisfy N / 2 < T <= N: strictly more than 50% and no more than 100%. The opposing threshold is derived as R = N - T + 1. During the applicable active voting stage, reaching T affirmative votes satisfies that class's approval; reaching R opposing votes immediately rejects the proposal. R need not exceed half the total. With N = 10,000 and T = 6,000, 6,000 affirmative votes suffice and 4,001 opposing votes reject it. With N = 3 and T = 3, all three affirmative votes are required and one opposing vote rejects it.

Proposal creation separately fixes N, T and derived R for director and shareholder classes, approval and notice durations, the prohibition or permission of early notice completion, and applicable rules. Later credential transfers or issuance cannot retroactively change that proposal's N, T, R or counted votes. Newly issued units gain no eligibility for old proposals.

A proposal has one public status for everyone: In approval, In notice, Approved, Rejected or Failed. If an existing proposal fails during execution because of insufficient balance, insufficient execution gas or another error, its public status is Failed, while its prior approval history, execution result and failure reason remain recorded. Unsuccessful payment of initiation gas still creates no proposal. Approved means governance approval, not successful execution or receipt of funds. A later execution failure must be shown as Failed, rather than hidden in a subfield of Approved.

The wallet separately shows Pending review or Reviewed for the current ordinary address and its director or shareholder role. A recorded affirmative or opposing submission for that address and role that passes eligibility checks, including a late opinion, is Reviewed, with its direction visible. Whether it affects the outcome is marked separately; no record is Pending review. Pending review grants no authority by itself. Submission still requires eligibility, signature authorization and duplicate-use checks. Each of the five public statuses can have either action status, producing ten combinations: In approval+Pending review, In approval+Reviewed, In notice+Pending review, In notice+Reviewed, Approved+Pending review, Approved+Reviewed, Rejected+Pending review, Rejected+Reviewed, Failed+Pending review and Failed+Reviewed.

Directors may submit later affirmative or opposing opinions after a proposal enters notice, and shareholders after notice ends. Both roles may also submit opinions after the proposal becomes Approved, Rejected or Failed. Decisive tallies include only votes in the applicable active voting stage. Late opinions are recorded separately: they do not reverse a stage, alter decided tallies, governance results or failure status, trigger execution, retry a failed or rejected proposal, or pay again. Late submissions retain the proposal's original credential-holding eligibility, signature authorization and per-unit duplicate-use rules. Used voting weight cannot express another opinion, and credential transfers cannot manufacture new eligibility.

Organizations leaving "Prohibit early end of notice" unchecked allow early passage when shareholder affirmative votes reach T. Organizations selecting it still allow affirmative signatures to be cast and counted, but even reaching T requires waiting for full notice expiry before the proposal takes effect. In either mode, while notice remains active, opposing shareholder votes reaching R immediately reject it; a board-approved proposal passes after full notice expires without R being reached. Non-voting is neither an affirmative nor an opposing vote. Both credential classes remain transferable after voting. Counted affirmative or opposing votes remain with the original proposal and are neither withdrawn nor copied by transfer. Voting itself does not restrict credential transfers.

Affirmative, signing and veto eligibility for both director and equity credentials is checked against traceable holding records for each batch or unit. At voting time, only eligible units received by the current address before proposal creation, never transferred out since, still held and not yet used on that proposal may vote. Later receipts or newly issued units cannot replace earlier voting weight. Units transferred out and returned to the same address are new receipts and do not regain eligibility for the old proposal.

For units not yet voted, three units held before a proposal and never transferred out remain at most three eligible units after two new units arrive. If all three original units leave and return, none is eligible for the old proposal. If only one leaves, the two original units that remain retain eligibility. The rule selecting transferred batches or units must be explicit and traceable. New receipts cannot replace the old eligibility of units that left, and new issuance cannot be backdated as a pre-proposal holding.

Each proposal separately records voting weight already used from each batch or unit. The same address cannot reuse a unit, transfer it out and back to vote again, or use splitting and merging to clear its used-vote record or fabricate earlier eligibility. A credential may be transferred after voting, but its recipient cannot duplicate that vote on the old proposal. Eligibility and used weight are checked separately for each proposal; their voting records cannot substitute for one another.

The order of proposal creation and credential receipt is determined by deterministic block height and transaction and event order within the block, rather than wall-clock time alone. Within one block, valid receipt before a proposal can establish eligibility, while receipt after it cannot be used for that proposal.

Recipients, amounts and governance actions must match the approved proposal. On-chain execution must validate authority and state. Failed execution must set the public status to Failed, preserve the reason and leave no partially completed transfer. Changes to thresholds, durations or credential rules require approval under the rules already in force, not the proposed replacement rules.

7 Credential issuance and layered ownership

A holder may directly transfer director credentials to another ordinary address without an organization proposal or notice period, including after voting. The chain must check recipient address type, valid holdings and transfer authorization. Equity may be transferred to ordinary or organization addresses under its rules. After either class is transferred, eligibility and used voting weight for existing proposals must still be checked by batch or unit.

Once issued, director and equity credentials are permanently non-destructible and cannot be forcibly deducted through governance. An organization may issue additional credentials through governance to dilute relative voting or equity shares. Replacing the entire holder table, deleting a holder or rewriting balances cannot be used to destroy credentials indirectly. Governance cannot forcibly reduce existing quantities, but further issuance may continually dilute relative percentages, without a fixed-percentage, value or return guarantee.

An issuance proposal lists only the recipient addresses and quantities to add, rather than replacing a table of existing holder balances. Execution reads actual balances at that time, adds the specified quantities and records new issuance batches as one atomic operation. Legitimate transfers during proposal editing must not be overwritten by stale balances, cause negative quantities or revive balances already transferred away.

Issuance and governance-setting changes require approval under the eligibility and thresholds already in force. Execution must validate each resulting integer total N and proposed affirmative threshold T, satisfying N / 2 < T <= N, and derive R = N - T + 1 from the new N and T. Conflicting governance-setting revisions must fail explicitly, without overwriting newer settings or leaving partial issuance. Newly issued batches cannot vote on earlier proposals.

Credential supply and CNC monetary supply are managed separately. The non-destruction rule applies to director and equity credentials. CNC cross-chain movement continues to follow its separate source-burn, equal-destination-issuance and global supply-conservation rules.

When an organization owns equity in another organization, its own immediate board determines how to exercise those external shareholder rights, without recursively polling its own shareholders. Indirect ownership does not automatically give an individual direct voting rights in a subsidiary. Circular and layered ownership must not duplicate or amplify the same voting weight.

An organization voting on a subsidiary's proposal must verify that the underlying equity units arrived before that proposal, have not left since, remain held at voting time and have not already voted on it. Board approval cannot make subsequently received equity eligible for an earlier proposal, and transfers cannot copy historical votes attached to underlying equity.

8 Wallet and game identity interfaces

The NA asset page provides four primary actions: Transfer, Receive, Approvals and Organizations. Bottom navigation contains Assets, Exchange and Me. Organization pages display director and shareholder addresses and balances read-only, with organization creation, issuance proposals and governance-setting proposals. They do not directly edit holder balances or delete holders. An ordinary payment selects and signs with an ordinary address; an organization payment creates a proposal rather than pretending to use an organization private key.

Proposal pages display the public proposal status alongside the current address's action status for its role, evaluating director and shareholder records separately. Execution results and failure reasons are also shown; failed execution requires the public status Failed while preserving prior approval history. Decisive votes and late opinions are distinguished. Reviewed or Approved must not be presented as proof of funds received, and Pending review must not enable an ineligible signature.

For ordinary players, one SDID corresponds to one immutable NWID, formed by NW followed by eight random letters or digits. Usernames are unique and changeable. Only ordinary addresses can bind to an NWID. A player may bind several addresses, each to only one player. The game initiates binding; within 24 hours the wallet must verify the matching NWID and sign confirmation. Expired or replayed confirmations must be rejected.

Players can set a default receiving address for username-based recipient lookup and marketplace proceeds, and choose a bound ordinary address for each payment. Organizations have no game account or NWID binding. The game discovers organizations from credentials held directly by the player's ordinary addresses. Rosters show addresses and quantities without revealing associated players, even for bound addresses. Organization notes are private to the player who writes them. Organization operating permissions are outside the current scope.

9 Cross-chain movement and supply conservation

Native Cenaca CNC and corresponding CNC on officially supported external chains connect through actual source-chain burning and equal destination-chain issuance after verification. The right to move funds belongs to their current legitimate controller authorizing the burn, not permanently to the first bridge user. Each operation requires a unique identifier, valid burn evidence, sufficient finality, destination replay protection and a recovery path.

The cross-chain design must preserve S_Cenaca + ΣS_external + P_pending = 21,000,000 CNC. P_pending represents valid amounts already burned but awaiting destination issuance; it is neither spendable again nor redeemable twice. Return from external chains to Cenaca uses an independent DApp. Each chain charges its applicable network fees.

The integration direction is to validate Cenaca and Ethereum first, then consider Solana. A preliminary risk-control reference is a network-wide maximum of 100,000 CNC per rolling 24 hours, requiring validation before deployment. Sepolia may be used for test exploration; it is not an issuance or deployment commitment. This paper confirms no deployed or audited bridge.

10 Later public institution plans

Government and bank are planned as separate on-chain organizations, initially using six ordinary addresses each: three director addresses and three different shareholder addresses, for 12 ordinary addresses in total. Each organization initially issues three director and three equity credentials, allocating one of the corresponding class to each address. Both classes use N = 3 and T = 3, deriving R = 1. The user will establish these addresses and 12 servers later and securely configure the corresponding private keys. Each server runs one independent Judge Program controlling only its own ordinary address; six serve government and the other six serve bank. The company's operations team governs government without shared player governance, and government and bank funds remain separate. The organizations themselves have no private key, and Judge Programs cannot bypass on-chain governance. These addresses, servers and programs are not deployed; authorization and team assignments still require implementation.

The Judge recovery design includes health monitoring that checks whether a process is online and attempts to restart it when offline or terminated. Monitoring and restart restore program operation; they do not substitute for security review or automatically approve or sign. An online process does not mean a review is complete. Whole-machine failure, power loss or network interruption may prevent recovery. This mechanism still requires implementation and validation, without an availability or security guarantee.

The government design reserves nine proposed identity pairs: SD11111/NW11111, SD22222/NW22222, SD33333/NW33333, SD44444/NW44444, SD55555/NW55555, SD66666/NW66666, SD77777/NW77777, SD88888/NW88888 and SD99999/NW99999. This is a reserved design exception to the ordinary player format of NW plus eight random letters or digits. It does not claim that these accounts exist, permit unauthenticated login or already have operational authority. Ordinary player NWID rules remain unchanged.

Government selects "Prohibit early end of notice" at creation. An in-game government payment still first requires approval from five of the nine special game accounts. Its request is then assigned at random to the Judge Program for an ordinary address holding director credentials in the government organization. That program performs a local security review before submitting an on-chain proposal. The other director Judges independently review and vote according to their own findings, without a mandatory sequential order. Initially, three valid director-credential affirmative votes move the proposal into full notice; one opposing director vote reaches R = 1 and rejects it. Shareholder Judges independently review and may cast affirmative signatures that are recorded as votes. Even if affirmative votes reach T = 3, the proposal must wait for full notice expiry and cannot execute early. They oppose it when an anomaly is found. One opposing equity-credential vote reaches R = 1 and immediately rejects the proposal. Notice lasts at least 24 hours and cannot end early through affirmative votes. Only after full expiry without the opposing threshold being reached does execution continue under on-chain rules. Special game-account approval is an application-layer gate before government Judge submission, not extra on-chain privilege or a change to Cenaca's independent operation.

Government also plans an independent inspection program that reads the on-chain state of government-organization proposals. For inspection, directors are in an active voting stage only during In approval, and shareholders only during In notice. For an identity with valid eligibility in that stage and no confirmed affirmative or opposing vote, the timer starts at proposal creation for directors and at entry into notice for shareholders. More than one hour without a vote triggers an alert and investigation. Late opinions and expressions after a terminal outcome are not pursued. Missing votes signal an anomaly, not proof that a process has stopped. RPC, unconfirmed transactions, gas and process status are checked before bounded recovery attempts with backoff. Terminated proposals, inapplicable stages and identities without valid eligibility are excluded from timeout checks. Inspection does not sign on anyone's behalf, change on-chain governance or execution conditions, or guarantee timely recovery. This is a government operating plan and is not deployed in production. The user will configure a company-wide email recipient list; on an anomaly, the inspection program is planned to send urgent alerts to every listed recipient, including the proposal, organization, Judge, time and recovery status, without private keys or other secrets. Repeated alerts for the same fault are consolidated and recovery notices are sent; actual email addresses and the sending service are not configured or deployed.

The fiscal design allocates all 21,000,000 CNC to government in the genesis startup phase, followed by circulation through genuine procurement and other economic activity. The mature treasury's available reserve target is approximately 7,000,000 to 14,000,000 CNC. This is a fiscal management target, not a return or safety guarantee or a hard on-chain constraint, and does not change the fixed global supply. The design does not claim that genesis allocation has occurred.

The company bears necessary real-world operating expenses, including server costs and staff wages, and plans to obtain operating funds by selling CNC already held by the government organization. These sales use existing CNC, not new issuance. Sold CNC enters the market for players to trade freely, while government recovers CNC through auctions of weapon-production blueprints. On-chain transfers of government funds remain subject to organization governance. Real-world income and expenses, the CNC price and conversion liquidity are not guaranteed. Recovering CNC is not the same as earning real-world cash revenue, and bank deposit reserves must not fund company operations. This is a fiscal and operating design, not a claim that sales have occurred.

Bank leaves "Prohibit early end of notice" unchecked at creation. A valid player withdrawal request is assigned at random to the Judge Program for an ordinary address holding director credentials in the bank organization, without manual agreement from five special administrator accounts. That program performs a local security review before submitting an on-chain proposal. Director Judges independently review, approving when safe and opposing when an anomaly is found, without a mandatory sequential order. Initially, three valid director-credential affirmative votes begin notice; one opposing director vote reaches R = 1 and rejects it. Shareholder Judges independently review and approve when safe or oppose anomalies. Three equity-credential affirmative votes may pass the proposal early, while one opposing vote reaches R = 1 and immediately rejects it. The configured notice period remains at least 24 hours. Players sign deposit payments, actual receipts are credited by NWID, and withdrawals may go to another ordinary address bound to the same player. Early passage and automatic submission do not guarantee immediate receipt, which still depends on chain confirmation, Judge availability, approval and successful execution. Authorization deployment and custody controls require implementation and validation, without absolute-safety or non-custodial promises.

Every proposal type, including transfers, governance settings, issuance and rights proposals, must successfully debit gas before creation; unsuccessful payment must not produce an effective proposal. Debited initiation gas is not refunded because a proposal passes, is rejected, expires or fails during execution. Organization proposal initiation requires more gas than an ordinary transfer. Exact rates, multipliers and resource metering remain subject to calibration, without fixed figures here. On-chain operations such as proposals and votes incur network-resource fees. Off-chain security review and health monitoring on servers do not themselves consume on-chain gas, and server operating costs are accounted for separately. Retries of the same accepted request must be idempotent, preventing duplicate initiation-gas debits, duplicate effective proposals or duplicate payments.

The bank would record deposit liabilities only against actual CNC receipts, maintaining fully redeemable reserves without lending, credit creation or diversion of customer principal. Government, bank and game Spirit Stone reserves remain separate and cannot be mixed. These institutions are later plans, not currently available asset services.

11 Implementation and risk boundaries

Local development has exercised account separation, wallet interfaces and isolated on-chain signature flows. Complete credential governance, real wallet signing and cross-module integration remain in development. Interface examples, fixtures and isolated tests are not evidence of production readiness. Cenaca independence requires drills showing continued blocks, transfers and governance credential use with NW and its database stopped.

Cross-chain authorization, voting eligibility and used-weight accounting, atomic organization execution, key backup and recovery, bank custody, and Spirit Stone redemption during game outages require specific validation. Lost keys, malicious proposals, continued issuance dilution, cross-chain message errors and off-chain outages can cause losses. Applicable issuance, trading, custody and gaming requirements must be assessed before operation. This paper guarantees no appreciation, liquidity or delivery date.