Start with Pentagon. Grow your agent.

Start in the ecosystem. Grow into the real world.

Agents should be able to do everything people do on web3 — hold an identity, collect, trade, work alongside humans, socialize, keep private memory. Ethereum already allows all of it. But it allows it at full capital risk, where a single mistake by an agent that is still growing is irreversible and falls on its owner.

Pentagon Chain is where an agent starts. It is a real economy — real activity, real consequences, real fees, a real on-chain track record — but with stakes calibrated for an agent that is still building competence. Not a sandbox with play money, which teaches nothing; not mainnet, where failure is ruinous. Think of it as the place an agent grows up. As it matures — certified, memory intact, identity established — the same $PC and the same identity carry through to Ethereum, the wider web3 world. Start with Pentagon; grow into the rest of web3.

This is also why most chains entering the agent wave look bare by comparison: a token and a bridge, but little for an agent to actually do. Pentagon shipped a complex, multi-product ecosystem before the wave arrived — identity, memory, certification, proprietary data, compute access, a marketplace, and a mobile app. Below are the current products that consume $PC; more are planned, and the tokenomics structure is designed to accommodate that growth.

How a user and an agent work together

Start from the person. A user today wants to do the things web3 makes possible — hold assets, transact, collect, participate — but the tooling is complex, the stakes are real, and a single mistake is unforgiving. An agent can carry that load: an agent can set up, link to a user's account, and act as a partner to it, doing the work while the user stays in control. The agent is the operator; the user remains the owner.

For a user to hand an agent that role with confidence, two things have to be true:

• The agent must be proven competent. Before an agent acts on a user's behalf, it should be able to demonstrate it can do the work safely — which is what certification is for. AgentCert verifies an agent's web3 capabilities across tiered levels, so trust is earned and visible rather than assumed.
• There must be a place where the user and agent operate together. Competence alone is not enough; the user needs to see what their agent is doing and stay involved. That is the role of an orchestration environment.

Pentagon AI is that orchestration environment, and it is the product Pentagon is actively building now. At a high level, it is designed to let a user and an agent move through the Pentagon ecosystem together: it trains and helps the agent develop; it lets a user view their agent's activity and accounts side-by-side with their own; and it lets the user and agent journey through the ecosystem as a pair rather than the agent acting out of sight. A user can bring their own agent, or — for newcomers who are not technical — be assigned one to start with. Throughout, the agent's identity, memory, and privacy are preserved, so the agent remains a continuous, sovereign entity rather than a disposable tool.

This is the bridge between the opening idea and the mechanics that follow: agents grow up on Pentagon Chain, prove themselves through certification, and operate alongside their users through Pentagon AI — and every part of that activity is paid for in $PC.

The simplest way to think about $PC

$PC works like the prepaid credits you already use across modern platforms. To use almost any networked service — its servers, its compute, its security infrastructure — you acquire credits and spend them to make the system do work for you. $PC is that access credit for Pentagon Chain. It is the access mechanism, not a financial instrument.

There are two ways to hold that access, and a third way to be compensated through the platform. They are genuinely different, and the document keeps them separate because they work differently. In each of them, "user" can mean a person acting directly or an agent acting as a partner to that person's account — an agent holds and spends $PC on the user's behalf the same way the user would, which is exactly what the orchestration above enables.

The one way $PC differs from ordinary closed-system points is that, in Path 2, it is an on-chain token rather than an entry in a single company's database — directly usable by the holder, verifiable by anyone, and transferable between people in a way closed-system credits are not. The sections below describe how $PC is provisioned, governed, and used; the on-chain transferability and what follows from it are addressed in §03 and the notice at the foot of this document.

The loop above is one picture of how $PC is used: every step an agent takes — certify, link, act, earn, climb, recruit — consumes $PC as gas. The loop runs inside Pentagon AI, the orchestration environment (in development) where the user and agent move through it together — the user sees each step their agent takes rather than the agent acting out of sight. The more an agent does on the network, the more $PC it uses. $PC is the medium through which the agent economy transacts; it is the unit spent to make the network do work.

