AISFOR-CHAIN

# Whitepaper

한국어로 보기 Chain Home PLAIFOR Home
Updated 2026. 7. 2. 오후 1:52:22

# PLAI Chain Whitepaper

## Purpose

AISFOR-CHAIN is the development name for the internal proof, wallet, and settlement ledger layer. PLAI Chain is the public display brand candidate for this network. Its current role is not public coin issuance. It records authenticated service proofs, mock chain transactions, wallet transfers, block references, node-economy events, and callback confirmations so connected services can be audited through a chain-like ledger before any public mainnet decision.

## Network Services

The initial trusted services are:

- AISFOR
- AISTALK
- AISGROUP
- AISMALL
- AISFOR_CHAIN

AISFOR remains the canonical identity source. AISFOR user `_id` is treated as the stable network account identifier for user wallet mapping.

## Authenticated Proof Gateway

AISFOR-CHAIN accepts proof writes only from registered services when auth-required mode is enabled. Service clients can use API-key auth or HMAC v2 signatures.

HMAC v2 signed requests include:

- `X-AISFOR-SERVICE`
- `X-AISFOR-API-KEY`
- `X-AISFOR-SIGNATURE`
- `X-AISFOR-TIMESTAMP`
- `X-AISFOR-NONCE`

The signature covers service name, timestamp, nonce, HTTP method, path, and request body. Timestamp skew and nonce replay checks reduce accidental or malicious replay during service integration. AISFOR, AISTALK, AISGROUP, and AISMALL clients now generate HMAC v2 headers when service keys are configured. Unsigned proof writes are rejected in the current auth-required deployment.

## Proof Ledger

The proof ledger records service-originated events with idempotency by `sourceService + idempotencyKey`. Initial proof sources include AISFOR blockchain proof bundles, AISTALK chat activity, AISGROUP group activity, and AISMALL order activity.

Each accepted proof can be linked to:

- a proof ledger row
- a mock chain transaction
- a sealed block
- a service callback confirmation
- explorer views for address, transaction, and block traceability

## Wallet Layer

The wallet layer supports user and service wallets inside the mock ledger. User wallets can be created idempotently from AISFOR user ids. Service wallets are reserved for AISFOR, AISTALK, AISGROUP, AISMALL, and AISFOR_CHAIN.

Current wallet controls include:

- receive QR
- send form
- PIN protection
- recovery phrase setup, confirmation, and restore flow
- sensitive API response redaction
- wallet transaction to chain transaction anchoring
- wallet transaction ledger block hydration

A wallet transfer now produces an internal wallet transaction hash, a linked AISFOR-CHAIN transaction hash, and a ledger block reference after mining.

## Explorer

The explorer exposes a chain-style view of the internal ledger:

- `/explorer`
- `/explorer/address/:address`
- `/explorer/tx/:txHash`
- `/explorer/block/:height`
- search by address, transaction hash, or block id
- wallet transaction detail with linked chain transaction
- chain transaction detail with ledger block reference
- address detail with wallet and transaction history

The explorer is not a public-chain explorer yet. It is an internal audit surface for the mock chain ledger.

## Blocks And Mock Finality

Blocks contain height, previous hash, merkle root, block hash, and included ledger references. Pending proofs and transactions can be sealed into mock blocks. Validator assignment, voting, and `FINALIZED_MOCK` finality simulate later testnet behavior without claiming public settlement.

## Node Economy

Node participants can lock pledge points, receive rewards, and receive slashes. Node economy events create ledger rows and mock chain transactions. This is a simulation layer for future node and validator design.

## Chain Confirmation Callbacks

Finalized mock blocks create callback events for included proofs. AISFOR, AISTALK, AISGROUP, and AISMALL have initial callback receivers. Service-side chain status admin views expose proof/callback visibility:

- AISTALK: `/admin/chain-status`
- AISGROUP: `/master/chain-status`
- AISMALL: `/admin/chain-status`

