Skip to main content

PlatON

PlatON — a reference card for a crypto project: what the product does and how verifiable the project’s key claims are; also — alignment with the Decentralized AI thesis (DecAI Fit).

PlatON — an Infra | L1 project (a public network for trustless/verifiable computation and onchain governance), token (symbol: LAT).

Disclaimer

Important: this page is a reference overview of the project. Within DecAIHub, we separately record a verification based on open sources within the AI thesis (what is real AI/onchain/why a token, and which sources this is based on).
This is not financial advice and not a recommendation to buy/sell/hold any asset. We do not assess price, returns, or entry/exit timing.
Conclusions are based on publicly available materials found as of the verification date. The absence of confirmation does not imply the absence of the technology.

TL;DR (for readers who are not into AI)

  • What it is: the PlatON L1 network for dApps, with a focus on trustless/verifiable computation and computation privacy.
  • Who it’s for: developers and teams that need a network and onchain rules/governance + computational/privacy primitives.
  • Why onchain/token: LAT is used for staking/delegation and participation in consensus/governance, as well as for network fees.

How it works (very briefly)

  1. The user does: deploys a node/validator or uses a wallet/SDK for transactions and staking.
  2. The system does: selects validators from candidate nodes via PPoS; runs consensus and applies onchain governance (proposals/voting).
  3. The user gets: a network for executing transactions/smart contracts, plus a staking/delegation economy and governance.
  4. Where the blockchain is: the base product is the L1 network itself; system contracts (staking/governance/slashing, etc.) have fixed addresses.
  5. Token role (if any): LAT is needed for staking/delegation and for paying fees (gas/tx fees).

Quick links: AI thesis fit

Project passport

Field Value
Project name PlatON
Also known as (aliases) LAT (token); PlatON Network
Logo (logo) ../assets/121_platon_logo.jpg
Token symbol (ticker) LAT
Category Infra | L1
Primary chain (chain) PlatON
Type Appchain
Network status mainnet
Consensus (consensus) PPoS (Proof-of-Pledge / PoS)
Launch date (launch_date) —
Project status (status) active
Token (standard) native
Token contract —
Token model (token_type) utility (gas + staking + governance)
Max supply — (not extracted in brief form from the current sources)
Issuance inflationary (there are “offerings”/issuance for the reward pool, see docs)
Tokenomics (tokenomics, brief) LAT is needed for staking/delegation; transaction fees go to validators
Governance onchain governance (proposal/voting) + the role of validators
Admins/keys —
Audit —
Bug bounty yes (Developer Bounty Program, Tier‑1: Medium)
Team (team) PlatON team + community (see website/GitHub)
Funding (investors/funding) —
AI component (ai_component) none
Use‑case (use_case) L1 network, staking, governance, compute
DecAI Fit — AI thesis fit 0/6 — no AI reality and no AI intent (ai_score=0)
DecAI Fit component summary 0 / 3 / 3 / 2
Last verified 2026-02-11

General project overview

PlatON is a public L1 network that the whitepaper positions as a “trustless computing network”: the idea is to separate heavy computation from onchain consensus and to ensure the verifiability of results (verifiable computation) and computation privacy (MPC/HE approaches are mentioned as part of the overall concept). In parallel, the network includes an onchain staking and governance economy: validators are selected via staking/delegation, and key protocol changes are discussed and voted on through the on‑chain proposals mechanism.

Features/modules

  • PlatON L1 network: transactions/blocks/validators (PPoS).
  • Staking and delegation: participation in security/consensus via LAT.
  • Onchain governance: proposals and voting (referendum and regular).
  • System contracts: staking/governance/slashing/lockup, etc., with fixed addresses (devdocs documentation).

Typical scenarios

  • Scenario 1: a LAT holder delegates to a validator → receives a share of the rewards, increases network security.
  • Scenario 2: a node operator stakes ≥ 100,000 LAT → becomes a candidate/validator and receives rewards/fees.
  • Scenario 3: a governance participant submits/supports a proposal → validators/the community vote and update parameters/versions.

Getting started (wallet/network)

  • What you need: a wallet/account with LAT for fees and/or staking; for a validator — node infrastructure.
  • Network/chain: PlatON mainnet.
  • Fees: fees (tx fees) in LAT; participation in governance may involve proposal fees/deposits (see governance docs).