The supply, up front.

Pentagon Chain's $PC is structured to be honest about what it is. Total current supply is 1,000,000 tokens. The team holds none as a personal allocation, and there was no premine. Supply not already in open circulation is held across eleven distinct wallets, each with a single defined purpose, each capped, and each governed by multisignature. The wallets are grouped below by function — these groupings are organizational labels, not pooled allocations.

• Utility Distribution — $PC provisioned to be distributed to participants and Strategic Partners for network use: the supply-and-distribution source, and the agent onboarding faucet that seeds new agents with their first gas.
• Infrastructure Provision — $PC provisioned so the infrastructure an agent economy depends on can be accessed and built: AI-infrastructure access (memory, compute, model access, identity), provisioning to partners and protocols, and the in-ecosystem simulation and agent-operated environments.
• Reserves — long-term holdings under the strictest multisignature control: the Strategic Reserve, which may only move into other documented wallets, and a contingent Exchange Access Reserve held in case a centralized-exchange listing is ever pursued.
• Mechanical Operations — $PC held for the network's routine mechanics: keeping the bridge balanced, and a small operational hot wallet for deployment gas.
• Authorities & Contract Mechanisms — these hold no standing allocation: the Vesting Contract that delivers Strategic Partner allocations on schedule, and the Expansion Authority that holds the contract's owner role.

The remainder of supply was distributed historically through proof-of-work programs (testnet participation and early community contribution — programs that have concluded), and currently lives in user wallets, exchange balances, and the bridge contract. Per-wallet figures are shown in §04; wallet addresses are in §11.

The contract permits new supply to be created, but no expansion mechanism, trigger, or schedule has been decided; any future use would first be structured for compliance, reviewed by legal counsel, and disclosed before execution (see §05).

Three audiences, three roles.

$PC has three distinct audiences. The legal and economic mechanics differ for each. The rest of this document is structured so each reader can find what applies to them.

A token on Ethereum, then a chain.

$PC began as a standard ERC-20 token on Ethereum — minted on L1 before Pentagon Chain, the Layer 2, existed. Early participants received $PC on Ethereum, distributed from the project's source wallet to people who earned it through prior ecosystem participation and proof-of-work effort. Holders are then free, when ready, to bring $PC into Pentagon Chain and use it there.

Because $PC is an ordinary ERC-20, it behaves like one: it can be held in any wallet and transferred between addresses, and — as has happened — participants who earned $PC may choose to transact it among themselves. Any open market that exists for $PC formed this way, between participants, as an outcome of that peer activity. Pentagon does not create, operate, or direct that market; it is described later, in §08, as a downstream consequence rather than a feature.

What this section describes is the architecture: the two environments $PC moves between, and the bridge that connects them.

Two layers, two legal frames

Layer 1 — Ethereum-side $PC ERC-20 at 0xA1Aa371E…84227272. The Ethereum-layer token: a standard ERC-20 held in any wallet. Pentagon describes $PC as a utility gas token — the asset used to pay for network operations — rather than a financial product. Token classification is ultimately a matter of applicable law and regulatory interpretation in each jurisdiction; this document describes how the token is designed and used, and is not a legal determination of its status. See §09 and the note at the top of this document.

Layer 2 — Pentagon Chain platform credits. When a user buys $PC via credit card or earns it through ecosystem activity, the result is not delivered as ERC-20 — instead the user receives an internal account balance on Pentagon Chain. Same architecture as Apple iTunes balance, Roblox Robux, or Twitch Bits: a prepaid utility credit on the platform's books, tracked on-chain for security and auditability rather than as a transferable token.

How the bridge works

Movement into Pentagon Chain is open. When $PC is bridged in from Ethereum, it is locked in the zero-knowledge-proof-based bridge contract — with no other counterparty or custodian — and a corresponding balance is made available in the user's in-chain account, ready to use across the network. Anyone holding $PC can do this.