## Ledger Database Migration Readiness

The live ledger still reads and writes `data/ledger.json`. MongoDB is currently used for migration staging and observation-only dual-write. Live reads still use JSON.

The DB migration path now includes:

- dry-run mapping from JSON arrays to DB-shaped documents
- deterministic `_migrationId` and `_sourceHash` values
- rollback snapshot checks
- shadow consistency checks
- MongoDB connectivity probe
- staging-only backfill into `migration_staging_*` collections
- staging compare by collection count and source-hash sequence
- admin visibility at `/admin/ledger-migration`

As of the latest staging and observation runs, 212 ledger documents were compared successfully with 0 failed collections. MongoDB observation dual-write is enabled for `observation_*` collections, and the short observation window runner reached 6 consecutive OK samples. The technical read-switch preflight is ready, but live DB reads remain locked until manual approval and a longer observation window across real service writes are complete.

## Current Implementation Status

Implemented:

- Node.js and Express AISFOR-CHAIN server
- proof ledger API
- mock chain transaction API
- file-backed ledger persistence
- mock block sealing
- node participant registry
- node pledge/reward/slash ledger
- point reward simulation
- validator assignment and voting
- mock finality
- chain confirmation callback ledger
- HMAC v2 service proof clients for AISFOR, AISTALK, AISGROUP, and AISMALL
- auth-required proof submission mode with unsigned write rejection
- service callback receivers for AISFOR, AISTALK, AISGROUP, and AISMALL
- end-to-end callback test across AISFOR, AISTALK, AISGROUP, and AISMALL
- admin dashboard
- service-side chain status admin views for AISTALK, AISGROUP, and AISMALL
- wallet UI with receive QR, send form, PIN protection, and recovery vault controls
- wallet API response redaction for sensitive fields
- wallet transfer PIN enforcement
- wallet transaction to chain transaction anchoring
- wallet transaction ledger block hydration
- explorer wallet, address, transaction, and block traceability
- MongoDB staging backfill and compare verification for ledger migration
- MongoDB observation dual-write, compare verification, window runner, and read-switch preflight gate
- PM2 process registration

In progress:

- database-backed ledger live writer and read switch
- persistent nonce store for production-grade replay protection
- retry queue for real callback delivery

Future:

- testnet deployment
- external node protocol
- production validator rules
- real mainnet adapter
- token/legal/economic design, only after technical and compliance review

## Mainnet Path

AISFOR-CHAIN should evolve in stages:

1. Mock mainnet prototype

2. Internal testnet

3. Service-integrated testnet

4. External validator testnet

5. Mainnet candidate

6. Public mainnet, only after security, legal, and operational readiness

The current server is the core prototype. It can keep growing as the mainnet candidate codebase, while deployment environments remain separate.

## Safety Statement

AISFOR-CHAIN currently records mock ledger events and simulated point rewards. It should not be represented as a launched public blockchain, issued cryptocurrency, or investment product.

Any future coin, token, or public mainnet design must be handled as a separate milestone with technical audits, legal review, security review, and operational controls.

## Latest Ledger DB Migration Milestone

On 2026-06-30, the MongoDB read backend candidate advanced from adapter-only readiness to live collection parity:

- Confirmed live Mongo backfill was executed with `scripts/ledger-mongo-live-backfill.js --confirm-live-backfill`.
- 212 ledger documents were written into live Mongo read candidate collections with `_ledgerLiveKind = ledger-json-live-backfill`.
- `scripts/ledger-mongo-read-compare.js` verified JSON vs live Mongo parity: 212 / 212 matched, 0 failed collections.
- MongoDB read adapter remains gated by explicit read-backend request and manual read-switch approval.
- Current live service reads remain on `data/ledger.json` until the read switch is explicitly approved and requested.

This milestone proves MongoDB can now hold a read-equivalent copy of the current ledger, while preserving JSON as the active live backend and rollback source.

## Controlled Read Gate Test

