Inside App Arena: per-entry portfolios, USD balance, and on-chain payouts to reach

Each App Arena user signs in through Privy, pays $10 in TradeStars USD to enter a weekly league arena, receives 1,000 in-arena credits, and trades fractional player shares across the fixture week. That gives the integration four overlapping data surfaces that have to be modeled together: a real-money USD ledger, a set of arena-bound credit accounts, a per-entry portfolio, and a Solana settlement record that anchors paid entries and payouts. A team building portfolio mirroring, weekly reconciliation, tax exports, or a cross-arena analytics layer needs all four. The Play Store category reads as Finance; the product itself is a fantasy player-share game, not a bank, and the integration design follows the latter.

The route we recommend leads with the in-app surfaces under the user's Privy session, with Solana RPC reads for settlement and payout roots as a verification layer. Native export is light: the app's profile screen exposes withdrawal requests but does not produce a structured download of trades or arena history, so the integration carries that load.

The surfaces an integrator actually touches

Each row below is named the way the app names it where the docs commit to a label.

Three authorized routes into the data

Authorized interface integration of the in-app traffic

The studio captures the HTTP calls the App Arena clients make while a consenting account is signed in through Privy, identifies the endpoints that back the arena list, an entry's holdings, the trade history and the USD balance, and documents the request and response shapes. This is the route that gives the richest coverage of the surfaces above. Effort is moderate. Durability is medium: changes ride along with regular product updates of the TradeStars app, and the maintenance contract carries a scheduled re-map against the captured response corpus so a UI revision does not silently break the feed.

Solana on-chain reads for settlement and custody anchors

Arena settlement, payout roots, withdrawal requests and the USDC collateral backing paid entries are on Solana per the TradeStars FAQ. A public RPC endpoint reads them. Coverage is narrow but durable, and this route doubles as an independent check against the in-app ledger: if the in-app summary says one number and the chain says another, the chain wins on the audit. Useful even when the integration is mostly built on route one.

User-consented credential access through Privy

For per-user automation, the integration uses the user's own Privy session to talk to the same endpoints the mobile client uses. Sign-in methods are email, Google or wallet-connect; if the user has no wallet, Privy creates one. We design the flow so consent scope, refresh and revocation are explicit, and so a single user can authorize across several arena entries without re-onboarding.

In practice route one carries the bulk of the build for most clients, route two is folded in as the independent settlement check, and route three is added when the integration must act on behalf of an individual user rather than mirror an aggregate read-only feed.

What lands at delivery

• An OpenAPI specification for the in-app endpoints actually used by the App Arena client, organized by the surfaces in the table above.
• An auth flow report covering the Privy session, JWT exchange, refresh and the user-consented revocation path.
• A Solana read module: arena settlement, payout-root verification and withdrawal-request mirroring, using a public RPC endpoint with documented rate posture.
• Runnable client source in Python and Node.js for: listing the user's active arenas, fetching one entry's holdings, paging trade history, reading USD and credit balances, and pairing the result with the on-chain settlement entry for that arena.
• Automated tests against a captured response corpus, so a regression after a TradeStars front-end update is caught in CI rather than in production.
• Interface documentation written for the integrator who will keep the feed alive, including the multi-entry data model (entry_id as the join key, not user_id) and the reconciliation pattern between in-app ledger and on-chain settlement.
• Compliance and data-retention guidance: consent scope under Privy, what user data the integration stores, and a written record of authorized access.

A look at the client code

Illustrative; field names and paths are confirmed during the build against the live client.

# Read one user's active arena entries, the holdings inside each entry,
# and reconcile the closing payout against Solana settlement.

import httpx
from solana.rpc.api import Client as SolanaRPC

PRIVY_SESSION = "<jwt-from-user-sign-in>"
ARENA_BASE    = "https://api.tradestars.app"   # confirmed during the build
SOL_RPC       = "https://api.mainnet-beta.solana.com"

h = {"Authorization": f"Bearer {PRIVY_SESSION}"}