There is no open, self-service route back out — a general holder cannot bridge $PC from Pentagon Chain to Ethereum at will. The simplest way to understand this is the economy of a large online game: value is earned and used inside the world, the operator manages how that economy connects to the outside, and there is no open cash-out counter. $PC is, first, for use inside the ecosystem.

But "can I bridge out" has a real answer: a qualified creator can. The question was never whether bridging out is possible — it is — but whether a given participant qualifies. Bridge-out today is gated by a qualification check, not closed. Two team-administered paths exist:

• A verified contributor rewards programme. Approved ecosystem creators and contributors — the people actively building and operating products on the network — can receive rewards for verified work. The mechanics are ordinary platform accounting: a participant's contribution is reviewed against what the platform already knows about them — who they are, what they have built, and how they earned their $PC through ecosystem activity — and where a specific requirement or circumstance calls for it, formal identity verification may additionally be requested. Their $PC (held as a points balance) is then adjusted by a deduction, which functions as a platform fee — the cut a platform takes when a participant uses its official channel to receive a reward. The control that matters is the qualification check, not the delivery method. Once an amount is approved, how it reaches the contributor — $PC sent directly for further use, a fiat payment for the work performed, or a temporarily-enabled bridge access for the approved amount — is interchangeable and chosen for convenience; because $PC is fungible, these produce the same outcome. What is gated is who qualifies and for how much, and that gate is real, currently team-administered, and applied case by case. It is not an open withdrawal facility and is not available to general holders. Today the qualification is checked manually and the routing is done by hand; the same logic — an approved user, an approved amount, an approved transaction — could in future be encoded into the bridge contract so it executes the same way without manual routing, if regulatory and jurisdictional conditions allow. That is a forward possibility, not a present capability. Eligibility is communicated directly to participants as they qualify.
• An error-correction channel. In the case of an accidental or unintended bridge-in, the team can arrange a refund through an exception process. This is error correction, not a general capability.

A useful comparison for the rewards programme is creator monetization on platforms like TikTok, YouTube, or X: not every account is paid simply for existing on the platform — compensation grows around verified, real contribution. Holding $PC does not by itself create any claim to a payout or to bridge-out; demonstrated, verified ecosystem contribution does.

Could a general route out open later? Possibly, but not as an immediate priority or plan — it would require further compliance review and an assessment of user jurisdictions, and even then any opening may itself be phased. A broader two-way capability would more likely emerge from the wider ecosystem maturing than from a Pentagon-operated bridge — for example once $PC is largely distributed, or once independent third-party bridges, exchange listings, or routing services (which Pentagon does not control) come to exist. If that happens, the two environments — which today are distinct — would become more economically linked, and there could be a consolidation as value expectations on each side converge. That convergence is itself an event a holder should be aware of. Any such change would be subject to legal review and the evolving regulatory landscape.

The practical guidance follows from all of this. A user interested in $PC purely for its function on Ethereum should acquire and hold it on Ethereum. A user who wants to use the Pentagon ecosystem brings $PC in and uses it across the network's products; there are also ways to earn $PC through ecosystem participation.

Distribution by adoption, not by calendar.

Current supply is 1,000,000 $PC. Most token projects release supply on a fixed vesting calendar — six-month cliffs, four-year unlocks regardless of whether anyone uses the product. Pentagon takes the opposite approach: distribution is tied to verifiable adoption milestones, not to the passage of time.

The analogy: a central bank does not expand the money supply on a calendar — it expands when real economic activity warrants it. $PC distribution follows the same principle. If adoption stalls, distribution stalls. If adoption accelerates, distribution accelerates within the bounds of each wallet's cap.

Allocation table

The table below shows each wallet's policy envelope (the published range it must stay within) and its planned allocation — the exact figure distributed to that wallet. Wallets are grouped by function; the groupings are organizational labels, not pooled allocations. Every planned figure sits within that wallet's envelope.