Architecture/tech (non‑AI)

  • Components: network nodes, system contracts (staking/governance/slashing/lockup), client SDKs/tools (mtool/the ATON wallet in the docs).
  • Participant roles: LAT holders, delegators, candidate nodes/validators, developers.
  • Where logic runs: base logic — onchain (L1); staking/delegation and governance operations are available via system contracts.
  • Dependencies: system contracts with fixed addresses; RPC/SDK for interaction.

Token/economics (expanded, no forecasts)

  • Token utility: LAT is used for staking/delegation (participation in validator selection) and for fees/rewards (tx fees and rewards).
  • Protocol necessity drivers: without LAT it is impossible to become a candidate/validator and participate in staking/delegation; governance is also tied to LAT stake/validators.
  • Who pays fees: network users when transacting; proposal initiators pay a fee/deposit (per the governance docs).
  • Where fees go: tx fees for packaging transactions go to the validator that packs the block (per the validator docs).
  • Issuance/burn: the docs describe a rewards/offerings model (an inflationary component).
  • Security/incentive mechanisms: staking/delegation, rewards, slashing (including dual signing, zero‑block penalties).
  • Distribution and token issuance schedule: — (not extracted in detail in this card).
  • Treasury: a governance fund is mentioned in the governance mechanism (distribution via proposals/voting).

Governance

  • Who makes decisions: validators and LAT holders (a combination of direct/indirect democracy in governance, per the docs).
  • How protocol parameters change: via on‑chain proposals and voting (including software upgrade proposals).
  • Where decisions are discussed/made: on‑chain governance + PIP/GitHub processes (per the docs), the PlatONnetwork GitHub repositories.
  • Keys/multisig: — (not extracted).

Security and incidents

  • Audits: there are public statements about module audits (Tier‑1: Medium).
  • Bug bounty: there is a developer bounty program (Tier‑1: Medium).
  • Incidents: — (not extracted from Tier‑1 within this card).
  • Threat model: typical risks of PoS networks: centralization of stake/validators, bugs in system contracts, slashing and soft‑upgrade risks.

Project status and timeline

  • Current status: mainnet.
  • Key releases/milestones: client releases — in PlatON-Go releases.
  • Roadmap: — (no separate roadmap is set in the card’s links).

Ecosystem/integrations

  • Integrations: the ATON wallet, staking/delegation tools (mtool) and devdocs/SDK (per the official documentation).
  • Partners: — (not recorded within this card).
  • Where it’s actually used: an infrastructure network and a set of system contracts/processes (staking/governance).

AI component of the project

  • What is real AI here? Per the available Tier‑1 sources, PlatON does not describe an “AI module” as a product component; it is an L1 network and computation/privacy infrastructure.
  • What is truly onchain? The PlatON network and its system contracts (staking/governance/slashing/lockup, etc.) with fixed addresses.
  • Why is a token needed? LAT is needed for fees, staking/delegation and participation in validator selection/governance.
  • Red flags (based on the information found): AI‑washing (if the project is positioned as an “AI network” without Tier‑1 AI artifacts), what to double‑check: whether the current Tier‑1 docs contain separate AI products/demos/metrics.

DecAI Fit component summary

  • DecAI Fit: 0/6 — no AI reality and no AI intent (ai_score=0)
Component Level Score
AI reality absent 0
Onchain necessity high 3
Token necessity high 3
Evidence Tier‑1 partial 2
Details

AI reality

AI_0 — AI intent (Tier‑1 roadmap) (1/0)

  • AI_0 (decision): 0
  • Claim (one line): the available Tier‑1 sources contain no roadmap/promises about an AI component as part of the product
  • Evidence: Tier‑1 — https://platon.network/ , https://platonnetwork.github.io/docs/en/
  • Why sufficient / why not (one line): the Tier‑1 documentation focuses on L1, staking and governance; AI intentions are not highlighted
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 0
  • Claim (one line): AI functionality as a product module is not described
  • Evidence: Tier‑1 — https://platon.network/pdf/en/PlatON_A_High-Efficiency_Trustless_Computing_Network_Whitepaper_EN.pdf
  • Why sufficient / why not (one line): the whitepaper and docs describe trustless compute/privacy as infrastructure, but not an AI module/model
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): no demo of a working AI module was found (per Tier‑1)
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): there are no Tier‑1 examples/demos of “AI” specifically (in the sense of a model/agent/inference)
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): AI quality metrics are not applicable: no AI module is claimed
  • Conflict note (if any): —