def list_active_entries():
    r = httpx.get(f"{ARENA_BASE}/v1/me/entries?status=active", headers=h, timeout=15)
    r.raise_for_status()
    return r.json()  # [{entry_id, arena_id, league, credits, fantasy_points, rank}, ...]

def entry_holdings(entry_id):
    r = httpx.get(f"{ARENA_BASE}/v1/entries/{entry_id}/holdings", headers=h, timeout=15)
    r.raise_for_status()
    return r.json()  # [{player_id, shares, avg_price, last_price}, ...]

def entry_trades(entry_id, cursor=None):
    p = {"cursor": cursor} if cursor else {}
    r = httpx.get(f"{ARENA_BASE}/v1/entries/{entry_id}/trades", headers=h, params=p, timeout=15)
    r.raise_for_status()
    return r.json()  # paged: {trades:[...], next_cursor}

def settlement_for(arena_id):
    # The TradeStars FAQ describes settlement, payout roots and withdrawals as written on Solana.
    # We read the program account for this arena and verify the payout root.
    sol = SolanaRPC(SOL_RPC)
    acct = sol.get_account_info(arena_program_address(arena_id))
    return decode_settlement(acct)   # {closed_at, payout_root, total_usdc_paid}

for e in list_active_entries():
    holdings = entry_holdings(e["entry_id"])
    trades   = entry_trades(e["entry_id"])
    settle   = settlement_for(e["arena_id"]) if e.get("closed") else None
    yield {"entry": e, "holdings": holdings, "trades": trades, "settlement": settle}

The shape that matters above is the join. entry_id is the primary key inside the in-app surfaces; arena_id is the join into the Solana side. A user holding ten entries in one arena returns ten records on the in-app side and a single settlement record on the chain side, and the reconciliation step is where most integration bugs in this class of app live.

Consent, USDC custody, and the rules around the money rail

App Arena pays out in USDC on Solana, so the regulatory shape is closer to a crypto-funded fantasy product than a banking app. Two distinct consent boundaries matter, and they sit on different sides of the integration.

On the data side, sign-in is through Privy. Consent for the integration to act on a user's behalf rides the same session: the user authenticates as they would in the app, the integration holds a refresh token under documented scope, and revocation is a single explicit call. We store the minimum needed to keep the feed live, log every authorized read, and operate under NDA where the client requires it.

On the money side, the TradeStars FAQ describes paid entries as backed by Solana collateral and settlement and withdrawal requests as on-chain. A read-only integration does not touch custody at all; it mirrors USD balance and settlement records but never moves funds. Anything that crosses from read-only mirroring into initiating withdrawals or transfers we scope separately, with the client, because that is a different risk surface and a different posture. For users in the EU and the UK, the data side falls under GDPR and we apply data-minimization accordingly; geographic eligibility for fantasy sports trading itself sits with TradeStars, not the integration.

Engineering notes from the build

These are the specific places we have seen this app's shape bite, and how the studio absorbs them so the integrator does not.

• Treat entry_id, not user_id, as the primary key. A user can hold up to 10 independent entries in a single arena per the TradeStars arena docs, each with its own portfolio, credit balance and rank. A schema that keys on user-plus-arena collapses ten parallel strategies into one and is the most common silent bug we have to undo on this kind of app.
• Pin a settlement snapshot at arena close. Credits reset weekly and the live screen rolls forward to next week's arena, so historical positions disappear from the in-app view. We capture an immutable snapshot when the arena closes, anchored to the Solana settlement record so it can be re-verified later. Without that snapshot, anything that wants a one-year activity history has nothing to show.
• Reconcile the in-app USD ledger against on-chain USDC at every settlement. The in-app balance and the Solana view will normally agree, but they are produced by different systems and a one-cent drift over months is exactly the kind of finding an accounting or tax-export build is meant to catch. We wire the reconciliation in by default, not as an after-the-fact audit step.
• Re-validate after each TradeStars client release. The in-app endpoints ride on product updates; after each release the captured response corpus is replayed through the integration's test pack, so a renamed field or restructured payload surfaces in the corpus first rather than in production.
• The Play Store description's "more than 90% success rate" is the app's marketing copy, not a data field. Integrators sometimes look for that number in the API; it is not there. The integration surfaces the underlying entries, fantasy points and payouts that the figure was summarising, and we say so on the page rather than synthesising a metric.