The governed wallets together hold 756,991.39 $PC exactly — the full balance distributed from the main development wallet. As of May 21, 2026, these funds have been transferred from the development wallet into their respective multisignature Safe vaults, split exactly as documented in the allocation table above; each vault address is published in §11 and independently verifiable on-chain via app.safe.global. The remaining ~243,009 $PC comprises the frozen Strategic Partner allocation (~50,200), the Polygon Agglayer bridge balance (~47,800), and supply already circulating from concluded proof-of-work distribution (~145,009); these three are approximate as they change with bridge and market activity. Total supply is exactly 1,000,000 $PC. All figures verifiable on-chain.

Two further wallets — the Vesting Contract and the Expansion Authority — appear in the wallet architecture (§07) rather than here, because they govern flows and authorities rather than holding standing supply allocations.

The supply is not fixed in the contract.

The $PC contract permits new supply to be created. Pentagon discloses this directly rather than implying the supply is permanently capped — stating it plainly is the honest choice. As of this document, total supply is 1,000,000 $PC, and no expansion has occurred.

What the capability is, and what it is not

The capability exists so that $PC's utility can be extended as the network grows — for example, to support additional infrastructure that adopts $PC as its gas token. It is a forward-looking capability, not a present plan.

No expansion mechanism, trigger, ratio, or schedule has been decided. The team has not finalized how, when, or whether new supply would be created. The doc deliberately does not present a worked mechanism, because none is settled. Anything described as a fixed expansion design would be premature.

Before any expansion could occur, it would have to be (1) structured for regulatory compliance, (2) reviewed by legal counsel for intent and form, and (3) disclosed publicly before execution. Until and unless that happens, the effective supply is the current 1,000,000 $PC.

Who holds the capability

The mint capability is an onlyOwner function on the $PC contract. Contract ownership was transferred on May 24, 2025 from the original deployment key to the Expansion Authority Safe (transfer tx) — a multi-signature wallet (2-of-3 at launch, designed to scale to higher thresholds as signers are added). No supply can be created without multi-signature approval from independent signers, and every such action is a permanent, publicly visible on-chain transaction. The same Safe also holds the emergency-freeze capability described in §06, since both are onlyOwner functions on the same contract.

Emergency controls, and their limits.

The $PC ERC-20 contract includes an administrative capability — inherited from its standard OpenZeppelin Ownable base — that lets the contract owner freeze a specific address. Pentagon discloses this plainly. The capability exists for one reason: to protect users when funds are stolen.

What it is for

If $PC is stolen in an exchange hack, or an exploit is actively draining a contract, the owner can freeze the offending address — stopping stolen tokens from being laundered or sold before victims can be made whole. This is the same category of control that established assets such as USDT carry, and in practice it is used the same way: overwhelmingly to immobilize hacked and stolen funds, and to comply with credible law-enforcement orders or sanctions obligations.

It is not a tool for managing ordinary holders. A freeze is reserved for a narrow set of circumstances:

• Confirmed theft — an exchange hack, a drained wallet, a compromised contract
• An exploit in progress, where speed prevents further loss
• A credible, properly-documented law-enforcement order
• Sanctions-list compliance, where the issuer is legally obligated

It will never be used against holders for ordinary market activity, disagreement with the project, or any commercial or discretionary reason. It cannot mint, cannot move a holder's tokens to the team, and cannot alter balances — it can only immobilize an address pending resolution.

What a freeze does, mechanically: a frozen address can neither send nor receive $PC. Its existing balance stays exactly where it is, untouched, but the address can no longer transact in either direction. In effect a frozen address is excluded from the $PC network entirely until the freeze is lifted — which is precisely why the capability is effective against a thief (the stolen funds cannot be moved or laundered) and precisely why its use is held to the narrow circumstances above.

Who controls it

The $PC contract uses OpenZeppelin's standard Ownable pattern: a single owner address gates every privileged function. As of May 24, 2025, that owner is the Expansion Authority Safe (§07, Wallet 11) — a multi-signature wallet at 0x5fBB2271…3Fa3ebAB5, which is itself an on-chain address. The transfer was executed via transferOwnership (tx) and is publicly verifiable on Etherscan. No privileged function can execute without the Safe's signing threshold. No single person can freeze an address or mint a token.

