my-project-public

repository

loading code, commits, and activity

repositories

loading repo index

#1	{
#2	"skillId": "dflow-kalshi-portfolio",
#3	"name": "dflow-kalshi-portfolio",
#4	"description": "View what a wallet holds on DFlow's Kalshi prediction markets — current positions, unrealized mark-to-market, realized P&L, activity history, and redeemable winners. Use when the user asks \"what are my positions?\", \"what do I own?\", \"am I up or down?\", \"what's my fill history?\", \"what can I redeem?\", \"mark my portfolio to market\", or \"show me this wallet's DFlow activity\". Read-only. Do NOT use to place sells or redemptions (use `dflow-kalshi-trading`), for market-wide data unrelated to a wallet (use `dflow-kalshi-market-data`), or to discover new markets (use `dflow-kalshi-market-scanner`).",
#5	"category": "pump-protocol",
#6	"path": "dflow-kalshi-portfolio/SKILL.md",
#7	"url": "https://x402.wtf/api/skills/dflow-kalshi-portfolio",
#8	"tags": [
#9	"dflow",
#10	"solana",
#11	"kalshi",
#12	"portfolio"
#13	],
#14	"requiredEnv": [],
#15	"homepage": null,
#16	"attestation": {
#17	"status": "pending",
#18	"isFormallyVerified": false,
#19	"attestationPda": null,
#20	"verificationTimestamp": null
#21	},
#22	"markdown": "---\nname: dflow-kalshi-portfolio\ndescription: View what a wallet holds on DFlow's Kalshi prediction markets — current positions, unrealized mark-to-market, realized P&L, activity history, and redeemable winners. Use when the user asks \"what are my positions?\", \"what do I own?\", \"am I up or down?\", \"what's my fill history?\", \"what can I redeem?\", \"mark my portfolio to market\", or \"show me this wallet's DFlow activity\". Read-only. Do NOT use to place sells or redemptions (use `dflow-kalshi-trading`), for market-wide data unrelated to a wallet (use `dflow-kalshi-market-data`), or to discover new markets (use `dflow-kalshi-market-scanner`).\n---\n\n# DFlow Kalshi Portfolio\n\nRead-only views on a wallet's Kalshi activity — holdings, mark-to-market valuations, realized P&L, fill history, redeemable positions.\n\n## Prerequisites\n\n- DFlow docs MCP (`https://pond.dflow.net/mcp`) — install per the [repo README](../../README.md#recommended-install-the-dflow-docs-mcp). This skill is the recipe; the MCP is the reference. Look up exact response shapes, pagination, and batch-endpoint payloads via `search_d_flow` / `query_docs_filesystem_d_flow` — don't guess.\n- `dflow` CLI (optional, for the fast-path holdings view) — install per the [repo README](../../README.md#recommended-install-the-dflow-cli).\n\n## Surface\n\nThere is no `/positions` endpoint. A portfolio is assembled by hand from onchain wallet balances + metadata joins. Two ways to do it:\n\n- CLI — `dflow positions` — one command, dumps spot + outcome tokens for the active vault wallet with balances and market labels. Covers \"what do I hold right now?\" on the CLI, and the stablecoin `uiAmount` already reads as USD. Doesn't carry mark prices for outcome tokens, `redemptionStatus`, or fill history, so outcome-token valuation, redemption checks, and P&L still need the API pipeline. Active-vault only.\n- API — build-your-own pipeline — needed whenever the user wants any of: mark-to-market, P&L, activity history, redemption eligibility, or to inspect a wallet that isn't the CLI's active vault.\n\n## Quick path: `dflow positions` (CLI)\n\nOutput (single JSON envelope, same on every wallet):\n\n```json\n{\n \"ok\": true,\n \"data\": {\n \"wallet\": \"<pubkey>\",\n \"positions\": [\n { \"type\": \"spot\", \"mint\": \"...\", \"symbol\": \"USDC\", \"amount\": \"1326161\", \"uiAmount\": 1.326161, \"decimals\": 6 },\n { \"type\": \"outcome\", \"mint\": \"...\", \"symbol\": \"DFlowYU0192\", \"amount\": \"2000000\", \"uiAmount\": 2.0, \"decimals\": 6,\n \"side\": \"yes\", \"market\": { \"title\": \"...\", \"status\": \"active\" } }\n ]\n }\n}\n```\n\n- `type: \"spot\"` — SOL, USDC, CASH, and anything else in the wallet.\n- `type: \"outcome\"` — Kalshi outcome token; additionally carries `side` (`\"yes\"` \| `\"no\"`) and a minimal `market` (`title`, `status`).\n- No flag to inspect another wallet. For that, use the API pipeline.\n\n## Full path: build-your-own (API)\n\nThe canonical pipeline, from the DFlow recipe [`/build/recipes/prediction-markets/track-positions`](https://pond.dflow.net/build/recipes/prediction-markets/track-positions):\n\n1. Read wallet balances via Solana RPC — `getParsedTokenAccountsByOwner(wallet, { programId: TOKEN_2022_PROGRAM_ID })`. Outcome tokens are Token-2022. (For stablecoin balances, also query the classic SPL token program.)\n2. `POST /api/v1/filter_outcome_mints` — send the wallet's mint list, get back just the PM outcome mints.\n3. `POST /api/v1/markets/batch` — fetch full market metadata for those outcome mints (title, status, closeTime, `yesBid` / `yesAsk` / `noBid` / `noAsk`, `redemptionStatus`, `accounts.yesMint` / `noMint`).\n4. Join — map each holding to its market; determine YES vs NO by matching the held mint against `accounts.yesMint` / `accounts.noMint`.\n\nField-level detail (response envelopes, pagination) → docs MCP.\n\n## Views on top of the pipeline\n\n### Current positions\nOutput of the pipeline above. Optionally attach current mark price per position (`yesBid` for YES holdings, `noBid` for NO holdings — see mark-to-market below).\n\n### Unrealized mark-to-market\nValue each outcome holding at the bid on its side (what you could sell it for), not the ask:\n- Long YES → `uiAmount * parseFloat(yesBid)`\n- Long NO → `uiAmount * parseFloat(noBid)`\n\nSum across positions for a wallet-level unrealized value. Subtract cost basis (below) for unrealized P&L.\n\n### Realized activity and P&L\n`GET /api/v1/onchain-trades?wallet=<pubkey>&sortBy=createdAt&sortOrder=desc&limit=N` — DFlow-indexed view of the wallet's onchain fills.\n\n- Activity feed: each row has `createdAt`, `marketTicker`, `side`, `inputAmount`, `outputAmount`, `transactionSignature`.\n- Cost basis per market: track net settlement-mint flow per outcome mint (settlement-in on buys minus settlement-out on sells).\n- Fees: sum `feeAmount` across fills in the settlement mint.\n\n### Redeemable sweep\nA holding is redeemable iff all three:\n- market `status` is `determined` or `finalized`,\n- market `redemptionStatus` is `\"open\"`,\n- the held outcome mint is the winning side (from market `result`).\n\nTo redeem, hand off to `dflow-kalshi-trading` (redemption is a sell of the winning side back to the settlement mint).\n\n### Pending order check\nIf the app submitted the order itself, persist the `orderAddress` returned at submission and poll `GET /order-status?orderAddress=<addr>` until terminal. There's no list-by-wallet endpoint. Most fills terminate well under the CLI's 120s poll budget, so this is rarely a user-facing concern — but outside the maintenance window, don't assume a specific fill time.\n\n## What to ASK the user (and what NOT to ask)\n\nView shape — infer if unambiguous, confirm if not:\n\n1. Which view — holdings / mark-to-market / realized P&L / activity / redeemable.\n2. Wallet pubkey — API only (CLI uses the active vault wallet).\n\nInfra — always ask, never infer (HTTP/RPC pipeline only; the `dflow positions` quick path needs neither):\n\n3. DFlow API key (only when the script is hitting the Metadata API directly — `markets/batch`, `onchain-trades`, etc.). The CLI quick path (`dflow positions`) doesn't need one — it uses the CLI's stored config. *For the HTTP pipeline, ask with a clean, neutral question: \"Do you have a DFlow API key?\"*** Don't presuppose where the key lives — phrasings like \"do you have it in env?\" or \"is `DFLOW_API_KEY` set?\" nudge the user toward env-var defaults they didn't ask for. Surface the choice; don't silently fall back to env or to dev. It's one DFlow key everywhere — same `x-api-key` unlocks Metadata + Trade APIs. Yes → prod host `https://prediction-markets-api.dflow.net` with `x-api-key`. No → dev host `https://dev-prediction-markets-api.dflow.net`, rate-limited. Pointer: `https://pond.dflow.net/build/api-key`. When you generate a script, log the resolved host + key-presence at startup.\n4. RPC URL — yes, ask here, unlike spot/PM trading or market-data. The HTTP pipeline reads token accounts directly via RPC; there's no wallet in the loop to do it for you. Recommend [Helius](https://helius.dev). CLI users on the `dflow positions` quick path don't need one — `dflow setup` already configured it.\n\nDo NOT ask about:\n- Settlement mint, slippage, fees, signing — read-only skill. If the user pivots to acting on a position, hand off to `dflow-kalshi-trading`.\n\n## Gotchas (the docs MCP won't volunteer these)\n\n- No `/positions` endpoint. Portfolio = wallet balances + metadata joins. Don't hunt the API for a shortcut.\n- Token-2022 program for outcome tokens. `TOKEN_2022_PROGRAM_ID`, not the classic token program. Query the classic program separately for USDC/SOL/CASH.\n- Mark-to-market = bid, not ask. Long YES → `yesBid`. Long NO → `noBid`. Marking on the ask overstates the portfolio.\n- Two POST endpoints. `filter_outcome_mints` and `markets/batch` both take a POST body with an address list. Easy to default to GET and fail.\n- Stablecoins aren't outcome mints. `filter_outcome_mints` strips them out (they're settlement, not positions). Track USDC / CASH balances separately from the PM view.\n- Redemption readiness is three ANDed conditions, not just \"market closed.\" Surface a redeemable list only when status + `redemptionStatus` + winning side all line up.\n- Balance lag after fill. A fill that just landed onchain may not show up immediately on a non-indexed RPC — the token account update propagates after the transaction finalizes. Debounce rapid refreshes, and if the user expected a balance change and doesn't see it, retry before assuming failure.\n- `dflow positions` is active-vault only. No `--wallet` flag; switching wallets means `dflow setup` or the API pipeline.\n- `dflow positions` returns balances, not mark prices. You get `amount` / `uiAmount` / `decimals` plus `side` + `market.title` + `market.status` on outcome tokens. That already gets you close to dollar value for USDC and CASH (their `uiAmount` ≈ USD modulo depeg), but outcome tokens need `yesBid` / `noBid` from `markets/batch` to mark, and other spot tokens (SOL, etc.) need an outside spot price. No `redemptionStatus` and no cost basis in the output either — pair with `markets/batch` for redemption eligibility, `/onchain-trades` for P&L.\n- Closed outcome token accounts. After a full sell or redeem, the token account may be closed (rent reclaimed) and will no longer show up on the wallet. That's expected — check onchain-trades history if you need the record.\n- Same market, different rail = separate position. Every Kalshi market on DFlow has a USDC rail and a CASH rail, each with its own `yesMint` / `noMint`. A wallet can hold YES on both rails of the same market — those are two rows in the portfolio, two redemption flows, and their mark-to-market sums independently. Rare in practice (most users stick to one rail) but worth handling if it shows up.\n- Two surfaces, two auth paths. `dflow positions` shells out through the CLI and uses its stored config (key, wallet, RPC) — the script plumbs nothing for that call. The build-your-own HTTP pipeline (`markets/batch`, `onchain-trades`, RPC `getParsedTokenAccountsByOwner`) is plain HTTP/RPC and needs the DFlow API key + RPC URL plumbed in explicitly. They're independent: the CLI's stored key isn't reachable from a sibling HTTP client. Only ask about API key + RPC for the HTTP pipeline.\n\n## When something doesn't fit\n\nFor anything not covered above — full response envelopes for `filter_outcome_mints` / `markets/batch` / `onchain-trades`, pagination params, Proof state in the picture, edge cases in `redemptionStatus` transitions, order-status terminal states — query the docs MCP (`search_d_flow`, `query_docs_filesystem_d_flow`). Don't guess.\n\nFor runnable reference code, point at [`/build/recipes/prediction-markets/track-positions`](https://pond.dflow.net/build/recipes/prediction-markets/track-positions) (and its Cookbook Repo link).\n\n## Sibling skills\n\n- `dflow-kalshi-trading` — sell, redeem, or otherwise act on a position you see here.\n- `dflow-kalshi-market-data` — market-centric data (orderbook, trades, candles, in-game) for a position you're watching.\n- `dflow-kalshi-market-scanner` — find new markets to open positions in.\n- `dflow-proof-kyc` — verify a wallet before it can buy into new positions.\n"
#23	}
#24

z6Mkq5mY3JWtxoxUobWcfNHm7AkRubgSWEZTkBVqZXJviFZ5/my-project-public