Paycoin (PCI)

Paycoin (PCI): A Payment Token Moving From a Private Mainnet Toward PayChain

Paycoin is designed for spending rather than general-purpose smart-contract activity. Its current architecture combines a Hyperledger Fabric-based settlement network, a planned or emerging EVM-compatible PayChain, wallet and merchant services, and external payment partners. The main questions are how much activity is independently verifiable, how control is distributed, and how token supply and third-party dependencies affect users.

A payment network with two stated layers

Paycoin was created as the payment asset for PayProtocol, a project associated with Danal’s payment business. The project’s support documentation describes PCI as a utility token issued alongside a private Hyperledger Fabric mainnet, where participation is restricted to approved nodes. PayProtocol’s newer white-paper announcement describes a broader architecture: the existing Hyperledger network is intended to act as a settlement ledger, while PayChain is presented as an EVM-compatible payment blockchain for transaction execution, settlement coordination, liquidity management, and stablecoin exchange. This means Paycoin is not simply a token on one public chain; its use depends on a combination of project-operated infrastructure and external networks.

The available materials do not establish that every element of the newer PayChain design is already operating at full production scale. The white-paper announcement presents PayChain and Pay-to-Finance as the next-generation model, while the project’s general site continues to describe the existing Paycoin mainnet and payment services. Readers should therefore distinguish between deployed wallet or payment functions and design proposals or stated future architecture.

What PCI does in practice

The core stated use of PCI is payment. PayProtocol describes the token as a bridge between users and merchants, with app-based payments, QR transactions, exchange-linked payments, and international payment services. Its card materials describe a separate route in which users deposit PCI, convert it through liquidity infrastructure, and receive a fiat-linked balance for card spending. In that arrangement, PCI is the input asset, while the card transaction is settled using Fiat24 tokens denominated in currencies such as USD, EUR, or CHF. That distinction matters: holding PCI does not mean every merchant receives PCI directly.

The card route also adds operational dependencies. Users need a compatible wallet, identity verification, a Fiat24 account structure, supported geography, and access to the relevant liquidity and conversion path. PayProtocol’s documentation says PCI can be wrapped for use on Arbitrum and identifies PCI on both the Paycoin network and Arbitrum in its wallet instructions. Sending assets on the wrong network can result in loss, so network selection and custody arrangements are practical parts of the token’s utility rather than minor technical details.

PayChain, fees, and the proposed token economy

The October 2025 white-paper announcement assigns PCI wider functions within PayChain, including payment, settlement, staking, governance, and gas. It also describes a proposed fee policy in which 50% of payment and transfer fees would be burned, alongside a buyback-and-burn concept linked to payment activity. These are project-defined economic mechanisms, not independently established evidence that a particular burn rate, buyback volume, or demand effect has occurred. Their practical importance will depend on deployment, transaction volume, fee routing, and the rules governing any associated contracts.

The project’s lockup dashboard gives a more concrete view of supply administration. It reports a fixed total supply of 1.9 billion PCI and says foundation-held tokens are locked through contracts on Arbitrum, with allocations including reserve, ecosystem incentives, marketing, liquidity provision, and team holdings. The dashboard also records scheduled unlocks and transaction hashes. This improves the visibility of contractual releases, but it does not by itself show who controls each wallet, how unlocked tokens are used, or whether secondary-market liquidity can absorb future distribution.

Governance and operational control

PayProtocol’s revised architecture says PCI will have a governance role and that re-locking or redistribution after lockup periods may be subject to governance decisions. The inspected public materials do not provide enough detail to describe a complete voting system, such as proposal thresholds, voter eligibility, quorum, execution safeguards, or whether decisions are binding on the foundation and service operators. Governance should therefore be treated as a stated component of the design, not assumed to be equivalent to a fully documented, permissionless DAO.

The public code evidence is also narrower than the project’s service claims. The PayProtocol GitHub organization lists repositories for chaincode, token functions, identity, contracts, and an API. The API documentation shows account queries and transfers through named chaincode components such as kiesnet-token. That supports the existence of software interfaces related to the PayProtocol network, but a repository listing is not a security audit, uptime guarantee, decentralization assessment, or proof that every described service is controlled by the code available there.

Who the system is meant to serve

Paycoin is aimed at consumers, merchants, payment operators, and businesses that want to connect digital assets to ordinary checkout flows. The project’s website lists food and beverage, leisure, lifestyle, and culture merchants, while its card product targets users who want to spend a token through Mastercard acceptance. PayProtocol reports its own figures for users, active payers, merchants, and cumulative payments, but these are company-reported figures. They should not be read as independently audited measures of active PCI holders, transaction settlement on-chain, or recurring economic demand.

The intended user experience is therefore closer to a payment application than to a general smart-contract platform. Users may interact with the PayProtocol app, a private or non-custodial wallet, an exchange, a card issuer, a conversion venue, and sometimes Arbitrum. Each layer can introduce separate fees, geographic restrictions, identity requirements, service interruptions, or counterparty exposure.

What remains uncertain

Paycoin’s central limitation is that its utility is service-dependent. A payment token is useful only where wallets, merchants, conversion routes, payment processors, and applicable jurisdictions continue to support it. The private-mainnet model may help the project coordinate settlement, but it also places greater importance on approved operators and project-controlled infrastructure than a permissionless public chain would. The materials reviewed do not provide a complete independent record of network validators, service-level performance, or third-party security testing.

The most material open questions are whether PayChain’s proposed functions are fully deployed, how governance decisions are executed, how much payment activity is organic rather than promotional, and how future unlocks affect circulating liquidity. The lockup dashboard and public notices improve disclosure, but they do not remove market, custody, regulatory, smart-contract, bridge, card-provider, or operational risks.

Key takeaways

• Paycoin is primarily designed as a payment asset connected to PayProtocol’s wallets, merchants, settlement systems, and card products.
• The stated architecture combines a private Hyperledger Fabric settlement layer with a newer EVM-compatible PayChain design.
• PCI can be used as a payment input, but card spending may involve conversion into fiat-linked tokens rather than direct PCI settlement.
• The project describes future or expanded roles for PCI in gas, staking, governance, fee payment, and fee burning; deployment and execution should be verified separately.
• The lockup dashboard provides contractual unlock information, but token allocation visibility does not fully establish wallet control or market impact.
• Use of PCI depends on third-party processors, liquidity venues, identity checks, geographic availability, and correct network selection.

Risks and open questions

• The project’s public materials do not fully document the live status, validator structure, or operational performance of the newer PayChain architecture.
• Governance is described as part of the token model, but the inspected materials do not specify a complete voting and execution framework.
• Merchant, user, and payment figures on the project website are self-reported and were not treated as independently audited adoption data.
• PCI payment and card use depend on wallets, bridges or wrapping, liquidity providers, card issuers, and fiat-conversion infrastructure.
• Scheduled unlocks and large allocation categories may affect liquidity and supply distribution; the dashboard does not establish future selling behavior.
• Private-network controls, custody choices, smart contracts, bridge operations, regulatory requirements, and service interruptions can each create user risk.