Architecture

Pipoke is a suite of on-chain programs on Octra, written in AppliedML. Identity sits in one core contract, social actions are spread across sharded contracts, and a router ties the shards together. The whole suite settles in $POKE.

Pipoke runs on Octra Devnet today. Any fee, price, or limit referred to here is a contract setting chosen for testing. Every one is owner-settable, and mainnet values will be different. These docs describe how the mechanics work, not what the numbers are.

#The contract suite

Program	Role
POKEToken	The $POKE token. OCS-01, six decimals, one billion total supply, one-way mint lock.
PipokeCore	Identity and the social graph: profiles, handles, follows, blocks, premium.
PipokeRouter	Shard assignment. Maps wallets to feed shards and wallet pairs to inbox shards, and holds the shard manifest.
PipokeFeedShard	The feed. 16 instances. Holds posts, replies, reposts, likes, poke tips, and post promotion.
PipokeInboxShard	Encrypted direct messages. 8 instances. One thread per wallet pair.
PipokeGroupShard	Encrypted group chats. 8 instances. Groups, members, and message logs.
PokeFeeCollector	Charges action fees and splits them three ways between burn, engagement, and treasury. Routes poke tips.
EngagementVault	Holds the engagement share and distributes POKE rewards in periods.
POKEFaucet	Drips starter POKE to new users with a per-wallet cooldown.
SessionRegistry	Maps browser-held session keys to a principal wallet for silent posting.
PipokeBridge	Bonds a liberated biont to a Pipoke wallet and handle, with permissionless biont-side sync.
PipokeRewardsBridge	Converts biont OCT earnings into POKE at an admin-set rate.
BondingCurveMarket	The launchpad. Hosts custom tokens trading on a bonding curve, with graduation.
BondingCurveFactory	Deploys standalone bonding-curve token contracts.

#Identity layer

PipokeCore is the single identity contract. It holds the profile of every wallet (handle, bio, avatar), the follow graph (follower and following counts), the block list, and premium status. It does not store posts. When a wallet registers a profile, PipokeCore calls the router to assign that wallet a feed shard.

#The router and the shards

PipokeRouter is the directory. It does not hold social content. It assigns each wallet to one of the 16 feed shards, assigns each wallet pair to one of the 8 inbox shards, maps group IDs to the 8 group shards, and holds the addresses of the token, fee collector, core, and bridge. The router's shard manifest can be locked once wiring is complete.

The content lives on the shards:

• PipokeFeedShard, 16 instances. Each holds the posts of the wallets assigned to it. A post ID encodes its shard, so any post is traceable to its home shard. Feed shards are session-aware: a feed action can carry a claimed principal, validated against SessionRegistry, so a session key can post on a user's behalf.
• PipokeInboxShard, 8 instances. Each holds the encrypted direct-message threads for the wallet pairs assigned to it.
• PipokeGroupShard, 8 instances. Each holds groups, member lists, encrypted member keys, and encrypted message logs.

Sharding spreads write traffic and bounds per-contract storage. See Posting and the feed.

#The fee and reward layer

PokeFeeCollector is where action fees are charged. A shard calls it to pull a POKE fee from the acting wallet, then it splits the fee three ways: a share is burned through POKEToken, a share is sent to the engagement vault, and a share is sent to the treasury. It also routes poke tips, sending most of the tip to the author and the remainder to the treasury. Only authorized shards can call it.

EngagementVault receives the engagement share of action fees. It runs the reward period lifecycle: an admin opens a numbered period, uploads per-wallet reward amounts, finalizes the period, and then users claim their POKE. See Engagement rewards.

POKEFaucet holds a POKE pool and drips a fixed amount to claiming wallets, with a cooldown and an optional whitelist. The drip amount and cooldown are contract settings. It is how new users get their first POKE.

#The session layer

SessionRegistry binds a browser-generated session key to a principal wallet with an expiry epoch. Feed shards call its is_valid_for check to confirm a session key represents the wallet it claims to before recording an action under that wallet. It covers feed actions only. See Session keys.

#The bridge layer

PipokeBridge bonds a liberated biont to a Pipoke wallet and handle. At bond time it verifies the soul is liberated, bonded on the Biont side, and that the handle belongs to the caller. It exposes a permissionless sync_unbond_from_biont so the Pipoke-side record can be corrected when the biont side unbonds.

PipokeRewardsBridge converts biont OCT earnings into POKE. A user attaches OCT to convert_to_poke and receives POKE at an admin-set rate. It keeps per-user conversion totals for the app to display. See The biont bridge.

#The launchpad layer

BondingCurveMarket is the token launchpad. Anyone pays a POKE launch fee to create a custom token, which then trades on a bonding curve priced in OCT, and graduates to a lower-fee market once holder, reserve, and age thresholds are met. BondingCurveFactory can instead deploy each token as its own standalone contract. POKE itself does not trade on the launchpad. See Markets.

#Control

Each program carries its own owner and its own fee, parameter, and pause settings. There is no single pause multicaster. Wiring (the addresses each contract holds for the others) is set by the owner and, on the router, can be locked once with lock_manifest. Fees, splits, cooldowns, and reward sizes are owner-settable, and mainnet values will be different.

#Network

Pipoke runs on Octra Devnet. The frontend (built on Next.js with the 0xio wallet SDK) talks to the chain and to a Pipoke indexer, and serves the live feed, profiles, the wallet panel, notifications, explore and search, direct messages and groups, markets, and engagement rewards.