On 2026-06-30, a process-local MongoDB read gate test was completed without changing the running PM2 service environment:

- Temporary manual read approval was recorded.
- A separate Node process requested `AISFOR_CHAIN_LEDGER_READ_BACKEND=mongodb`.
- The Mongo read adapter passed the gate and read 212 documents from MongoDB.
- Temporary approval was revoked immediately after verification.
- Live AISFOR-CHAIN service reads remain on JSON.

## Mongo Read Snapshot Path

On 2026-06-30, AISFOR-CHAIN gained a synchronous read-switch bridge for the current Node.js service structure:

- A verified Mongo read snapshot can be materialized from live Mongo read candidate collections.
- `persistentStore.readState()` can read that snapshot only when a Mongo read request and manual approval are both present.
- A process-local switch test confirmed the store reads 212 rows from the Mongo-derived snapshot.
- The temporary approval was revoked after testing, so the running service remains on JSON reads.

This avoids introducing asynchronous Mongo reads into modules that currently load ledger state synchronously at service startup.

## PM2 Mongo Read Switch Rehearsal

On 2026-06-30, a temporary PM2-level Mongo read switch rehearsal was completed:

- The Mongo read snapshot was refreshed after 212 / 212 compare success.
- Manual approval and `AISFOR_CHAIN_LEDGER_READ_BACKEND=mongodb` were applied temporarily.
- The running `aisfor-chain` process was restarted and served admin, explorer, transaction detail, and address detail pages successfully under `mongodb-read-enabled`.
- The environment was rolled back to JSON reads and approval was revoked immediately after verification.
- Current live service mode remains `json-read-active`.

## Read Backend Operational Controls

On 2026-06-30, AISFOR-CHAIN added explicit read backend request and rollback controls:

- `Mongo Read 요청` records manual approval and sets the read backend request to MongoDB.
- `JSON Read 롤백` restores the read backend request to JSON and revokes approval.
- Every `.env` change creates a timestamped backup and switch-history record.
- PM2 restart remains a separate operational step, so operators can review the request before applying it.
- Current live read backend remains JSON.

## Mongo Live Writer And Snapshot Refresh

On 2026-07-01, AISFOR-CHAIN added the consistency layer needed after a future Mongo read switch:

- A gated Mongo live writer can refresh the live read candidate collections from the current ledger state.
- `persistentStore.writeState()` refreshes the Mongo read snapshot when Mongo read is enabled.
- `persistentStore.writeState()` can trigger live Mongo synchronization when live write is explicitly enabled or Mongo read is active.
- Manual live sync was verified: 212 documents synced, JSON vs Mongo compare remained 212 / 212, and the read snapshot refreshed to 212 documents.
- Current production mode remains JSON read with Mongo live writer on standby.

## Mongo Read Monitor Gate

On 2026-07-01, AISFOR-CHAIN added a repeated read monitor gate before any production Mongo read promotion:

- Each monitor sample compares live Mongo read collections against the JSON ledger without switching the active backend.
- The admin migration page shows the latest sample, expected/actual rows, failed collections, sample window, and consecutive OK count.
- The operational promotion rule is conservative: require at least 6 consecutive OK samples before treating Mongo read as ready.
- This keeps the switch decision evidence-based while live service reads remain on JSON.

## Mongo Post Switch Guard

AISFOR-CHAIN also includes a post-switch guard for the controlled promotion window. The guard compares JSON and Mongo ledger reads, then verifies the key service endpoints: admin, explorer, and ledger migration status.

The guard records health by default and does not change the active backend unless a CLI operator explicitly requests rollback-on-failure with confirmation. This keeps production promotion reversible while avoiding accidental backend changes from a normal admin-page health check.

## Controlled Mongo Read Promotion

On 2026-07-01, AISFOR-CHAIN completed the controlled Mongo read promotion. Final preflight passed, the read monitor reached 12 consecutive OK samples, and JSON-vs-Mongo parity remained 212 / 212.

