# PLAIS Chain Whitepaper Version 0.4 — 2026-08-04 Status: canonical-mainnet technical and policy document. The QBFT network is technically operational, while public circulation and external transfers remain locked. This document is not an investment prospectus, token sale, exchange-listing announcement, or promise of future value. ## Executive Summary PLAIS Chain is the canonical settlement and audit network for the PLAI service ecosystem. It gives AISFOR, AISTALK, AISGROUP, AISMALL, and future approved services a common way to authenticate events, preserve proofs, trace rewards, and settle separately approved on-chain transactions. The current architecture has two deliberately separated planes: - a Besu QBFT mainnet, which is the only canonical asset ledger; and - a legacy application ledger, which retains proof, point, wallet, reward, and callback history as a read-only compatibility archive. The canonical network is technically operational with chain ID `20260718`, four validators on four independently attested hosts, and continuous QBFT block production. The technical mainnet gate passed 11/11 on 2026-08-04. Public circulation remains zero, external transfers and operator signing remain locked, and point-to-coin conversion is disabled. Public activation, exchange integration, legal review, and independent security review remain separate approval gates. ## Problem And Purpose The PLAI ecosystem produces events across messaging, groups, commerce, storage, identity, and node operation. A conventional service database can process these events efficiently, but cross-service auditability becomes difficult when each service maintains its own identifiers, retry behavior, and history. PLAI Chain is intended to provide: - authenticated and idempotent service event submission; - a consistent audit trail linking source events, rewards, reviews, and callbacks; - a canonical EVM-compatible ledger for approved transactions; - a clear boundary between application points and the canonical native asset; - observable node and validator readiness; and - fail-closed controls that prevent a technically live network from being publicly activated without explicit approval. The design does not attempt to put every service payload on-chain. Services keep operational and personal data in their appropriate databases. The chain layer records only the minimum identifiers, hashes, amounts, statuses, and references required for verification and settlement. ## Names And Asset Boundaries The project uses the following terms: - PLAI: the service ecosystem and product brand. - PLAIS Chain: the public display name of the canonical network. - AISFOR-CHAIN: the development and repository name retained in technical history. - PLAIS Coin: the canonical network's native asset. - PLAIS: the canonical native-asset symbol. - plais Point: the legacy application reward unit. The canonical native asset and the legacy point ledger are not interchangeable. Canonical native asset: - name: PLAIS Coin; - symbol: PLAIS; - decimals: 18; - genesis supply: 10,000,000,000 PLAIS; - address format: standard EVM `0x` address; - public circulating supply: 0; - external transfers: locked; - public issuance: not approved. Legacy application unit: - display unit: plais Point; - stored symbol: `plais` for data compatibility; - storage decimals: 6; - settlement: simulation only; - conversion to canonical PLAIS: disabled. Earlier Tokenomics v0.1 materials used PLAI/PLAI Coin as a provisional name and described a six-decimal simulation ledger. For the canonical mainnet implementation, the authoritative technical identity is PLAIS Coin, symbol PLAIS, with 18 decimals. This naming clarification does not authorize circulation and does not convert any existing balance. ## System Architecture ### Service And Identity Layer AISFOR remains the canonical identity source. An AISFOR user `_id` is used as the stable ecosystem account reference for application wallet mapping. Approved service identities currently include AISFOR, AISTALK, AISGROUP, AISMALL, and AISFOR_CHAIN. Services submit proofs and reward events through the Express control plane. When security enforcement is active, `/api/**` requests require HMAC v2 authentication. A signature binds the service name, timestamp, nonce, HTTP method, request path, and normalized request body. Timestamp skew checks and nonce replay protection reduce forged and duplicate submissions. API-key-only and legacy signatures are not sufficient in the hardened mode. ### Canonical Ledger The canonical mainnet ledger is Hyperledger Besu using QBFT consensus. - chain ID: `20260718`; - consensus: QBFT; - target block period: 2 seconds; - validator identities: 4; - RPC role: a separate non-validator node; - canonical API namespace: `/api/canonical/**`; - canonical Explorer route: `/explorer/block/:height-or-hash`. Canonical status is read from Besu RPC. Readiness checks use chain ID, validator set, block freshness, peer identity, peer connectivity, external-transfer locks, and genesis identity. Legacy mock block height or mock votes are never treated as canonical finality. QBFT provides deterministic finality under its quorum assumptions. It does not remove operational risk. Liveness and safety still depend on validator key security, network connectivity, correct client configuration, and an independently operated validator topology. ### Legacy Application Archive The earlier Express block ledger is retained as a `legacy-read-only-archive`. It preserves application proofs, simulated point rewards, mock wallets, callbacks, and historical block references. Legacy mining, validator assignment, voting, and finalization writes are locked. The archive can support audits and compatibility views, but it is not a validator, consensus, or finality source. Archived point and wallet balances are not EVM balances and cannot be moved into the canonical ledger without a future, separately approved migration policy. ### Data Persistence Application-ledger read migration from JSON to MongoDB was completed through staged backfill, source-hash comparison, monitored promotion, and rollback controls. MongoDB serves application audit data; it does not replace Besu as the canonical ledger. The JSON dataset is retained as a rollback and historical verification source. This distinction matters: database replication can improve service reliability, but only the QBFT ledger determines canonical block and transaction history. ## Proof And Audit Flow An accepted service proof is idempotent by `sourceService + idempotencyKey`. Depending on the event type and active policy, the record can be linked to: - the originating service and source event; - a proof-ledger row and request hash; - a simulated reward and operator review; - a legacy archive reference; - an approved canonical transaction; - a callback delivery and acknowledgement; and - Explorer views for the relevant address, transaction, or block. Source systems must not include message bodies, recovery phrases, private keys, unrestricted personal information, or other unnecessary content in proof payloads. Hashes provide integrity evidence only when the source data, canonicalization rules, timestamp, and retention policy are also controlled. ## Wallet And Key Model The legacy application wallet supports receive QR, PIN-protected actions, recovery setup, and application-ledger traceability. These balances remain points or simulation records. The canonical EVM wallet uses standard secp256k1 keys and `0x` addresses. User key material is encrypted with AES-256-GCM using a key derived with scrypt from a user PIN and a separate server-side vault secret. Ownership can be verified through message signatures. This design still requires independent security review, recovery testing, brute-force resistance assessment, secret rotation procedures, and user-facing phishing protection before public-value use. The canonical operator address is preserved, but its private key is removed from the web process. The interim offline vault uses Windows DPAPI `CurrentUser`, and web signing fails closed. This is an operational containment step, not the final public-mainnet custody design. Public-value operation requires an approved hardware wallet, HSM/KMS, or remote signer with multi-person approval, transaction simulation, policy limits, immutable audit logs, and a tested disaster-recovery ceremony. ## PoSS Reward Model PoSS means Proof of Service & Storage. It is a candidate method for recognizing measurable contributions to the ecosystem, including service use, content, storage capacity, verified data custody, uptime, commerce, emoticon creation, moderation, and other approved activity. The simulation score is composed as follows: ```text rewardScore = serviceScore + contentScore + storageScore + uptimeScore + verificationScore + commerceScore + emoticonScore + ecosystemScore ``` Weights, eligibility, and caps are policy inputs, not permanent economic rights. Current reward writes are simulation records. They do not mint PLAIS, create a debt, guarantee an allocation, or establish an exchange value. Before any settlement model is approved, PoSS must include: - stable source-event definitions and idempotency rules; - per-user, per-day, and per-category caps; - refund, cancellation, self-trading, and duplicate-event exclusion; - storage challenge and restore verification; - Sybil, fake-commerce, and fake-uptime detection; - delayed settlement and operator review; - an appeal and correction process; and - reproducible policy versioning for every calculation. ## Nodes, Storage, And Validators A storage or sync client is not automatically a validator. These roles are separate: - service client: submits authenticated ecosystem events; - storage or sync node: provides approved capacity or availability evidence; - node participant: enters an approved collateral and reward program; - validator: holds a QBFT validator identity and participates in consensus; - RPC node: serves controlled read and submission interfaces without voting. Validator admission, removal, rotation, uptime thresholds, penalties, emergency response, geographic or operator diversity, and conflict-of-interest rules require formal operating-policy approval before public-value activation. The canonical network has four validator identities on four independently attested hosts. Each host reports its bound validator identity, current canonical height, peer state, and fresh signed runtime evidence. Duplicate use of one validator key is forbidden. Validator-set changes and coordinated restarts require explicit, time-limited approval and must preserve a quorum of at least three validators whenever the procedure permits. ## Temporary TRX Collateral TRX may be used as a temporary external collateral asset for controlled node-participant rehearsal before native PLAIS collateral is practical. The current policy rate is configurable and is presently 100 TRX per 1 TB of approved node capacity. TRX collateral: - does not mint PLAIS; - does not change the canonical genesis supply; - is not a purchase of PLAIS; - does not create a guaranteed point or coin claim; and - does not make a storage client a validator. The server can verify a submitted TRON transaction hash, destination treasury address, native TRX amount, successful receipt, and required confirmation count. Confirmed or rejected decisions are anchored in the application audit trail. Public collateral intake should not expand beyond controlled operation until custody ownership, refund conditions, slashing authority, dispute handling, sanctions and source-of-funds review where applicable, accounting and tax treatment, incident response, and user disclosures are approved. A mock or test address must never receive real funds. The temporary policy must have an explicit retirement or migration process before native collateral is introduced. ## Supply And Economic Policy The 10,000,000,000 PLAIS genesis balance is the locked canonical genesis allocation. It is not circulating supply, a sale, or an authorization to distribute assets. Candidate distribution policy v0.2 allocates the fixed supply as follows: - ecosystem and user rewards: 32%; - node, storage, and validator rewards: 20%; - foundation treasury: 15%; - core team and contributors: 12%; - ecosystem partners and grants: 8%; - market and liquidity infrastructure: 6%; - community launch and eligibility: 5%; and - security and user-protection reserve: 2%. If a public launch is separately approved, the maximum TGE-unlocked ceiling is 800,000,000 PLAIS, or 8% of supply. Team allocation has no TGE unlock, a 12-month cliff, and 36-month linear vesting. Foundation allocation has a 12-month cliff followed by 60-month linear vesting. Ecosystem and node reward pools release over 120 months. Unlocked does not automatically mean circulating: actual circulation is based on observable transfers outside enforceably locked or issuer-controlled wallets. There is no private-sale allocation. Legacy points, testnet balances, reward history, and node activity do not automatically create a claim. Allocation wallets must be separated and published, and monthly supply reports must reconcile wallet balances, unlock ceilings, actual transfers, market-maker or liquidity balances, burns, and circulation to canonical genesis supply. The complete rules are in `docs/TOKEN_DISTRIBUTION_POLICY.md`. Public issuance remains locked until legal and tax review, audited vesting enforcement, public allocation wallets, custody approval, circulation reporting, and explicit launch approval are complete. Fee policy and any community eligibility snapshot still require separate approval. ## Security And Privacy The public Express service is the mainnet information and application control plane, not a public Besu RPC endpoint. The hardened deployment binds Express and Besu RPC to loopback, uses Nginx as the public ingress, redirects HTTP to HTTPS, requires HMAC v2 for protected API access, rate-limits sensitive paths, enables secure cookies and browser security headers, and keeps external transfers and legacy mutation paths locked. Security enforcement is fail-closed: unsafe drift in canonical-ledger selection, authentication mode, bind address, transfer locks, asset identity, supply consistency, or legacy issuance policy prevents normal startup. Remaining security work includes independent code and infrastructure audit, dependency and build provenance, penetration testing, validator-host hardening, key ceremony review, backup restoration, monitoring and alerting, denial-of-service planning, incident classification, disclosure channels, and post-incident reporting. Only minimum audit data should be retained. Personal content stays in the originating service unless a specific lawful and documented requirement says otherwise. A blockchain hash can itself become personal or sensitive metadata when it is linkable to a person; data mapping, retention, erasure handling, and access controls therefore require privacy review. ## Governance And Change Control Until a formal governance model is approved, canonical-mainnet changes are controlled operational decisions, not decentralized governance. At minimum, changes to genesis, validator membership, asset name or symbol, decimals, supply, issuance, conversion, external transfers, reward settlement, collateral, or signer availability require: - a written proposal and risk analysis; - review by technical, security, operations, and applicable legal owners; - reproducible test evidence and rollback steps; - explicit approval with named authority; - a versioned policy and configuration change; and - a public notice before any user-facing economic effect. Emergency action may protect the network, but it must be narrowly scoped, recorded, time-limited, and followed by a retrospective. No administrator should be able to silently turn a point into a coin, change supply, or enable public transfers through a routine dashboard action. ## Current Readiness Implemented or enforced on the canonical mainnet: - Besu QBFT selected as the only canonical asset ledger; - chain ID, genesis identity, validator set, liveness, and peer checks; - four independently attested validator hosts with fresh runtime evidence; - encrypted validator-key envelopes, approval-controlled delivery, and offline operator custody; - 11/11 technical mainnet launch-gate checks passed on 2026-08-04; - canonical PLAIS and legacy-point separation; - zero public circulation and locked external transfers; - read-only legacy application archive; - authenticated proof and reward gateway with HMAC v2; - MongoDB-backed application audit reads with migration controls; - canonical and legacy Explorer separation; - operator signing removed from the web process; - API, session, rate-limit, and HTTPS hardening gates; and - scripts and runbooks for validator distribution and key delivery. Open public-activation and exchange-support blockers: - production-grade HSM/KMS or remote-signer custody is not approved; - independent security and smart-contract review is incomplete; - exchange RPC/WS, deposit, withdrawal, confirmation, fault, recovery, and long-duration test evidence is incomplete; - distribution policy is defined, but legal approval, audited vesting enforcement, public allocation wallets, fee policy, and circulation reporting remain incomplete; - reward and storage fraud controls need sustained production-like evidence; - TRX collateral legal, custody, refund, and dispute policies need approval; - privacy, consumer, tax, sanctions, and jurisdiction reviews are incomplete; and - formal governance, incident response, user terms, and risk disclosures are not approved. ## Roadmap And Launch Gates ### Phase 1 — Canonical Mainnet Technical Gate — Complete Four-host validator distribution, encrypted validator-key controls, canonical liveness, and canonical/legacy boundary checks are complete. The technical gate passed 11/11; public controls remain locked. ### Phase 2 — Operational Assurance — In Progress Run sustained load, partition, validator-loss, upgrade, rollback, backup-restore, and incident drills across the independent hosts; publish repeatable evidence and known limitations. ### Phase 3 — Economic And Compliance Approval Finalize asset naming, allocation, emission, fees, treasury authority, PoSS settlement, collateral policy, user eligibility, privacy, legal, tax, accounting, and consumer disclosures. ### Phase 4 — Security And Custody Approval Complete independent audits, remediate findings, adopt production signer custody, conduct key and disaster-recovery ceremonies, and establish vulnerability disclosure and incident response. ### Phase 5 — Explicit Public Activation And Exchange Integration Only after every mandatory gate passes may a new written decision unlock public transfer access and authorize an exchange-integration application. Point balances, reward history, node operation, and genesis allocation do not automatically create circulating PLAIS or exchange eligibility. If a later gate fails, activation must stop or roll back according to the approved plan. ## Risks And Limitations Principal risks include validator concentration, key compromise, software defects, network partition, service-authentication compromise, database inconsistency, reward manipulation, storage-proof fraud, bridge or oracle dependence, privacy leakage, custody loss, regulatory change, treasury misuse, and misleading user expectations. QBFT finality does not guarantee the truth of off-chain service events. HMAC proves which registered service submitted an event, not that the underlying human activity was legitimate. PoSS and collateral controls therefore require source validation, fraud review, governance, and correction procedures in addition to cryptography. There is no guarantee that PLAIS will be publicly issued, transferable, listed, convertible from points, or have monetary value. Users and operators must rely on the current published policy and runtime locks, not on projections or informal statements. ## Reference Documents Detailed operational controls are maintained separately so this whitepaper can describe stable architecture and policy rather than deployment diary entries: - `docs/CANONICAL_LEDGER.md` - `docs/CANONICAL_ASSET_POLICY.md` - `docs/TOKEN_DISTRIBUTION_POLICY.md` - `docs/CANONICAL_VALIDATOR_MIGRATION.md` - `docs/OPERATOR_KEY_CUSTODY.md` - `docs/PUBLIC_API_HARDENING.md` - `docs/MAINNET_POLICY_DRAFT.md` - `docs/TESTNET_POLICY.md` - `docs/REWARD_SERVICE_INTEGRATION.md` - `docs/AISFOR_TOKENOMICS_V0.1.md` — historical simulation-policy baseline If a reference document conflicts with the active fail-closed configuration, the stricter lock applies until the conflict is reviewed and resolved through change control. ## Notice This whitepaper describes the canonical network and its locked public controls as of 2026-08-04. Technical settings and policies may change only through the documented approval process. Nothing in this document is financial, investment, legal, or tax advice, and nothing here is an offer or solicitation to buy, sell, or receive a digital asset.