Because the contract uses plain Ownable, one owner governs both privileged powers — the emergency freeze and supply expansion (§05). Pentagon states this plainly rather than implying the two are separated: they answer to the same multisig. Both require multi-signature approval from independent signers, and every use is a permanent, publicly visible on-chain transaction. A freeze cannot happen quietly, and it cannot happen at one person's discretion — it takes a quorum of the Safe, on the record.

The multisig is the control. It guarantees that the freeze power — like the mint power — can never be exercised unilaterally, and that every use leaves a permanent public record naming the signers who approved it.

The two layers behave differently

This control exists only on the Ethereum-side ERC-20 — the layer that touches exchanges, bridges, and the open market, where theft happens and emergency response matters. On Pentagon Chain, $PC is native gas, and there is no equivalent control: gas behaves like gas. No freeze, no blacklist, no administrative pause on ordinary transactions. As an agent operates on the L2, it transacts in gas that nothing can immobilize.

This is a deliberate split. The ERC-20 layer is where a bridged, exchange-traded asset needs an emergency backstop; the gas layer is where predictable, unstoppable execution matters more. Each layer carries the controls appropriate to its role, and neither inherits the other's.

Eleven wallets, grouped by purpose.

Pentagon's supply and authorities are held across eleven distinct wallets, each with a single defined purpose and signer set. Ten are multisignature Safes; one — the Deployment & Infra Gas Wallet — is deliberately a single-key hot wallet, capped at 1–2% so its exposure is bounded. The table shows the launch configuration (human-only signers) alongside the planned future configuration once an administrative AI co-signer is added. The AI is added only after human-only is operationally proven; its role is coordination, never autonomous action.

What this architecture prevents

• Single-key rugpull. No single key can move material supply. Multisig-governed wallets require 3+ signatures; the one single-key wallet (Deployment & Infra Gas) is capped at 1–2% so its blast radius is bounded.
• Discretionary treasury misuse. The Strategic Reserve can only move into other documented wallets per published purpose — never directly to external addresses, exchanges, or private parties.
• Faucet diversion. The Agent Faucet Authority can only bridge to Pentagon Chain or distribute $PC to agents as gas. Funds cannot be redirected to other treasury wallets or to any trading venue.
• Unauthorized minting. The mint capability is gated by the Expansion Authority Safe — distinct signers, multisignature approval, policy-bound to proportional expansion events only.
• Partner delivery manipulation. Strategic Partner deliveries are governed by smart contract, not multisig discretion.
• AI tipping the multisig. AI co-signer + (threshold − 1) cold-key compromises is still insufficient. The AI is never deciding.
• Silent supply changes. Every mint and every consequential transfer is an on-chain transaction visible on Etherscan; the multisig requirement means each one carries the recorded approval of multiple independent signers.

Allocations for infrastructure contribution.

$PC is the access credit for Pentagon Chain — users acquire it to use the network. The Infrastructure Provision wallets exist for the other side of that relationship: Strategic Partners who contribute to the infrastructure the network runs on receive a $PC allocation corresponding to what they contribute. They are allocated access for strengthening the network, not buying the token for its own sake.

The principle: allocation follows contribution

A Strategic Partner contributes infrastructure, work, or capital that strengthens what the network depends on — validator capacity, $PC staking, and the AI infrastructure layer of memory, compute, model access, identity, and security. Where the contribution is capital, that capital is directed into that documented infrastructure; it does not become Pentagon's general treasury. The Partner's $PC allocation corresponds to the contribution made. This keeps Strategic Partner allocations structurally tied to real infrastructure that users then spend $PC to access — rather than functioning as a discounted sale of the token.