The promotion recorded manual approval, set the read backend request to MongoDB, restarted the PM2 service with the updated environment, and confirmed runtime mode as `mongodb-read-enabled`. The post-switch guard then verified admin, explorer, and ledger migration endpoints with 200 responses. JSON remains retained as rollback source and can be restored through the guarded rollback control.

## Ledger Migration Completion

AISFOR-CHAIN has completed its ledger read migration from JSON-primary operation to MongoDB-primary reads. The final completion checkpoint confirmed `mongodb-read-enabled`, 12 / 12 successful read monitor samples, 212 / 212 document parity, and healthy admin/explorer endpoints.

The legacy JSON ledger remains available as rollback source, but it is no longer the active read backend. Future work moves from migration engineering to routine operational monitoring and broader chain feature expansion.

## PoSS Tokenomics v0.1

AISFOR-CHAIN now defines the first internal PLAI tokenomics model. AISFOR Chain remains the development name, while PLAI Chain is the public display brand candidate. This model is for simulation and testnet preparation only. It is not a public coin issuance statement.

- Chain development name: AISFOR Chain
- Service brand: PLAI
- PLAI meaning: Platform Life AI
- Public display chain name: PLAI Chain
- Initial reward unit: PLAI Point
- Public display coin name: PLAI Coin
- Public display symbol: PLAI
- Candidate maximum supply: 10,000,000,000 PLAI
- Operating sequence: internal point -> testnet token -> mainnet coin
- Reward model: PoSS, Proof of Service & Storage
- Token and coin names must be loaded from configuration, not hardcoded.

PoSS rewards useful contribution inside the AISFOR ecosystem. Reward categories include service usage, content creation, storage capacity, actual data retention, node uptime, file custody verification, shopping activity, emoticon pack creation and sale, and ecosystem participation.

The first reward engine runs in simulation mode. Simulation rewards are recorded in a reward ledger but do not represent public cryptocurrency issuance, guaranteed value, or exchange-tradable assets.

The initial score model is:

    rewardScore =
      serviceScore
      + contentScore
      + storageScore
      + uptimeScore
      + verificationScore
      + commerceScore
      + emoticonScore
      + ecosystemScore

Abuse controls must include daily reward caps, per-user caps, per-category caps, refund exclusion, self-trading review, fake commerce detection, storage proof challenges, suspicious activity flags, and delayed settlement.

The legacy mock wallet supply was aligned from 1,000,000,000 AIS under the development display to the Tokenomics v0.1 candidate maximum supply of 10,000,000,000 PLAI under the public display. The adjustment is recorded as a mock `SUPPLY_POLICY_ADJUSTMENT` ledger transaction to the foundation treasury.

AISFOR-CHAIN now includes a dedicated reward policy administration page at `/admin/rewards`. It displays PoSS categories, tokenomics status, category totals, top simulated actors, latest reward entries, and policy-based simulation controls. This keeps rewards in simulation mode while preparing later integrations with content, storage, commerce, and emoticon events.

AISFOR already maintains an internal AISFOR Point ledger for app activity and distributed storage contribution. AISFOR-CHAIN now accepts authenticated reward writes through `/api/reward`, so new AISFOR point events can be mirrored into the chain-side PoSS Reward Ledger with idempotency protection. This mirror does not double-pay points; it records the same event as a simulated reward proof for chain visibility. Batched point proof anchoring remains separate and can continue to provide range-based audit evidence.

Reward source readiness is tracked on the chain side before additional services are wired. `/api/reward/sources` and `/admin/rewards` list AISFOR, AISTALK, AISMALL, AISGROUP, and AISFOR_CHAIN source policies, including allowed reward categories, expected event types, and idempotency key patterns. AISFOR is connected through PointLedger mirroring. AISTALK, AISGROUP, and AISMALL now have service-side reward clients wired to real activity paths, with dry-run submission as the default and live simulation writes controlled by per-service environment flags.

