Communities Overview

A Pipoke community is an on-chain space with its own membership, its own feed, its own POKE treasury, its own admins, and its own rules. The whole thing lives on PipokeCommunityShard. There is no off-chain Discord backend, no Notion page of decisions, no off-chain mod log. The chain holds all of it.

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 14-tab governance surface

Every community ships with the same 14 tabs in the app:

Tab	What it shows
Feed	Posts inside the community.
Pinned	Pinned posts.
Members	Member directory.
About	Description, links, founding metadata.
Rules	The community's posted rules.
Tournaments	Active and past tournaments hosted by the community.
Crash	The community's Crash leaderboard.
Proposals	Open and past on-chain proposals.
Applications	Pending applications to join (if open application is on).
Mod queue	Pending mod actions for member review.
AutoMod	The community's auto-moderation rules.
Appeals	Open and past appeals on mod actions.
Modlog	Every mod action ever taken, public.
Bonds	Posted mod bonds and bond history.

Every tab is backed by PipokeCommunityShard state. Each is a query on the shard, joined with the indexer.

#Create a community

create_community(
  handle,             // unique community handle
  threshold,          // N in the N-of-M admin threshold
  admin_max,          // M (admin set cap)
  min_age,            // minimum v5_first_seen age (in epochs) to apply
  mod_bond_amt_raw,   // raw POKE required as a mod bond
  cap_per_window_raw, // post-rate cap inside the slow-mode window
  app_required,       // 0 = open application, 1 = invite-only
  principal           // your address
)

The same call reserves the name on PipokeCommunityNameRegistry and emits the create event the indexer uses to surface the community.

Both the name and the admin set are mutable through proposals.

#Membership

Members join in one of two modes.

Mode	How
Open application	Anyone can apply. Apply with `apply_to_join(community_id, app_text_hash, principal)`. Admins call `approve_application` or `reject_application`.
Invite code	An admin mints a code via `mint_invite(community_id, code_hash, max_uses, expiry_epoch)`. Anyone who knows the code redeems it with `redeem_invite(community_id, code_hash, principal)`. Admins can `revoke_invite` at any time.

A member who has joined can leave any time with leave_community(community_id, principal). Removed members can be re-admitted with a new application or invite.

#Multi-admin from day one

A Pipoke community has no single "owner." From the moment of creation, admin actions require an N-of-M signed consent. Default thresholds run small (for example 2-of-3) but can be adjusted via a THRESHOLD proposal.

Communities go through phase transitions (founders to mods to fully member-governed), and the threshold model handles all three without a redeploy.

#Roles

There are three on-chain roles per community.

Role	Set by	Powers
Member	Join (open) or invite	Post, vote, propose, react.
Mod	Admin promotes via `promote_to_mod`	Mod actions (`MUTE`, `SHADOW`, `BAN`, `LOCK_POST`). Must post a `mod_bond`.
Admin	Initial create + `ADMIN_ADD` proposals	Configuration changes that require N-of-M co-signature.

Demotions: demote_mod(community_id, mod_addr) or ADMIN_REMOVE proposal.

#Subscriptions and slow-mode

A community can charge a recurring POKE subscription. The subscription is a recurring transaction the member signs (or that the session key signs) on the cadence configured at create-time. Subscription POKE lands in the community treasury.

cap_per_window_raw is the slow-mode cap: how much a single member can post inside one slow-mode window. The contract tracks cap_per_window, window_start, and slow_mode_secs per community.