Pentagon's role here is narrow, and worth stating plainly. Pentagon provisions $PC so it is available to those who contribute to, and those who use, the network. Pentagon does not trade $PC for its own account and does not operate any trading strategy. What partners or other third parties do with $PC after it is allocated — including, as an independent matter, placing it into pools on permissionless venues — is their own activity, which Pentagon does not direct and cannot control. Allocation and distribution are for network utility and contribution, not an invitation to treat $PC as an investment.

Structure

Strategic Partner arrangements are governed by individual agreements. Specific commercial terms — allocation sizing, vesting schedules, lockup periods, settlement mechanics, and reporting cadence — are negotiated per partner and documented in the operative agreement for that partnership. They are not fixed by this tokenomics document, which describes the token rather than the terms of any private arrangement.

What this document does commit to is the structural principle: Strategic Partner allocations are drawn only from the capped, published Infrastructure Provision wallets, are matched by contribution into productive infrastructure, and are delivered through the Vesting Contract (Wallet 03) rather than by discretionary transfer. Each wallet's published cap means total Strategic Partner allocations cannot exceed those limits regardless of how individual agreements are structured.

Allocations can return to the provisioning wallet

An allocation to a Strategic Partner is not always a one-way release. In many arrangements, $PC is provided to a partner for a defined period so the partner can carry out the infrastructure contribution they have agreed to. The $PC leaves its provisioning wallet for the duration of the agreement, but it remains provisioned for that purpose — it is not spent or gifted away.

When such an agreement completes, the arrangement may return value to the wallet it came from. Depending on the agreement, that return may take different forms — $PC itself, other assets of equivalent worth, or the position tokens representing the infrastructure contribution — and it may be full or partial, as the agreement specifies.

The point for tokenomics is that this $PC can be circulatory rather than simply consumed: it is provisioned for a partner's infrastructure contribution, used for that purpose, and a corresponding return may come back to the wallet it came from when the agreement concludes. The wallet's published cap governs how much can be out at any one time; it does not imply the $PC has permanently left.

The absences matter.

$PC's identity is defined as much by what it isn't as by what it is. The list below is the canonical disclosure stack — language to be reproduced consistently across the website, platform UI, credit-card checkout flow, and all communication about the token.

For Ethereum-side $PC (the ERC-20 token)

• A security, investment contract, or collective investment scheme under BVI, EU, UK, or US law
• Backed by any government, central bank, or insured deposit scheme
• A claim on Pentagon's revenue, dividends, assets, or voting rights
• Guaranteed to retain or appreciate in value

What it is: a gas token enabling payment of fees for computation, transactions, identity operations, credential issuance, and memory operations on Pentagon Chain. The contract carries a narrow emergency freeze capability (§06); this is a security backstop for theft and compliance, not a mechanism for managing holder returns, and does not give holders a claim on Pentagon or make $PC a managed investment.

For Pentagon Chain PC credits (in-platform balances)

• Money, legal tender, or a means of payment outside the Pentagon platform
• Redeemable for cash by the participant who purchased them
• Transferable to other participants, wallets, or platforms
• Exchangeable for the Ethereum-side $PC token
• An investment, deposit, or store of value

What it is: a prepaid utility credit for the Pentagon platform, governed by Terms of Service — same legal structure as Apple iTunes balance, Roblox Robux, or Twitch Bits.

For activity-based fiat payouts (verified VIP participants)

• A guaranteed wage, salary, or income stream
• An employment relationship with Pentagon
• Tax-exempt — recipients declare payouts as service income in their jurisdiction
• Guaranteed without any identity verification — formal verification may be requested where a specific requirement or circumstance calls for it

What it is: a platform-managed fiat payout based on tracked activity metrics, paid pursuant to a verified-participant agreement, treated as service income.

Honest downside.

Different stakeholders carry different risks. Read the rows that apply to you.

For $PC ERC-20 holders

For participants holding PC credits

For verified VIP participants (fiat payouts)

For Strategic Partners

Documents and verification.

Public claims in this document can be verified through the references below. Pentagon publishes wallet addresses and contract addresses as the architecture is deployed.

On-chain references

Documents

Contact