AISTALK reward wiring covers chat activity, custom sticker message activity, emoticon pack store listing, and emoticon pack sale events. AISGROUP reward wiring covers group event-record creation and event-record comments. AISMALL reward wiring covers order creation and seller payment-confirmation events. These service integrations use stable idempotency keys so repeated requests do not duplicate simulated PoSS rewards.

The reward write API also validates source policy alignment. Unknown sources, disallowed categories, and idempotency prefix mismatches are stored as Reward Ledger flags. Unlisted event types and ready-but-not-connected sources are stored as review warnings. This keeps all reward activity visible without converting simulation rewards into public coin issuance.

Reward Ledger entries are visible through Explorer. `/explorer` lists recent PoSS reward entries, `/explorer/reward/:rewardId` shows validation and score details, and Explorer search can resolve reward ids, references, idempotency keys, external event keys, and proof hashes. This makes reward simulation auditable through the same interface as blocks, proofs, and transactions.

Reward Ledger entries can also be anchored into mock chain blocks. New blocks may include `rewardIds` and `rewardHashes` in addition to proof and transaction references, while historical block hashes remain unchanged. When a reward is mined, the entry receives block id, height, hash, and mined timestamp metadata. Explorer reward detail pages link back to the containing block, and block detail pages show the reward entries included in that block.

Reward submissions now also create an operational audit trail. Accepted `/api/reward` writes produce audit rows containing the source service, action type, category, actor, idempotency key, request hash, validation result, service identity, and linked Reward Ledger entry. Operators can inspect this through `/api/reward/audit` and `/admin/rewards`, giving reward integrations a tamper-evident review path before any testnet or public coin phase.

Explorer now exposes this audit trail as part of the same trace surface. Recent reward audit rows appear on `/explorer`, search can resolve audit ids, request hashes, idempotency keys, references, and linked reward ids, and `/explorer/reward-audit/:auditId` shows service identity, validation, request hash, and reward result details.

The reward engine now includes a cap gate for simulation rewards. Daily user and daily category caps are read from tokenomics configuration, and each reward records a `capReview` object showing the requested amount, remaining cap, and applied amount. When a cap limits a reward, the ledger flags the entry for review without treating the event as public coin issuance.

Reward review queueing is also available for operators. Entries with flags, failed source validation, or cap-limited amounts are exposed through `/api/reward/review` and summarized on `/admin/rewards`, allowing service integrations to be inspected before any later testnet or public-coin milestone.

Operators can record review decisions without rewriting the original reward ledger. `APPROVE`, `WATCH`, and `REJECT` decisions are stored in a separate review-decision ledger and surfaced through `/api/reward/review-decisions`, `/admin/rewards`, and Explorer review-detail pages, preserving an audit trail of why a flagged reward was accepted, watched, or rejected.

Review decisions also affect operations. `APPROVE` and `REJECT` close the pending review item, while `WATCH` keeps it in the queue for continued monitoring without changing the original reward ledger amount.

New review decisions emit a `REWARD_REVIEW_DECISION` chain transaction. This gives each operator decision a tx hash, mock-chain confirmation metadata, and a path to ledger-block anchoring. New decision transactions are auto-mined with the `reward-review-decision` reason so operators can inspect the tx and the ledger block anchor from Explorer.

Explorer transaction detail pages recognize reward-review metadata and link the tx back to the review decision, reward ledger entry, audit log, and block anchor. This makes review decisions traceable in both directions: from reward review to tx, and from tx back to reward review.

Block detail pages also surface reward-review traces inside the chain transaction list, so an operator inspecting a block can identify which transactions are review decisions and jump directly to the decision, reward, or audit records.

Reward-review monitoring includes chain transaction count, ledger-anchored count, pending anchor count, and missing review-transaction count. These counters are exposed through the reward review API and the admin rewards dashboard.

Operators can run review-anchor repair from the admin rewards dashboard or through the authenticated reward API. The repair pass recreates missing review-decision transactions when needed and retries ledger anchoring for decisions that still lack a ledger block reference.

