Laika AI

← Back to Prediction Markets

Polymarket Token ID Explained

calendar

Posted Sep 01 2026

Polymarket Token ID Explained

If you've ever pulled up a Polymarket market in a dev console and seen a 70-plus digit number sitting where you expected something readable, that number is the market's token ID, and no, you didn't break anything. A Polymarket token ID is just how the underlying smart contract identifies one specific outcome, Yes or No, of one specific market, and once you know where it comes from it stops looking like gibberish and starts looking like plumbing.

This piece walks through what that number actually represents, how it's derived from a market's condition ID, and the much easier route most people should actually take instead of computing it by hand. 

What Is a Polymarket Token ID?

A Polymarket token ID, sometimes called a position ID or an asset ID depending on which part of the stack you're reading about, is the on-chain identifier for one outcome share of a market. Polymarket runs on something called the Conditional Token Framework, and under that framework every outcome of every market gets minted as its own ERC-1155 token. A simple Yes/No market has exactly two of these: one token for Yes, one for No.

Here's the part that trips people up. These aren't arbitrary IDs assigned by a database somewhere; they're mathematically derived from the market itself. Feed the same inputs - the oracle address, the question ID, the outcome index- into the same formula, and you'll always get the same token ID back. That determinism is the whole point; it's what lets any contract or script on Polygon verify a token belongs to a specific market without trusting a centralized lookup table.

The Conditional Token Framework, Explained

The Conditional Token Framework, or CTF, is the piece of infrastructure Polymarket didn't build from scratch. It's an adaptation of Gnosis's open-source conditional tokens standard, and it's what turns a plain-English market question into a pair of tradable, fully collateralized tokens.

Every Yes/No pair under Polymarket CTF is backed one-to-one by real collateral locked in the contract, meaning one Yes token plus one No token can always be redeemed for exactly one full unit of collateral, regardless of which side eventually wins. That backing is what makes the tokens actual claims rather than just betting slips.

Getting from a market question to a tradable token ID happens in three on-chain steps, and each step produces an intermediate ID the next step consumes.

Step

Function

What it needs

What it produces

1

getConditionId()

Oracle address, question ID, number of outcomes

The condition ID

2

getCollectionId()

Parent collection (always empty for Polymarket), condition ID, index set

The collection ID

3

getPositionId()

Collateral token address, collection ID

The final position ID, i.e. the token ID

The "index set" in step two is just a bitmask flagging which outcome a token represents, one value for Yes, a different value for No, in a standard binary market. Run the same three functions with the No-side index set instead of the Yes-side one, and you get a completely different token ID for the same market's other outcome.

How Token IDs Are Computed On-Chain

If you're building something that talks to the smart contracts directly rather than through Polymarket's own API layer, you'll eventually need to run this computation yourself. Polymarket publishes a small utility library specifically for this, and pulling a position ID from it looks roughly like this:

import { calculatePositionId } from "@polymarket/ctf-utils";

 

const conditionId = "0xbd31dc8a20211944f6b70f31557f1001557b59905b7738480ca09bd4532f84af";

const collateral = "0x2E8DCfE708D44ae2e406a1c02DFE2Fa13012f961";

const outcomeSlotCount = 2;

const outcomeIndex = 0;

const positionId = calculatePositionId(conditionId, collateral, outcomeSlotCount, outcomeIndex);

That single function call quietly runs all three steps from the table above and hands back the finished token ID as one long integer. If you're hunting for more tooling like this, Top 10 Free GitHub Repos for Polymarket Trading in 2026 rounds up the utility libraries and bot frameworks developers actually reach for, this one included.

Realistically, this manual path only matters if you're writing a smart contract that interacts with the CTF directly, building infrastructure that needs to derive IDs without an API call, or just want to understand what's happening under the hood before you trust a number some library handed you.

The Easier Way: Looking Up Token IDs via the Gamma API

Here's the honest advice: almost nobody needs to compute a Polymarket position ID by hand. Polymarket's own Gamma API already returns both outcome token IDs for you, no math required.

Hit GET /markets or GET /events for the market you care about, and look at the tokens array in the response. It'll contain both the Yes and No token IDs as plain strings, already computed, already correct.

