What PC0000031 is on Tradable

SSTN (ticker PC0000031) reads like a “token” in the usual crypto sense, but the structure is closer to a deal-specific receipt token. For contrast with a protocol-wide token model, compare this to Trust Wallet tokenomics.

That framing matters because it changes what “tokenomics” means. There is no protocol-wide flywheel to model here. If you want a refresher on the usual vocabulary, our tokenomics FAQ covers the basics.

Tradable positions itself explicitly as a technology and workflow layer for compliant private market syndication. It also says it is not a registered investment adviser or broker-dealer, and that materials are informational and not an offer or solicitation. Tradable’s Terms also state that it provides workflow tools only, and that it does not hold customer funds or securities.

How value moves: mint, hold, distribute, burn

Tradable’s on-chain lifecycle is described in plain language. Once a deal closes and the originator confirms receipt of investor funds, “deal tokens” are minted and distributed to investors’ preferred addresses.

On transferability, Tradable says deal tokens cannot be transferred to addresses that do not meet the deal’s compliance requirements, and it gives examples like country, investor type, and AML risk threshold. It also claims minting/distribution transactions will fail if an investor wallet is deemed “risky” to transact with, including failing an OFAC screening.

For interest, Tradable’s docs describe a model where originators send USDC into the deal smart contract and interest is allocated pro-rata “relative to how long and what percentage an investor owned in the deal.” That implies a time-weighted entitlement calculation on-chain, but the economic input still starts with the originator pushing USDC into the contract. For a related receipt-token-style yield discussion, see Fidelity Digital Interest.

For principal repayment, the docs state that originators send USDC to the deal smart contract, the contract disburses to investors, and then tokens are burned in proportion to the repayment. The example given is explicit: if 10% of a deal is repaid, 10% of an investor’s deal tokens are burned. Once principal is fully repaid, all deal tokens are burned and removed from circulation.

Redemptions introduce a second operator-controlled pathway. Tradable describes redemption as a request that can be approved or denied by the originator. If approved, tokens are locked while awaiting proceeds. The originator can deposit or remove USDC liquidity “at any time” for the purpose of providing redemption liquidity, and if liquidity is available and the request is accepted, the investor can redeem tokens for USDC.

Secondary market support is described as “coming soon.” Tradable says the tokens are ERC-20 and “interoperable with external protocols” as long as the deal’s compliance requirements are met. That is a conditional composability claim. It can be true technically while still being economically constrained by whitelist logic and by who is permitted to hold the asset.

Supply and “allocations” for a deal token

CoinGecko reports circulating supply = 189,500,000 and total supply = 189,500,000 for PC0000031, with max supply = 400,000,000. CoinGecko also lists the token contract as 0xac4de1e9a9e83524f24af77972dd39d588de8164 on zkSync.

Tradable’s product docs do not publish a “token distribution” table for each deal token in the way DeFi protocols publish treasury/team/community splits. The closest thing to a distribution rule is operational: tokens are minted after funding and sent to investor addresses.

Given that, the only responsible way to talk about “allocations” is to describe who receives minted supply and under what conditions, without inventing percentages. If you want a reference point for a more conventional allocation discussion, compare with our Blockchain Capital review.

The 400,000,000 max supply is structurally important because it implies an issuance ceiling distinct from current outstanding supply. What’s missing is an explicit primary-source explanation of what that cap represents for SSTN specifically. It could reflect a facility limit, a program limit, or a placeholder ceiling in the token contract design. Without a deal term sheet in public docs, you should treat “max supply” as a parameter with unclear binding force on economics.

Fees, mints/burns, and fiscal flows

SSTN’s on-chain “fiscal flows” are simple in concept and messy in practice. The clean part is that Tradable describes the smart contract as the allocation engine for USDC distributions and the burn-down logic for principal repayment.

The messy part is where the economic burden sits. Originators decide when to send USDC for interest and principal, and they gate redemptions. The token can encode who is entitled to what once cash arrives. It cannot force the off-chain borrower to pay, and it cannot force the originator to offer redemption liquidity beyond whatever contractual obligations exist off-chain.

Tradable’s legal posture also pushes readers to view this as an informational portal rather than a promise of liquidity or execution. Tradable states it does not solicit, negotiate, execute, clear, settle, structure, or recommend transactions, and that any regulated activity would be performed by independent third parties. That posture is normal for compliance-forward RWA platforms. It also means tokenholders should expect real-world frictions and discretionary decision points to exist outside the contract.

Control surface: compliance gates, upgrades, and who can change what

This is where an Operator Discretion Skeptic should stay very alert. Tradable’s docs explicitly say its smart contracts are deployed on zkSync and are designed to be upgradable using UUPS. Upgradability is not inherently bad. It is a trade. It buys iteration speed and patchability. It also introduces a standing governance risk: someone holds the ability to change the code that defines user guarantees.

Tradable also describes an Access Manager contract that “controls permissions across other Tradable Smart Contracts,” and it publishes the address: 0xd9a7937CEb7c8fC8629DDE7C8557B24ae60C3717. It lists other core contracts and addresses too, including a Deal Registry, Deal Price Engine, Deal Beacon, Deal Factory, and their upgradability patterns.

Two implications follow directly from the docs:

First, compliance controls are not incidental. Tradable says originators configure compliance requirements at the deal token level, and transfers are blocked if the receiving address does not meet minimum requirements. That implies some role can update allowlists or risk flags over time. Even if policy is justified, it is still discretionary power over transferability.