Reward operations readiness is exposed through `/api/reward/readiness` and the admin rewards dashboard. The readiness view checks source policy configuration, reward ledger presence, audit log presence, review queue health, review-anchor health, and block-engine status.

AISFOR-CHAIN also exposes a reward integration manifest through `/api/reward/manifest` and the admin rewards dashboard. The manifest lists required reward submission fields, recommended trace fields, source-specific idempotency patterns, allowed categories, event types, guardrails, and sample payloads for AISFOR, AISTALK, AISMALL, AISGROUP, and AISFOR_CHAIN. This gives each service a stable integration contract while the reward engine remains in simulation mode.

The manifest is itself checked by a chain-side validation gate. `scripts/reward-integration-manifest-check.js`, `/api/reward/readiness`, and the admin rewards dashboard verify that published sample payloads satisfy the current source policy. This helps detect reward-contract drift before external services are connected.

Reward service authentication readiness is also surfaced before external integrations are enabled. `scripts/reward-service-auth-check.js`, `/api/reward/readiness`, and the admin rewards dashboard report which source services have configured chain credentials and which environment keys are still missing. This makes credential rollout explicit while the reward engine remains in simulation mode.

Before a service writes a reward event, it can submit the same payload to `POST /api/reward/dry-run`. The dry-run path requires service authentication but does not persist a Reward Ledger entry. It returns source-policy validation, duplicate status, score calculation, cap review, simulated reward amount, and whether the event would enter the review queue. The manifest dry-run script checks all published sample payloads against this path so integrations can be rehearsed before live reward writes.

Service integrations can use the chain-side helper in `lib/rewardIntegrationClient.js` to build HMAC v2 headers and submit reward payloads consistently. `scripts/reward-client-dry-run-example.js` demonstrates the dry-run and live simulation call pattern using a manifest sample payload, while `docs/REWARD_SERVICE_INTEGRATION.md` records the required fields, headers, and guardrails for ecosystem services.

AISFOR-CHAIN also includes an HTTP dry-run smoke gate for service integrations. `scripts/reward-http-dry-run-smoke.js` sends authenticated dry-run requests for every configured external reward source and records the result for the readiness dashboard. This verifies credentials, HMAC signatures, routing, source policy validation, and dry-run scoring together before live simulation writes are enabled.

The reward dashboard also derives a service rollout plan from source policy, credential readiness, and the latest HTTP dry-run smoke result. Operators can see whether each service is already connected, ready for controlled live simulation writes, or still waiting for service wiring. `scripts/reward-rollout-status.js` exposes the same plan from the command line.

A controlled live canary gate separates dry-run readiness from Reward Ledger writes. `scripts/reward-live-canary.js` runs as a dry-run by default, and it performs a live simulation write only when the operator supplies `--confirm=LIVE_SIMULATION_WRITE`. The latest canary result is shown on the rewards dashboard so operators can verify the transition point before broader service rollout.

The canary also has a preflight check. `scripts/reward-live-canary-preflight.js` verifies reward readiness, HTTP dry-run smoke, the latest dry-run canary, and rollout target availability before an operator is allowed to run the confirmed live simulation write.

After each canary, `scripts/reward-live-canary-postcheck.js` verifies the outcome. Dry-run canaries must not create reward or audit rows, while future confirmed live canaries must create a linked Reward Ledger entry and Reward Audit row. The rewards dashboard surfaces the same post-check status.

The final pre-execution step is an explicit canary permit. `scripts/reward-live-canary-permit.js`, `/api/reward/live-canary-permit`, and the rewards dashboard combine readiness, preflight, post-check, and rollout target state into a single `PERMITTED` or `LOCKED` decision before any confirmed live simulation canary is run.

Operator approval is recorded separately from execution. The rewards dashboard can persist or revoke a live-canary approval containing the permit id, service name, and permitted command. This approval is an operational checkpoint only; it does not execute the live simulation write.

