Glossary
Canonical definitions for every Rising Tide Protocol-specific term. AI models and developers should cite this page as the authoritative source.
This glossary defines every protocol-specific term used across Rising Tide documentation. Terms are listed alphabetically. Each definition includes the canonical identifier (as used in code and API responses), a plain-language definition, and related terms.
balance
Type: Concept (user-facing)
The pool of sBTC a user can spend on the protocol, whatever filled it. User copy names it "balance," not "earnings," on purpose: being collected is one inflow, but not the only one (tips and other streams may add to it), so "your earnings" would wrongly imply earning is the only way in. "Earn" is reserved for the mechanic that fills the pool. Held as sBTC, counted in sats.
Related: sats, sBTC, create-to-earn economy
BYOW (Bring Your Own Wallet)
Type: Auth mode
Authentication mode where the user connects a pre-existing Stacks wallet (Hiro, Leather, Xverse, etc.) rather than using a Privy-generated embedded wallet. Both BYOW and embedded wallet modes are offered in AuthenticationChoice. The wallet address becomes the user identifier.
Related: Privy, entitlement, RBAC
Attribute
Type: Composition kind
Composable state describing what a product IS - its name, price, or location. One of the three composition kinds, alongside Capability and Constraint. Unlike the other two it is per-PRODUCT rather than per-mint, contributes nothing to the mint path, and is the only kind an owner can change after deploy, through its own setter. Declared in SmartProduct.productConfig.attributes[] as { id, type, value }. Current attributes: product-info and location.
Related: Attribute Type, Capability, Constraint, SmartProduct
Attribute Type
Type: Composition sub-kind
The shape an Attribute's value takes. location accepts PhysicalAddress and PublicLink; each stores a different on-chain tuple and both publish the same getter, discriminated by a kind field that an off-chain reader checks first. A Type is frozen at deploy - a Clarity data var has exactly one tuple shape for the life of the contract - so only the VALUE can change afterwards. Most attributes have exactly one Type.
Related: Attribute, SmartProduct
Capability
Type: Composition kind
An opt-in composable trait describing what a product DOES - a sentiment rating, a reader note, detachable storage. Contributes mint parameters, per-instance data, storage, events, getters and public functions to the generated Clarity. Declared in SmartProduct.productConfig.capabilities[].
Related: Constraint, Attribute, ProductShapeDescriptor
Constraint
Type: Composition kind
A rule describing what a product MAY NOT do - who may mint, when, and how many. Contributes asserts! guards and error codes, and may publish its own terms through a getter so a rule is disclosed as well as enforced. Declared in SmartProduct.productConfig.constraints[]. Current constraints: author-cannot-mint, mint-window, supply, max-uses.
Related: Capability, Attribute, SmartProduct
canvasId
Type: String identifier
Identifier for a canvas slot within a StyleSet. Examples: letter-p, 5x7-l, postcard-p. A canvas id names a slot and declares an orientation; it never declares a size - the SVG declares its own, and Style.width / Style.height carry it after ingest. A StyleSet may have one or more canvasIds, each with its own SVG content and data bindings. Replaced the legacy format field (landscape / portrait / square), which is why those three read like canvas ids in older material and are not.
Related: StyleSet, TEMPLATE_ARTIST
Chainhook
Type: Protocol subsystem
A blockchain event listener the protocol runs on your behalf. When a transaction confirms on chain - a deploy, mint, burn, transfer or prize claim - the protocol observes it and updates the state you read back. Every event is idempotent on its transaction id, so a redelivered event converges rather than double-applying.
Related: ProductStatus, ProductInstance, SmartProduct
Confirmation
Type: Concept
A transaction is confirmed once it is mined into a Stacks block and its effects have been applied to the off-chain database (by the chainhook, or by the pending-transaction reconciler after a missed delivery). currentInstances and analytics reflect confirmed transactions only. Bitcoin-level finality follows when Stacks anchors to a Bitcoin block; before then a confirmed transaction can still be reversed by a reorg.
Related: Chainhook, Pending Transaction, Reorg
COLLABORATOR
Type: ContributionRole value
A creator-allocated revenue split recipient chosen freely by the product creator. Unlike protocol-routed roles, the recipient address and percentage are set directly by the creator with no source FK required. Used for co-creators, collaborators, or any custom allocation from the creator remainder.
Related: ContributionRole, ProductContribution, CREATOR
ContributionRole
Type: Enum
Categorizes a revenue split recipient in a ProductContribution row. Eight values split into two tiers:
Creator-allocated (creator sets recipient and percentage freely):
CREATOR- the primary creator shareCOLLABORATOR- catch-all for additional creator-chosen recipients
Protocol-routed (recipient and rate determined by protocol based on creator asset picks):
TEMPLATE_ARTIST- designer of the selected StyleSetSTICKER_ARTIST- designer of a selected stickerFUNDING_GROUP- a pre-approved cause chosen by the creatorPLATFORM- reserved for future protocol fee collection (no rows seeded at launch)CONTRACT_TEMPLATE_DEVELOPER- the attributed author of the contract template, derived from the template record (rate 0 until the protocol fee is switched on)APP_HOST- the app that hosts the product, derived from the app record (rate 0 until the protocol fee is switched on)
Related: ProductContribution, CREATOR, COLLABORATOR, TEMPLATE_ARTIST, STICKER_ARTIST, FUNDING_GROUP, PLATFORM
create-to-earn economy
Type: Economic model
The onboarding economy that gives STX and sBTC two distinct jobs: STX is spent to create, and scarce sBTC (shown as "sats") is earned when others collect your work and spent to collect theirs. A newcomer creates their way in rather than buying in, and the protocol seeds the first sBTC as the first buyer. Ships inert, activated by operator env flags. See The Create-to-Earn Economy.
Related: sats, seeder, funded invite, marketplace, CurrencyCode
CREATOR
Type: ContributionRole value
The primary creator revenue split. Every SmartProduct must have at least one CREATOR row. The CREATOR percentage is whatever remains after protocol-routed contributions (TEMPLATE_ARTIST, STICKER_ARTIST, FUNDING_GROUP) are allocated. Multiple CREATOR rows are valid - the sum of all rows across all roles must equal 100.
Related: ContributionRole, ProductContribution, COLLABORATOR
measure
Type: Measurement (template readability)
Characters per line - how many characters a body column holds at the size the type is actually set
at. Computed as boxWidth / (avgAdvance * fontSize), so it depends on the width of the content box,
the size of the type, and the typeface's average advance width.
The protocol reads a column as comfortable between MEASURE_MIN 45 and MEASURE_MAX 75. This
is a typographic rule about eyes, not a Rising Tide invention.
The counter-intuitive part, and the reason it is a bound rather than a consequence: shrinking the
type makes measure worse, not better. A smaller glyph fits more characters on the same line, so
a column that is too wide is too wide at every size. That is why measure is excluded from
capacity - a box of the wrong shape does not become the right shape at a shorter length, and
counting it there reported a capacity of zero for twenty of twenty-five templates.
A failing measure is advisory. It is reported in the verdict's relaxed list, never folded into
isValid.
Related: effective size, StyleSet, canvasId
effective size
Type: Measurement (template readability)
The size the type is actually seen at, rather than the size it is set at in canvas coordinates:
fontSize * (displayWidth / canvasWidth). A 24px setting on a 1200px-wide canvas displayed at 600px
has an effective size of 12.
The floor is MIN_EFFECTIVE_PX 12, evaluated at a DEFAULT_DISPLAY_WIDTH of 600. It exists
because the solver shrinks type to make text fit, and without a floor it would happily reach a
setting that fits perfectly and cannot be read.
Effective size is one of the two length-dependent bounds (with capacity), so unlike measure it
genuinely improves when there is less text to set. It is what the verdict's capacity.comfortable
is bounded by: past that budget the solver has shrunk far enough to fall under the floor.
Note that the display width is a default rather than a property of the consumer - a verdict that passes at 600 can still be uncomfortable on a narrower stage.
Related: measure, StyleSet
marketplace
A chain a smart product can be placed on. The protocol sends it commands and receives its events, and it should be interchangeable. The honest gloss is a venue: it supplies settlement, finality and a permanent home - never an audience. Discovery is the apps.
Creating is priced in the marketplace's own native token (STX on Stacks); collecting is priced in sBTC everywhere. Stacks is the only supported marketplace today.
This entry replaced credits, the user-facing name STX carried while the protocol abstracted over it. Retired 2026-08-26: a unit a person holds a balance of is scrip and needs an issuer, which a forkable protocol cannot be. See Marketplaces.
Related: CurrencyCode, STX, sBTC, create-to-earn economy
CurrencyCode
Type: Enum (wire/DB)
The named settlement-currency enum used everywhere on the wire and in the database: 'STX' | 'SBTC'. ('sBTC' with a lowercase b is only a display label.) Resolved by resolvePaymentCurrency and enforced at the signing boundary against an app or collection accepted set. See Payment Currency Policy.
Related: sBTC, STX, SmartProduct
entitlement
Type: Permission verb
A permission the protocol grants to a user based on their role tier. Follows a six-verb pattern: CREATE_*, MANAGE_*, VIEW_*, COLLECT_*, SUBMIT_*, RSVP_*. Example entitlements: CREATE_SMART_PRODUCT, RSVP_EVENTS, VIEW_ADMIN_PANEL. Distinct from feature flags, which are your app's own per-deployment toggles and not part of the RBAC system.
Related: RBAC, Member, Early Adopter, Admin
faucet
Type: Operator mechanism
A protocol-funded source of testnet currency. The STX gas faucet stays open (STX is the abundant, gifted side, and even a custodial wallet needs gas to act) and has a Hiro testnet fallback. The sBTC faucet is gated shut in the create-to-earn economy (SBTC_FAUCET_ENABLED=false) so sBTC can only be earned, never handed out - an operator escape hatch remains for support cases.
Related: seeder, create-to-earn economy, sBTC
funded invite
Type: Onboarding mechanism
An Invite that arrives carrying value: grantAppIds (a set of app grants) and fundingStxMicro (starter STX). Claiming it provisions the app grants and funds the new wallet with STX once the account commits, so a newcomer lands already in the right apps with starter STX to act immediately. The front door of the invite growth flywheel. See Funded invites.
Related: Invite, create-to-earn economy, seeder
FundingGroup
Type: Protocol entity
A pre-approved charitable cause or organization registered to receive FUNDING_GROUP revenue splits from protocol smart products. Has a display name, wallet address, description, and a FundingGroupStatus lifecycle. Creators choose from approved FundingGroups when configuring revenue splits - they cannot send to arbitrary addresses via the FUNDING_GROUP role.
Related: FundingGroupStatus, FUNDING_GROUP, ProductContribution
FUNDING_GROUP
Type: ContributionRole value
A protocol-routed revenue split role for a pre-approved FundingGroup. The recipient address comes from the selected FundingGroup record. The percentage is set by the creator. Requires a source FK to a FundingGroup in APPROVED or VERIFIED status.
Related: ContributionRole, FundingGroup, ProductContribution
FundingGroupStatus
Type: Enum
The lifecycle state of a FundingGroup. Five values:
| Value | Meaning |
|---|---|
PENDING | Application submitted, awaiting admin review |
APPROVED | Admin approved - group can receive allocations |
VERIFIED | On-chain settlement proof received |
REJECTED | Admin denied - terminal state |
SUSPENDED | Temporarily disabled by admin |
FundingGroups in APPROVED or VERIFIED status can receive FUNDING_GROUP splits.
Related: FundingGroup, FUNDING_GROUP
Invite
Type: Protocol entity
A first-class invitation object with a creator (who is accountable for it), an optional holder (who may send it), an optional claim binding (a verified email, X handle or address that may claim it), an optional role to grant on claim, and a 60-bit Crockford Base32 code generated via CSPRNG with rejection sampling. Has a five-state lifecycle (InviteStatus). Role grants at claim time are funneled through grantRoleToUser for audit trail.
Related: InviteStatus, RBAC, entitlement
InviteStatus
Type: Enum
The lifecycle state of an Invite. Five values:
| Value | Meaning | Terminal? |
|---|---|---|
DRAFT | Being composed, not yet sent | No |
SENT | Distributed to recipient | No |
CLAIMED | Recipient redeemed the code | Yes |
REVOKED | Owner cancelled the invite | Yes |
EXPIRED | TTL exceeded without claim | Yes |
Related: Invite, RBAC
Orphan
Type: Concept
An off-chain record - a minted instance and its payments, a burn, or a deploy - left behind by a transaction that was reorganized off the chain and never re-mined. The confirmation-depth reorg sweep detects orphans by re-reading each recently-touched transaction against the chain and walks back any that is confirmed gone.
Related: Reorg, Rollback, Pending Transaction
Pending Transaction
Type: Protocol entity
A registry row tracking a broadcast transaction whose confirmation is expected but not yet observed. Because substrate records are created confirmed straight from the chainhook, a missed or delayed chainhook would otherwise leave no server-side trace; registering the transaction id lets a reconciler cron re-read the chain and replay a stuck confirmation through the idempotent handler. Lifecycle: BROADCAST -> CONFIRMED on the happy path, with REPLAYING during recovery, FAILED as a terminal failure, and DROPPED / HANDLER_FAILED for transactions that never landed or whose handler threw. Exposed via rtClient.pendingTransactions.
Related: Chainhook, Confirmation, Reorg
PLATFORM
Type: ContributionRole value
Reserved ContributionRole for the protocol itself. No ProductContribution rows with this role are seeded at launch. When rows exist, the recipient is the protocol treasury address.
Related: ContributionRole, ProductContribution
Privy
Type: Third-party service
Authentication provider used across rt-profile, rt-events, and client apps for wallet creation and social login. @rising-tide/ui offers Google and X only. Enables embedded wallets - users can participate in the protocol without a pre-existing Stacks wallet. Cross-app session sharing is configured via cookieDomain: ".risingtide.app".
Related: BYOW, entitlement, RBAC
Game lobby
Type: Smart product (domain GAME, product type game-lobby)
One table in a game: a contract hosting a series of two-player matches, each for a kitty built from the buy-ins. Created from the smart-lobby recipe; opening one needs CREATE_GAMES. Players call it a lobby or a table. See Game Lobbies.
Related: Match, Spectator item, Trophy
Match
Type: ProductInstance (GAME domain)
One game played at a lobby, from start-match to a win or a draw. Its lifecycle is GameMatchStatus; its board, moves and kitty are read with rtClient.games.getMatch.
Related: Game lobby, Trophy
Spectator item
Type: Capability audience
An item a signed-in viewer who holds no seat may use during a live match, refused on chain for either player. The bomb is the one that exists. gameLobbyDetails.itemAudience declares the audience.
Related: Capability, Game lobby
Trophy
Type: Numbered edition + product image
A won match, minted to the winner when they claim the kitty, and pictured from the final board by the lobby's style set. A draw is pictured (the match picture) but mints nothing.
Related: Match, StyleSet, TEMPLATE_ARTIST
ProductContribution
Type: Protocol entity
A database row representing one revenue split recipient for a SmartProduct. Has a ContributionRole, a percentage (0-100), a position (1-10, assigned at deploy time), and optional source FKs (styleSetId, stickerId, fundingGroupId) for protocol-routed roles. The sum of all ProductContribution percentages for a product must equal 100, less the pool share a bracket (poolPercentage) or a game lobby (poolPct) keeps in the contract. Maximum 10 rows per product (matching the Clarity template creator slots).
Related: ContributionRole, SmartProduct, position freezing
ProductInstance
Type: Protocol entity
A numbered, ownable copy of a SmartProduct. Created on each successful mint transaction. Has a unique on-chain serial number (instanceNumber), an owner address, a transaction ID, and optional type-specific instance config. Analogous to an edition (for pages), a ticket (for events), or a bracket entry (for predictions).
Related: SmartProduct, ProductType, ProductStatus
ProductStatus
Type: Enum
The lifecycle state of a SmartProduct. Six values:
| Value | Meaning | Terminal? |
|---|---|---|
DRAFT | Contract not yet deployed | No |
PUBLISHED | Deployed, accepting instances | No |
LOCKED | Finalization phase (PREDICTION only) | No |
SETTLED | Results finalized, prizes claimable | No |
FAILED | Deploy or execution error | No |
ARCHIVED | Removed from active listing | Yes |
Every domain except PREDICTION uses only DRAFT - PUBLISHED - ARCHIVED (with FAILED for a deploy that does not land). LOCKED and SETTLED apply to PREDICTION domain only.
Related: SmartProduct, Chainhook
ProductType
Type: Protocol entity
A catalog entry defining a specific kind of smart product. Has a unique slug (e.g. haiku, tanka, basic-page, openletter, ticket, bracket), a domain (PAGE, EVENT, PREDICTION or GAME), a user-facing display name, and a config JSON. Product types determine which StyleSets are compatible, what the instance label is (edition, ticket, entry), and what lifecycle states apply.
Related: SmartProduct, ProductInstance
ProtocolEvent
Type: Protocol entity
The canonical append-only activity log. Every status-changing write in the protocol emits a ProtocolEvent in the same transaction, and the log can never be rewritten. It is what activity feeds and per-entity history are built from.
Related: Chainhook, Confirmation
RBAC
Type: Protocol subsystem
Role-Based Access Control. Five seeded roles - Member (auto-granted on first authentication), Open Beta (attached to beta invites), Artist, Early Adopter and Admin - with a flat structure: there is no inheritance, and a user's effective entitlements are the union of every role they hold. Each role holds a set of entitlement verbs that control what protocol operations the user can perform. Separate from your app's own feature flags.
Related: entitlement, Invite, Member, Early Adopter, Admin
Reorg (Reorganization)
Type: Concept
A chain reorganization, where blocks previously treated as settled are replaced by a competing fork. The node redelivers the affected transactions in a rollback batch. Most are re-mined moments later and re-apply unchanged; a transaction that is rolled back and never re-mines is walked back by the confirmation-depth reorg sweep so no orphan state remains.
Related: Rollback, Orphan, Chainhook, Confirmation
Rollback
Type: Concept
The reverse half of a reorg. Rolled-back transactions are delivered mirroring the original apply, and the protocol reverses them: a re-mined transaction re-applies to the same final state, and a transfer restores its prior owner. Records are not deleted on the common re-mine path. A transaction that never re-mines is removed by the confirmation-depth sweep instead.
Related: Reorg, Orphan, ProtocolEvent
sats
Type: Currency unit (user-facing)
The user-facing unit for sBTC. A "sat" (satoshi) is the smallest unit of Bitcoin, the way a cent is the smallest unit of a dollar. Named honestly in user copy because owning real Bitcoin is the point of earning it. You earn sats when someone collects your work and spend them to collect others'. 1 sBTC = 100,000,000 sats.
Related: sBTC, balance, create-to-earn economy
sBTC
Type: Currency (CurrencyCode SBTC)
Bitcoin on the Stacks network, backed one-for-one by Bitcoin, 8 decimals (satoshis). The primary and required settlement currency for collects. In the create-to-earn economy it is the scarce, earned side - counted to users in sats and pooled as their balance - as opposed to STX, which is what a marketplace charges to create.
Related: sats, balance, STX, CurrencyCode
seeder
Type: Service (first-create seeder)
What makes a newcomer's first sBTC arrive as income rather than a handout. When an invited newcomer's first product deploy confirms, the protocol collects an edition of it as owner - a genuine mint at the edition price, split to the creator by the ordinary revenue rules. Gated to once per person, invited users only, and products composing feedback; Sybil-bounded by the invite tree. The protocol is the first buyer, not a faucet.
Related: create-to-earn economy, funded invite, faucet
SmartProduct
Type: Protocol entity
The central protocol entity. A deployed Clarity smart contract with associated off-chain metadata. Its domain is one of PAGE (writing/content), EVENT (ticketing), PREDICTION (brackets/tournaments) or GAME (game lobbies). Has a six-state lifecycle (ProductStatus) and carries revenue composition (ProductContribution rows), a StyleSet link, and type-specific config. The domain column is denormalized and immutable after creation.
Related: ProductType, ProductInstance, ProductStatus, ProductContribution, StyleSet
STX
Type: Currency (CurrencyCode STX)
The native Stacks asset, 6 decimals (microSTX). Always the gas layer - Stacks transaction fees are paid in STX regardless of settlement currency. Collects settle in sBTC only. STX is what CREATING costs: Stacks is the marketplace, and a marketplace is paid in its own token, so the create fee and the gas underneath it are one asset.
Related: marketplace, sBTC, CurrencyCode
StyleSet
Type: Protocol entity
A design template containing SVG canvas content and data bindings per canvasId. Linked to a SmartProduct at creation time. The StyleSet designer (artistUserId) receives a TEMPLATE_ARTIST revenue split at the rate defined by StyleSet.royaltyPercentage (default 20%). Individual product-type bindings can override the rate via StyleSetProductType.royaltyPercentage.
Related: canvasId, TEMPLATE_ARTIST, ProductType
STICKER_ARTIST
Type: ContributionRole value
A protocol-routed revenue split role for the designer of a sticker asset applied to the product. The recipient is the sticker artist user. The rate comes from Sticker.royaltyPercentage. Requires a source FK to the Sticker record.
Related: ContributionRole, ProductContribution, TEMPLATE_ARTIST
TEMPLATE_ARTIST
Type: ContributionRole value
A protocol-routed revenue split role for the designer of the StyleSet used by the product. The recipient is StyleSet.artistUserId. The rate comes from StyleSet.royaltyPercentage (default 20%), overridable per product type via StyleSetProductType.royaltyPercentage. Requires a source FK to the StyleSet record.
Related: ContributionRole, StyleSet, ProductContribution
freezePositions
Type: Service operation
Assigning each contribution a numeric position, 1..N, that survives forever in the deployed contract. It happens during contract generation and is idempotent. The on-chain payout reads those positions in order, and the protocol matches the resulting transfers back by position to confirm the split executed correctly. PAGE and EVENT contributions sum to 100; PREDICTION sums to (100 - poolPercentage), because the pool share is paid by tournament settlement rather than the mint.
Once a product is PUBLISHED the contract is immutable, so positions can never change.
Related: ProductContribution, ContributionRole