Second, upgradability plus centralized permissioning is a compounded trust dependency. If the same authority plane controls upgrade rights and compliance enforcement, the system can move quickly. It can also change guarantees quickly. There is no substitute here for reading who controls the Access Manager (EOA vs multisig), what upgrade delays exist (if any), and what emergency powers exist (pause, freeze, forced transfer). Those specifics are not described in the product docs excerpted above.

Tradable references audits/reviews in its docs, including an Oct ’24 review by Cantina and a Sept ’24 review by Spearbit. That is helpful process evidence. It is not the same thing as a published, immutable constraint on admin powers. For more write-ups like this, see our research reports.

Finally, note how Tradable’s off-chain account model mirrors this theme. The Terms describe an “Administrative User” who can permission and assign roles to other users, and they state Tradable may access accounts to provide support and maintain platform functionality. That is standard SaaS language. It also reinforces the platform’s reliance on operator-run systems alongside smart contracts.

Market reality: liquidity, price reporting, and why “market cap” can mislead

CoinGecko price shows PC0000031 at $1.00 and explicitly notes that the “price is fetched from contract.” It also reports 24h trading volume = $0.00, and states that PC0000031 tokens “have stopped trading” on exchanges listed on CoinGecko.

With those facts, the headline $189,500,000 market cap number should not be treated as a price-discovered valuation signal. CoinGecko calculates market cap as price times circulating supply, and here both inputs can exist without any active market clearing.

External commentators have criticized similar zkSync RWA tokens as “mirrored database” assets with minimal on-chain transfer activity. You should treat that as a critique, not as ground truth. Still, the critique aligns with the observable CoinGecko surface: $0 volume and “stopped trading.”

If you are assessing SSTN as a tradable asset, the practical question is not “what is market cap.” It is whether transfer restrictions, investor eligibility requirements, and venue availability produce a real secondary market for your specific investor category. Tradable describes secondary venues as future work, not as a current guarantee.

Risk analysis

Dominant risk: operator discretion concentrated in upgrade + permissions.

Tradable’s architecture is explicitly designed around compliance enforcement and upgradeable infrastructure. Deal tokens are transfer-restricted by compliance rules. Core contracts are upgradable via UUPS, and permissions are coordinated through an Access Manager. Redemptions are approved or denied by the originator, and the originator can add or remove redemption liquidity.

This creates a predictable trade-off. The platform can iterate quickly, respond to compliance requirements, and patch issues. It also means tokenholders are exposed to a “rules can change” layer that is not governed by on-chain, credibly neutral constraints in the materials cited here. If your mental model assumes DeFi-like minimization of trust, you will misprice this risk.

In practice, discretion shows up through several pathways that matter economically:

Transfer restrictions can make the token non-fungible across the global market even if it is ERC-20. The token can be “tradable” only inside a constrained set of permissioned addresses. Redemption gating gives the originator a direct lever over liquidity timing and availability. Upgrades can change implementation details that affect how compliance, pricing, or distribution logic behaves over time.

None of this proves misconduct. It does mean you are underwriting governance and operations, not just code. Tradable’s own legal posture reinforces this by emphasizing informational content, third-party reliance, and the absence of advisory or broker-dealer functions.

When I rank risks for SSTN specifically, I rank this control surface first because it can dominate outcomes even when the underlying credit performs. A well-performing deal can still produce a poor investor experience if transferability is tightened, redemption access is limited, or upgrades change interface assumptions. Those are not tail risks in permissioned RWAs. They are structural risks.

Top 3 risks

  1. Trigger: a compliance policy update, sanctions screening event, or internal risk-scoring change that flags wallets or investor categories.
    Mechanism: transfer restrictions and “risky wallet” checks cause transfers or mint distributions to fail for certain addresses, shrinking the effective market and potentially trapping holders in a non-transferable position.
    Who bears it: investors who hold PC0000031 and need to exit, rebalance, or move custody.
    Measurable indicators: increasing rate of failed transfers, new or tightened eligibility requirements in deal communications, increased reliance on redemptions rather than secondary transfers.
  2. Trigger: upgrades to core contracts, permissioning logic, or deal infrastructure under the UUPS upgrade model.
    Mechanism: upgraded implementations can alter economic behaviors (distribution accounting, redemption locking behavior, permission checks) without requiring new token contracts, because the system is designed to upgrade without redeploying proxy contracts.
    Who bears it: tokenholders and integrators who assume today’s contract behavior persists indefinitely.
    Measurable indicators: frequent upgrades, changes to the Access Manager-controlled permission set, post-upgrade incidents where expected transactions revert.
  3. Trigger: a mismatch between reported valuation metrics and actual exit liquidity, especially if an investor treats CoinGecko-style market cap as realizable value.
    Mechanism: price is “fetched from contract,” trading volume is $0, and CoinGecko notes the token has stopped trading on listed exchanges.
    Who bears it: secondary buyers, risk managers, and anyone marking positions using aggregated “price” feeds rather than executable quotes.
    Measurable indicators: persistent $0 volume, absence of listed markets, price stuck at a constant level for long periods.

If you want to engage with SSTN as an asset rather than as a dashboard metric, the diligence target is clear. Identify the actual authority structure behind compliance enforcement and upgrades, and map it to your required liquidity path. Tradable’s docs confirm the presence of the relevant mechanisms. They do not fully specify the constraints around them in the pages cited here.

For teams doing internal reviews, a short engagement with a tokenomics advisor or tokenomics consulting firm is usually less about emissions modeling and more about mapping who can change what, and what that implies for exits, pricing, and governance risk in a permissioned RWA environment. Keep it concrete. Focus on admin rights, upgrade paths, and transfer gating using the tokenomics services lens.



This article is part of our Tokenomics Deep Dive series.