The approved canary execution path is wrapped by `scripts/reward-live-canary-approved-run.js`. The wrapper refuses to run unless approval is recorded, the current permit still matches that approval, and the explicit `--confirm=LIVE_SIMULATION_WRITE` token is supplied. After execution, it immediately runs the canary post-check so the operator can verify the linked reward and audit records.

## PLAI Testnet Policy

AISFOR-CHAIN now has a controlled PLAI Chain testnet policy in `docs/TESTNET_POLICY.md`. The policy separates internal PLAI Point accumulation, PoSS reward simulation, controlled testnet token rehearsal, and any future mainnet coin decision.

The policy keeps public issuance, faucet, external wallet withdrawal, exchange, and cash-out flows disabled by default. Testnet balances are resettable and non-monetary. They do not represent public coin issuance, guaranteed future allocation, investment value, or exchange-tradable assets.

The rewards dashboard at `/admin/rewards` now includes a Testnet Policy Readiness panel. It shows the active testnet network id, chain display name, reserved symbol, issuance guardrail, validator count, genesis preview hash, and readiness checks from the chain-side testnet status service.

Mainnet policy review is intentionally separated from testnet operation. It requires stable reward rules across AISFOR, AISTALK, AISGROUP, and AISMALL, manageable abuse controls, documented reset and balance migration rules, approved supply and treasury policy, validator and staking rules, legal review, security review, and operational recovery evidence.

## Temporary TRX Collateral

Before PLAI has public liquidity or exchange availability, node and mining collateral may be accepted in TRX as a temporary external collateral asset. TRX collateral does not mint PLAI, does not change the candidate PLAI maximum supply, and does not convert into a public coin claim by itself. It is an operational deposit proof used only to rehearse staking, node participation, and abuse-control policy before PLAI collateral becomes practical.

The chain wallet now exposes a TRX collateral panel. A participant can see the configured TRX collateral treasury address, send TRX through an external wallet such as TronLink, submit the resulting TRON transaction hash, and request collateral verification. The server verifies the transaction through the TRON HTTP API before accepting it: the transaction must be a native TRX transfer, the target address must match the configured treasury address, the transferred amount must meet the submitted amount, the receipt must be successful, and the confirmation count must satisfy the configured threshold before auto-confirmation.

Operators can still inspect, confirm, or reject collateral requests from the admin dashboard. Confirmed and rejected collateral events are anchored as `PLAI_COLLATERAL` chain transactions so the operational decision is traceable through the same ledger surface as wallet transactions and reward-review decisions.

When no real TRX treasury address is configured, the system shows a mock testnet address and clearly marks it as test-only. Real TRX must not be sent to mock addresses. Production TRX intake currently uses the configured treasury collection address with transaction-hash verification. Full custodial per-user TRX address generation remains a later security milestone because it requires secured private-key generation, encryption, backup, rotation, withdrawal policy, and operational recovery.

This policy is temporary. Once PLAI has enough public-market and operational readiness, the preferred collateral asset should move from TRX to PLAI-based staking or another approved native collateral model.

## PLAI Mainnet Policy Draft

AISFOR-CHAIN now includes `docs/MAINNET_POLICY_DRAFT.md` as the first explicit mainnet decision draft. The draft keeps public PLAI Coin issuance, exchange listing, external wallet withdrawal, and point conversion locked until a separate approval milestone.

The draft defines the current decision boundary: internal PLAI Point is allowed, reward simulation is allowed, controlled testnet rehearsal is allowed, but public mainnet coin issuance is not approved. Internal points and testnet balances may be used as activity evidence only; they are not guaranteed claims, debts, or future allocations.

Before mainnet can be considered, PLAI Chain must pass technical stability, reward abuse-control, validator policy, wallet security, commerce policy, legal, tax, compliance, treasury, emission, and user-disclosure gates.

Markdown 원본 보기