AI_4 — tech description/architecture/versions (1/0)

  • AI_4 (decision): 0
  • Claim (one line): there is no technical description of an AI model/versions (no AI module is claimed)
  • Evidence: Tier‑1 — —
  • Why sufficient / why not (one line): there is no subject (an AI model) to describe/version per Tier‑1
  • Conflict note (if any): —

Onchain necessity

OC_1 — contracts/addresses/chain (1/0)

  • OC_1 (decision): 1
  • Chain: PlatON (L1)
  • Addresses/identifiers: system contracts with fixed addresses (example): staking lat1z...zsjx8h7, governance lat1z...93t3hkm (and others)
  • Evidence: Tier‑1 — https://devdocs.platon.network/docs/PlatON_system_contract
  • Why sufficient / why not (one line): the Tier‑1 devdocs list the system contracts and their fixed addresses
  • Conflict note (if any): —

OC_2 — onchain beyond just a token (1/0)

  • OC_2 (decision): 1
  • What useful logic is onchain: staking/delegation, governance proposals/voting, slashing/lockup — via system contracts
  • Evidence: Tier‑1 — https://devdocs.platon.network/docs/PlatON_system_contract , https://platonnetwork.github.io/docs/en/PlatON_Governance_Solution/
  • Why sufficient / why not (one line): specific onchain processes and interfaces (staking/governance) are described
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 1
  • “Replace the blockchain” test: without the PlatON L1 network there is no consensus/validators/system contracts and governance → the product disappears
  • Evidence: Tier‑1 — https://platon.network/pdf/en/PlatON_A_High-Efficiency_Trustless_Computing_Network_Whitepaper_EN.pdf
  • Why sufficient / why not (one line): the Tier‑1 whitepaper describes the network as the base unit of the product
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the network has a native token, LAT
  • Evidence: Tier‑1 — https://platonnetwork.github.io/docs/en/staking_and_delegation/
  • Why sufficient / why not (one line): staking/delegation is described as locking LAT
  • Conflict note (if any): —

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 1
  • Claim (one line): transaction fees (tx fees) are paid in LAT and go to the validators that pack blocks
  • Evidence: Tier‑1 — https://platonnetwork.github.io/docs/en/PlatON_Validation_Introduce/
  • Why sufficient / why not (one line): Tier‑1 directly states that the transaction fee goes to validators for packaging transactions
  • Conflict note (if any): —

TK_2 — incentives/collateral/penalties (1/0)

  • TK_2 (decision): 1
  • Claim (one line): LAT is locked in staking/delegation for validator selection and receiving rewards; violations are penalized (slashing)
  • Evidence: Tier‑1 — https://platonnetwork.github.io/docs/en/staking_and_delegation/ , https://devdocs.platon.network/docs/PlatON_system_contract
  • Why sufficient / why not (one line): Tier‑1 describes locking LAT and the roles of the staking/slashing contracts
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 1
  • Claim (one line): governance is tied to LAT stake/delegation: validators and LAT holders participate in proposals and referendums
  • Evidence: Tier‑1 — https://platonnetwork.github.io/docs/en/PlatON_Governance_Solution/
  • Why sufficient / why not (one line): Tier‑1 describes the roles of “Token holder” and validators, their rights and the voting process
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): as a PoS L1 network, PlatON relies on the native token for staking/fees/governance → it cannot be replaced without changing the model
  • Evidence: Tier‑1 — https://platonnetwork.github.io/docs/en/staking_and_delegation/ , https://platonnetwork.github.io/docs/en/PlatON_Governance_Solution/
  • Why sufficient / why not (one line): the token is embedded in the protocol mechanics of consensus and governance
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://platon.network/ the official project website
Tier‑1 https://platon.network/pdf/en/PlatON_A_High-Efficiency_Trustless_Computing_Network_Whitepaper_EN.pdf the positioning and architectural ideas of the trustless computing network
Tier‑1 https://devdocs.platon.network/docs/PlatON_system_contract the fixed addresses of the system contracts (staking/governance/slashing/lockup, etc.)
Tier‑1 https://platonnetwork.github.io/docs/en/staking_and_delegation/ LAT staking/delegation and the role of PPoS
Tier‑1 https://platonnetwork.github.io/docs/en/PlatON_Governance_Solution/ onchain governance (proposals/voting), the roles of LAT holders and validators

No comments to display

Back to top