What was checked, and when

The shape above was assembled from the live App Arena Play Store listing (developer description, app version metadata), the TradeStars product site (arena structure, sport coverage), and the TradeStars FAQ (Privy authentication, USDC on Solana, settlement and withdrawal mechanics). Coverage of the Polygon-to-Solana history was read against the long-form coverage of the TradeStars launch on crypto.news. Open citations:

• App Arena on Google Play (com.tradestars.arena)
• TradeStars: Arenas and Entries documentation
• TradeStars FAQ (Privy auth, USDC on Solana, settlement and withdrawals)
• crypto.news: TradeStars decentralised fantasy sports ecosystem

OpenBanking Studio integration desk · mapping reviewed 2026-05-29.

Where App Arena sits among player-share platforms

An integrator looking at App Arena is usually also looking at one or two of the apps below. Each holds adjacent data and is worth naming so a unified feed can reach across the category instead of stopping at one product.

• Sorare holds licensed digital player cards and lineup-contest results; the per-user data is ownership of cards and tournament entries rather than fractional shares.
• Rario ran a cricket-focused digital card and fantasy contest stack; its user data leans on card ownership and contest scoring.
• FanCraze covers cricket NFTs and fantasy gameplay, with card collections and contest entries as the per-user state.
• Fanton runs fantasy football on Telegram and holds a card collection, daily lineup and contest results per user.
• NBA Top Shot holds licensed basketball moment NFTs and per-user collections, plus marketplace activity.
• Football.Fun merges player share trading with NFTs and exposes per-user share holdings and trading activity in football.
• BatBall11 blends fantasy team building with opinion-trading-style markets and holds per-user contest and order data.
• Dream11 is the broader daily fantasy product, with per-user contests, teams and wallet ledger as the integration target.
• PrizePicks holds per-user pick history, wallet balance and settlement data on player-prop entries.
• Underdog Fantasy stores per-user drafts, pick-em entries and the associated wallet ledger.

Questions we get on App Arena

Is the USD balance in App Arena the same money sitting on Solana?

They are linked but not identical. The TradeStars USD balance you see in the app is an internal ledger entry; per the TradeStars FAQ, paid entries are backed by Solana collateral and arena settlement, payout roots and withdrawal requests are written on Solana. An integration that pretends the in-app number and the chain state are the same surface will drift. We model them as two reconciling sources and write the join logic explicitly.

Can the per-entry holdings be pulled if a user holds 10 entries in the same arena?

Yes. Per the arena docs, each entry is its own portfolio with its own 1,000 credits, its own holdings, its own fantasy points and its own leaderboard rank. The integration treats entry_id as the primary key and pulls holdings, trade history and current rank per entry. A user with ten entries in one arena returns ten parallel records, not one merged one.

What happens to the integration when an arena closes and settlement runs?

The arena moves into a review state where results are published, then payouts finalize against Solana settlement records. Credits reset weekly and cannot be withdrawn, so they disappear from the live picture; the surviving artifacts are the final fantasy points, the leaderboard, and the USDC payout into the user's TradeStars USD balance. We pin a snapshot at close so the historical entry is not lost when next week's arena overwrites the screen.

Does an integration here need a Solana wallet of its own?

For read-only mirroring of public settlement and payout-root data, no — a public RPC endpoint reads the chain. For the in-app surfaces (entry list, holdings, USD balance, trade history) the integration uses the user's authenticated session via Privy. Withdrawals and on-chain transfers are a separate concern we scope explicitly with the client, since they cross from read-only mirroring into custody.

A typical build on this app runs to a one-to-two-week cycle. Source-code delivery starts at $300, paid after delivery once the package is running against your account. Where the team would rather not host the integration at all, the alternative is to call our hosted endpoints and pay only for the calls actually made, with no fee up front. The integration desk is at contact; a useful brief names the surfaces you need (entries, holdings, USD ledger, settlement, or a subset) and whether the consumer will be your own users via Privy or an internal aggregate read-only feed.