That's genuinely the entire lookup process for the overwhelming majority of use cases, whether you're building a trading bot, a portfolio tracker, or just want to confirm you're placing an order against the right side of a market. If you're already leaning on AI tooling for the rest of your Polymarket workflow, How to Use Claude for Polymarket Trading in 2026 covers wiring up exactly this kind of API lookup, so you're not manually copying IDs out of a JSON response every time.

Compare that to a platform like Kalshi, where API access to your own orders and portfolio is well documented but doesn't hand you another user's position identifiers at all, since Kalshi accounts stay private rather than living on a public chain. Traders coming from that side of the industry and building out a Kalshi Trading Bot of their own will find the identifier model here works nothing alike, and that's worth knowing before assuming code written for one platform will port cleanly to the other.

Negative-Risk Markets and Token Conversion

Binary Yes/No markets are the simple case. Multi-outcome markets, the ones asking "who will win" across five or six candidates rather than a straight coin flip, run on what Polymarket calls negative-risk configuration, and it adds one extra mechanic worth knowing about.

In a negative-risk market, holding a No token on one outcome can be converted into Yes tokens across all the other outcomes in that same event. Practically, that means the token IDs involved aren't just a simple Yes/No pair; there's a full set of them across every outcome slot, and the conversion mechanism is what keeps pricing consistent across the whole group instead of letting each outcome trade in total isolation.

If you're pulling token IDs for a multi-outcome market via the Gamma API, expect the tokens array to be longer accordingly, one pair per outcome rather than one pair total.

A Quick Note on Collateral: pUSD vs. Older USDC.e References

If you're reading slightly older code examples or GitHub repos and see USDC.e referenced as the collateral token instead of pUSD, that's not a mistake; it's just from before Polymarket's platform migration. Some of the underlying mechanics stayed the same across that change, but the collateral contract address itself is different, which matters a lot if you're copying an old code snippet and wondering why your computed token ID doesn't match what the Gamma API returns. Polymarket V2 Technical Changes 2026: What Traders Need to Do walks through exactly what shifted and what old integrations need to update.Want to know how much you could make on a Polymarket trade? Enter your amount and entry price to instantly see your potential payout, profit, fees, and return before you trade.

 

Polymarket payout calculator showing trade amount, entry price, Yes or No position, order type, market category, estimated payout, net profit, fees, and share count.
Polymarket Payout Calculator: Estimate your payout, net profit, fees, and potential return before placing a trade.

Don't Confuse This With the POLY Token

One more thing worth clearing up, because search results tend to blur it together: a Polymarket token ID has nothing to do with POLY, the platform's own native cryptocurrency that's been the subject of launch speculation and an eventual airdrop. POLY, if and when it fully launches, would be a single fungible token representing the Polymarket platform itself, the kind of thing you'd hold in a wallet like any other coin. A token ID is the opposite of that; it's a unique, non-fungible-in-practice identifier for one outcome of one specific market, and there are effectively as many of them as there are outcomes across every market Polymarket has ever listed. If you searched for one and landed on news about the other, you're not going crazy; the naming overlap really is that unhelpful.

FAQs

What is a Polymarket token ID?

A Polymarket token ID is the on-chain identifier for one outcome of one market under the Conditional Token Framework, represented as an ERC-1155 token. Every binary market has two of them, one for Yes and one for No, and each is mathematically derived from the market's condition ID rather than assigned arbitrarily.

How do I find a market's token ID without computing it manually?

Query Polymarket's Gamma API at GET /markets or GET /events for the market in question and check the tokens array in the response. Both outcome token IDs are returned there already computed, so manual calculation is only necessary for direct smart contract integration.

What is a Polymarket position ID?

Position ID and token ID refer to the same thing, the final identifier produced after running getConditionId(), then getCollectionId(), then getPositionId() in sequence. "Position ID" is the more precise term used in Polymarket's own technical documentation, while "token ID" is the more common shorthand.

What is the Conditional Token Framework (CTF)?

The Conditional Token Framework is the smart contract system Polymarket uses to represent market outcomes as ERC-1155 tokens, adapted from Gnosis's open-source conditional tokens standard. It handles minting outcome tokens against locked collateral, splitting and merging positions, and redeeming winning tokens once a market resolves.

Share this article