# Eligible activity (/docs/activity-rewards/eligible-activity) Activity Rewards are for contributions that can be connected to real trading activity. Eligible activity can include things such as: * **Calls** that other users discover and trade from * **Thesis** that help another user understand a market and lead to a trade * **Eligible shared trading activity** that other users discover and act on * **Assigned Tribe activity** where the contribution can be attributed to subsequent trading * **Other attributable contributions** that meet the requirements for Activity Rewards The important part is not the format of the contribution. It is whether that contribution can be meaningfully connected to real trading activity. ## What does not automatically count [#what-does-not-automatically-count] Not every useful action generates an Activity Reward. Activity may be ineligible when: * there is no clear attribution between the contribution and the trade * the contribution did not lead to eligible trading activity * the activity was created primarily to manufacture rewards * the activity fails integrity or eligibility checks Useful contributions that do not generate Activity Rewards may still contribute to XP and reputation. See [XP and levels](/docs/reputation/xp-and-levels) and [Integrity and abuse prevention](/docs/activity-rewards/integrity-and-abuse-prevention). ## Eligibility and attribution [#eligibility-and-attribution] Being eligible does not guarantee a reward. The contribution still needs to meet the attribution and integrity requirements before any reward can become available. See [How attribution works](/docs/activity-rewards/how-attribution-works). List of eligible activity, minimum requirements, attribution rules and any activity-specific conditions. See [What is not final yet](/docs/getting-started/not-yet-final). # How attribution works (/docs/activity-rewards/how-attribution-works) Attribution connects a contribution to the trading activity it helped create. An Activity Reward can only be generated when that connection is clear enough to verify. ## The basic flow [#the-basic-flow] 1. You create eligible activity, such as a Call, thesis or other attributable contribution. 2. Another user discovers or engages with that activity. 3. They go on to trade the relevant market. 4. That trade generates eligible fees. 5. If the contribution can be attributed to that trade, part of those fees may become an Activity Reward. See [Fees](/docs/trading/fees). ## What attribution is trying to measure [#what-attribution-is-trying-to-measure] Attribution is not about rewarding every post that happened before a trade. It is about identifying the contribution that meaningfully helped create the activity. For example, someone might open a Call from a notification, review the setup and trade directly from it. That creates a much clearer attribution path than a random message that happened to mention the same token hours earlier. ## Why attribution has to be strict [#why-attribution-has-to-be-strict] Loose attribution rewards noise. If every nearby post, message or market mention could earn a share, the incentive would be to create more activity rather than better activity. Activity Rewards are designed to reward contributions that can be connected to real trading behaviour. ## More than one contributor [#more-than-one-contributor] A trade can sometimes have more than one relevant touchpoint. Someone might first discover a market through one person, later read a thesis from another and finally trade from a Call inside a Tribe. How credit is handled in cases like this depends on the attribution model. Attribution model, including attribution windows, qualifying interactions, how multiple contributors are handled and how fee shares are calculated. See [What is not final yet](/docs/getting-started/not-yet-final). # Activity Rewards (/docs/activity-rewards) Activity Rewards are designed to reward useful contributions that lead to real trading activity on Tribes. If someone discovers a market through your eligible Call, thesis or other attributable activity and then trades from it, you may receive a share of the fees generated by that activity. The idea is simple: **Create value. Create activity. Get rewarded for it.** ## How it works [#how-it-works] Activity Rewards connect useful contributions to the trading activity they help create. For example: * you post a Call and another member trades from it * you share a thesis that leads someone into a market * you create eligible market activity that another user discovers and acts on When that activity can be attributed, part of the value it generates can be returned to the contributor. See [How attribution works](/docs/activity-rewards/how-attribution-works). ## What can be eligible [#what-can-be-eligible] Eligible activity can include things such as: * Calls * thesis * eligible shared trading activity * other attributable contributions Not every post, message or action automatically earns rewards. See [Eligible activity](/docs/activity-rewards/eligible-activity). ## Activity Rewards and XP [#activity-rewards-and-xp] Activity Rewards and XP recognise different things. **Activity Rewards** are tied to eligible contributions that can be attributed to real trading activity. **XP** recognises participation and contribution more broadly, even when no trade follows. A contribution can therefore be useful enough to earn XP without generating an Activity Reward. See [XP and levels](/docs/reputation/xp-and-levels). ## Reward states [#reward-states] An Activity Reward can move through different states: * **Pending** * **Verified** * **Available** * **Voided** See [Reward states](/docs/activity-rewards/reward-states). ## Integrity [#integrity] Activity Rewards are based on attributable activity, so abuse prevention is part of the system from the start. Protections can address behaviour such as fake referrals, self-trading, circular activity, coordinated accounts and other attempts to manufacture rewards. See [Integrity and abuse prevention](/docs/activity-rewards/integrity-and-abuse-prevention). ## Reward economics [#reward-economics] Attribution model, reward percentages, eligibility rules and economics of Activity Rewards. See [What is not final yet](/docs/getting-started/not-yet-final). # Integrity and abuse prevention (/docs/activity-rewards/integrity-and-abuse-prevention) Activity Rewards are designed around real, attributable trading activity. Any system that rewards activity can be abused, so integrity checks are part of the reward process from the start. ## Principles [#principles] * **Rewards follow real activity.** A reward should come from eligible trading activity that generated real value. * **Checks come before availability.** Rewards can remain pending until the underlying activity and attribution have passed the required checks. * **Invalid rewards are voided.** Rewards based on fraudulent, manipulated or otherwise ineligible activity can be cancelled. * **Attribution must hold.** If the connection between a contribution and the resulting trade cannot be verified, the reward may not qualify. * **Records are corrected, not polished.** Invalid activity can also be excluded from verified history where appropriate. See [Reward states](/docs/activity-rewards/reward-states) and [Integrity](/docs/security-and-trust/integrity). ## Examples of abuse [#examples-of-abuse] Activity Rewards are designed to resist behaviour such as: * self-trading used to manufacture rewards * circular activity between coordinated accounts * fake or manipulated referrals * very small trades created only to trigger rewards * coordinated accounts designed to inflate attribution * fabricated or spammed Calls and Thesis * repeated activity intended to game reward rules The exact systems used to detect and review this behaviour are not published. ## What happens to invalid activity [#what-happens-to-invalid-activity] If activity fails integrity or eligibility checks, the associated reward can be voided. Where relevant, invalid activity can also be removed from verified records or excluded from reputation and performance systems. Additional enforcement rules, penalties and review procedures. See [What is not final yet](/docs/getting-started/not-yet-final). # Reward states (/docs/activity-rewards/reward-states) Activity Rewards move through different states so rewards are not made available before the underlying activity and attribution have been checked. The activity has been recorded and attribution has been identified, but the reward is still being reviewed. The underlying activity and attribution have passed the required integrity checks. The reward is ready to be credited or claimed, depending on how rewards are delivered. The reward will not be paid because the activity or attribution was found to be invalid, manipulated, fraudulent or otherwise ineligible. ## Why states exist [#why-states-exist] Activity Rewards are based on real attributable activity. The review process helps prevent rewards from being paid for activity that was manufactured, incorrectly attributed or otherwise ineligible. A reward can therefore appear before it becomes available. Review periods, how Available rewards are credited or claimed, and whether additional reward states are used. See [What is not final yet](/docs/getting-started/not-yet-final). # Calls (/docs/core-concepts/calls) A Call is a trade idea shared with a Tribe. It turns a market view into something members can quickly understand and decide whether they want to trade. A Call can be simple or detailed, but the goal is the same: show the setup clearly enough for the Tribe to follow it together. ## What a Call can include [#what-a-call-can-include] A Call can include: * **Asset**: the market the Call is about * **Entry**: where the caller sees the trade * **Target**: where they expect the market to move * **Stop**: where the idea no longer makes sense * **Direction**: long, short, buy or sell * **Thesis or context**: why the caller sees an opportunity * **Time horizon**: how long the idea is expected to play out Not every Call needs every field. Some Calls are quick setups with an entry and target. Others include more context and a complete trade plan. ## Receiving a Call [#receiving-a-call] When a Call is posted, members can see it inside the Tribe and can receive a notification on their phone. Tapping the notification takes them directly to the Call and the market behind it. From there, they can: * inspect the market * view the setup * read the context * join the discussion * follow the Call * decide whether to open their own trade This means a member does not need to already be active in the app when an opportunity appears. ## Joining a Call [#joining-a-call] Members who want to trade the Call open their own position. Each member chooses their own entry, position size and exit. As members join, the Call can show how the Tribe is participating in the trade, including information such as: * members joined * member entries * average Tribe entry * members still holding * exits * Tribe performance Different members can join at different prices and leave at different times. The positions remain individual, while the Call becomes a shared view of how the Tribe is trading that market. ## From Call to Tribe Trade [#from-call-to-tribe-trade] When members assign their trades to the Tribe, that activity can become part of a [Tribe Trade](/docs/core-concepts/tribe-trades). The Tribe Trade brings the individually controlled positions together into one shared view of the market, while each member continues to control their own trade. ## Calls and reputation [#calls-and-reputation] Calls can become part of a person's and Tribe's record over time. When a Call and its outcome can be attributed to real trading activity, it can contribute to verified history, performance and reputation. Wins stay part of the record. Losses do too. See [Calls and performance](/docs/reputation/calls-and-performance) and [Verified history](/docs/reputation/verified-history). A Call is a trade idea shared by a user. It can be wrong and should not be treated as financial advice. # Core concepts (/docs/core-concepts) Six concepts carry most of the Tribes experience. Understand these and the rest of the product becomes much easier to follow. A trading community built around people following, discussing and trading markets together. A token, ticker, contract or market shared with a Tribe so members can inspect it, discuss it and decide what to do next. A structured market idea that can include the asset, direction, thesis, entry, target, stop and time horizon. Shared trading activity around one market inside a Tribe, made up of individually controlled positions assigned to that Tribe. A person's identity on Tribes, including their activity, Tribes, trading history, reputation and verified performance. Trading on Tribes is social. Positions, trades, Calls, history and Tribe activity can become part of the shared experience and help build a public record over time. These concepts connect in different ways. A market might start as a Scan, become a discussion and later turn into a Call. Someone might instead discover a market elsewhere, trade it directly and assign that trade to a Tribe. Calls, trades and other attributable activity can then contribute to Tribe Trades, shared statistics, verified history and reputation. There is no single required path through Tribes. # Profiles (/docs/core-concepts/profiles) Your profile is your identity on Tribes. It brings together who you are, the Tribes you are part of, the markets you trade and the record you build over time. A profile can show things such as: * current positions * recent trading activity * trading history * Calls * verified performance * Tribe memberships * followers and friends * reputation, XP and leaderboard position ## A record built from activity [#a-record-built-from-activity] Profiles are designed around real activity. As you trade, share Calls, participate in Tribes and build a history, your profile becomes a record of what you have actually done on the platform. That gives other people a way to understand how you trade, what markets you follow and how you have performed over time. ## Public trading activity [#public-trading-activity] Trading on Tribes is social. Positions, trades, Calls, history and Tribe memberships can be visible to other users and can appear across profiles, Tribe activity, token pages and leaderboards. See [Public trading activity](/docs/core-concepts/public-trading-activity). ## Verified performance [#verified-performance] Performance marked as verified is based on attributable trading activity and integrity checks rather than screenshots or self-reported claims. Verified does not mean profitable. A verified result can be a win or a loss. See [Verified by Tribes](/docs/reputation/verified-by-tribes). ## Social identity [#social-identity] Profiles also connect the social side of Tribes. You can follow traders, build mutual friendships, see which Tribes people are part of and discover people through their activity and performance. Over time, a profile becomes both a social identity and a trading record. Profile controls and visibility settings. See [What is not final yet](/docs/getting-started/not-yet-final). # Public trading activity (/docs/core-concepts/public-trading-activity) Trading on Tribes is social. Your positions, trades, Calls, trading history and Tribe memberships can be visible to other users. The same is true for the people you follow, trade with and discover across the platform. That visibility turns trading activity into something people can follow, discuss and build reputation from over time. ## What can be visible [#what-can-be-visible] Public trading activity can include things such as: * open positions * recent trades * Calls * trading history * verified performance * Tribe memberships * activity assigned to a Tribe This activity can appear across profiles, Tribe activity, token pages and leaderboards. ## Why trading activity is social [#why-trading-activity-is-social] Public activity is part of how Tribes works. * **People can see what is happening.** Traders and Tribes build a record through real activity rather than screenshots or claims. * **Tribes get shared context.** Members can follow how people are trading the same market while it is happening. * **Reputation becomes meaningful.** Performance and history can be connected to attributable activity over time. * **Contribution can be attributed.** [Activity Rewards](/docs/activity-rewards) can connect eligible Calls, ideas and other activity to the trading activity they help create. ## Visibility and control [#visibility-and-control] Seeing someone's trading activity does not give you control over it. Every user manages their own wallet and positions. Public activity lets people follow what happened, not act on someone else's behalf. **Your trades are visible. Your decisions stay yours.** Visibility controls available for different types of activity. See [What is not final yet](/docs/getting-started/not-yet-final). # Scans (/docs/core-concepts/scans) A Scan is a quick way to bring a market into a Tribe. A member can share: * a token * a ticker * a contract address * a market Tribes then brings the available market information into the conversation so the Tribe can inspect it together. A Scan is simply a way of saying: **look at this.** ## What happens after a Scan [#what-happens-after-a-scan] Members can look at the market, review the available data and discuss what they are seeing in chat or voice. A Scan does not need a direction, entry, target or trade plan. It can simply be something worth looking at. From there, members can keep watching, discuss it further, trade it themselves or turn the idea into a [Call](/docs/core-concepts/calls). ## From Scan to Call [#from-scan-to-call] A Scan and a Call serve different purposes. A Scan brings a market to the Tribe. A Call turns a market into a specific trade idea. For example, someone might share a contract address so the Tribe can inspect the token. If a member later sees a clear opportunity, they can create a Call with an entry, target, stop and additional context. A Scan can lead to a Call, but it does not have to. ## Why Scans matter [#why-scans-matter] Scans make market discovery fast and social. Instead of sending a contract address somewhere else and switching between apps to understand what it is, members can bring the market directly into the Tribe and look at it together. ## Sharing a Scan is not a recommendation [#sharing-a-scan-is-not-a-recommendation] Sharing a token, ticker, contract address or market does not automatically mean the person sharing it is recommending a trade. Nothing on Tribes is financial advice. See [Trading risk](/docs/security-and-trust/trading-risk). # Tribe Trades (/docs/core-concepts/tribe-trades) A Tribe Trade is the shared view of how members of one Tribe are trading the same market. It is composed of the individual positions that members have assigned to that Tribe, so everyone can see how the group is participating in the same market over time. Every member trades from their own non-custodial wallet. There is no pooled Tribe position: each member still has their own position, their own entry, their own size and their own exit. ## Where a Tribe Trade comes from [#where-a-tribe-trade-comes-from] A Tribe Trade can start in different ways. It can begin with: * a [Call](/docs/core-concepts/calls) that members decide to trade * members independently trading the same market and assigning those trades to the Tribe The important part is not where the trade started, but that members are trading the same market and have assigned those trades to the same Tribe. ## What members can see [#what-members-can-see] As members join and manage their positions, the Tribe Trade can show shared activity such as: * members participating * individual entries * average Tribe entry * members still holding * exits * individual results * combined Tribe performance This gives the Tribe one place to follow how the group is trading the market while it is live. ## Individual positions, shared performance [#individual-positions-shared-performance] Members can: * enter at different prices * use different position sizes * use different leverage where the market allows it * take profit at different moments * exit at different times One member exiting does not end the Tribe Trade while other members remain in the position. The positions remain separate, but their results can be combined to show how the Tribe performed as a group. ## Tribe history [#tribe-history] Once a Tribe Trade is complete, its results can become part of the Tribe's trading history and performance record. Only trades that members assign to the Tribe contribute to that Tribe Trade and its statistics. See [Assigning a trade to a Tribe](/docs/trading/assigning-a-trade-to-a-tribe) and [Verified history](/docs/reputation/verified-history). The exact statistics, calculations and presentation used inside Tribe Trades. See [What is not final yet](/docs/getting-started/not-yet-final). # Tribes (/docs/core-concepts/tribes) A Tribe is a trading community inside Tribes. It is a place where people follow markets together, share what they are seeing, talk in chat or voice, post Calls, trade and build a shared history over time. A Tribe can be: * a group of friends * a public community * a competitive team * a creator-led community You can join people you already know or discover Tribes built around the markets, traders and communities you are interested in. ## What happens inside a Tribe [#what-happens-inside-a-tribe] Members can: * discover and share markets * post tokens, tickers and Scans * discuss ideas in chat or voice * create and receive Calls * receive notifications when new Calls are posted * open their own trades * assign trades to the Tribe * follow live Tribe activity * see how members are positioned around a market * build shared statistics and trading history * compete together in Tribe Battles A Tribe can stay active around a market from the first idea through to the final result. Someone might share a token, the group might discuss it, another member might turn the idea into a Call, and different members can then decide whether and how they want to trade it. ## Trading with a Tribe [#trading-with-a-tribe] Every member trades from their own wallet and controls their own positions. When you open a trade, you can assign it to one Tribe. That trade then becomes part of that Tribe's activity, statistics and trading history. Members can have different entries, position sizes and exits. Their positions stay separate, but the results of trades assigned to the Tribe are brought together in a [Tribe Trade](/docs/core-concepts/tribe-trades) to show how the Tribe is performing as a group. A trade that is not assigned to a Tribe remains part of your personal trading activity only. Assigning a trade to a Tribe does not combine wallets or positions. It connects the result of your individual trade to that Tribe. See [Assigning a trade to a Tribe](/docs/trading/assigning-a-trade-to-a-tribe). ## Building a history together [#building-a-history-together] A Tribe builds a record through the activity of its members. Calls, assigned trades and their results contribute to the Tribe's shared history. Individual profits and losses remain tied to each member's own position, while their results can be combined to show the Tribe's overall performance. Over time, this creates a record based on what the Tribe actually traded, not just what was discussed. ## Membership [#membership] You can trade on Tribes without joining a Tribe. If you join one, you can take part in its conversations, Calls and shared activity. You can also leave a Tribe whenever you want. Open positions remain yours after leaving. Historical activity that was legitimately assigned to the Tribe remains part of its history. **You can leave the Tribe. The history stays.** Membership limits, roles and the exact access options available to Tribe owners. See [What is not final yet](/docs/getting-started/not-yet-final). # Changelog (/docs/developers/changelog) ## 2026-09-08 [#2026-09-08] * Documentation site launched at **docs.tribes.wtf**. * Published the initial $TRIBES documentation, including token supply, fee allocation, Buyback & Burn, affiliate economics, distribution and vesting. * Published the first product documentation covering Tribes, Scans, Calls, Tribe Trades, trading, social features, reputation, Activity Rewards and Tribe Battles. * Marked product details that are still being finalised with clear Coming Soon notices. # Developers (/docs/developers) This section is for people who want to build on or connect to Tribes. It is small today because the public interfaces are not yet available. No public API and no integrations are available yet. When they are, they are documented in this section: authentication, endpoints, rate limits and terms for the API, and the integrations themselves as they exist. * [Changelog](/docs/developers/changelog): what has changed in these docs. ## Reading these docs programmatically [#reading-these-docs-programmatically] Every page is available as Markdown by appending `.md` to its path, for example `/docs/token/tokenomics.md`. The whole site is summarised at [/llms.txt](/llms.txt), with full text at [/llms-full.txt](/llms-full.txt). # How Tribes works (/docs/getting-started/how-tribes-works) Tribes brings market discovery, conversation and trading into one shared experience. Someone might share a market with a Tribe, start a discussion or post a Call. From there, every member decides what they want to do. They can keep watching, join the conversation or open their own trade. There is no single required path. A market can move from discovery to discussion to a Call, or someone can simply find an opportunity, trade it and assign that trade to a Tribe. ## A typical flow [#a-typical-flow] ### Discover [#discover] It can start with a token, ticker, contract or market. A member can share what they are watching with a Tribe, or discover something through Tribes itself. See [Scans](/docs/core-concepts/scans). ### Discuss [#discuss] Members can explore the market together using chat, voice and shared market information. They can share research, question an idea and follow what others are seeing as the market moves. ### Call [#call] An idea can become a Call. A Call is a structured market idea that can include the asset, direction, thesis, entry, target, stop and time horizon. When a Call is posted, members can receive a notification even when they are not active in the app. Tapping the notification takes them directly to the Call and the market behind it, where they can review the idea, join the conversation and decide whether to trade. Not every market needs a Call, and receiving a Call never means entering a trade automatically. See [Calls](/docs/core-concepts/calls). ### Trade [#trade] When you decide to trade, you open your own position. You choose your entry, size and exit. When opening the trade, you can optionally assign it to one Tribe. You can also trade without assigning the position to any Tribe. See [Assigning a trade to a Tribe](/docs/trading/assigning-a-trade-to-a-tribe). ### Trade together [#trade-together] When members trade the same market and assign their positions to a Tribe, Tribes can bring that activity together into a Tribe Trade. A Tribe Trade shows the shared activity around a market while every position remains individually controlled. Members can enter at different prices, use different position sizes and exit at different times. See [Tribe Trades](/docs/core-concepts/tribe-trades). ### Build a record [#build-a-record] Trading activity contributes to the history of the people and Tribes behind it. Attributable activity can be used to build verified trading history, performance and reputation over time. Wins remain part of the record. So do losses. See [Verified history](/docs/reputation/verified-history). ## More than one way to start [#more-than-one-way-to-start] A trade does not have to begin with a Call. You might discover a market through another person, a Tribe, a token community, a Call or your own research. You can then decide whether to discuss it, trade it or simply keep watching. The social experience is shared, but the trading decision remains individual. ## Where the rest fits [#where-the-rest-fits] Useful activity across Tribes can contribute to [Activity Rewards](/docs/activity-rewards), allowing eligible contributions that lead to trading activity to be attributed and rewarded. Tribes can compete with each other through [Tribe Battles](/docs/tribe-battles), combining trading performance and community competition. Trading activity also connects to the wider [$TRIBES token economy](/docs/token), including the published mechanics behind the $TRIBES Buyback & Burn. # Introduction (/docs/getting-started) Tribes is a multiplayer trading app built around people, communities and markets. These docs explain how Tribes works: how people discover and discuss markets, how trading works, how activity connects to Tribes, how reputation is built, and how features such as Activity Rewards and Tribe Battles are designed to work. They also document the published mechanics and information behind $TRIBES. **Markets are multiplayer now.** ## How the docs are organised [#how-the-docs-are-organised] * **Getting started** explains what Tribes is, why we are building it and how the product works. * **Core concepts** covers the building blocks of Tribes: Tribes, Scans, Calls, Tribe Trades, profiles and public activity. * **Trading** explains your wallet, opening and closing positions, assigning trades to a Tribe, and trading fees. * **Social** covers chat, voice, following, friends and token communities. * **Reputation** covers verified history, verification, ratings, XP and leaderboards. * **Activity Rewards** explains how eligible contributions can be attributed and rewarded. * **Tribe Battles** explains how Tribes can compete against each other. * **Token** documents the published information about $TRIBES, including its supply, fees, Buyback & Burn, allocation and vesting. * **Security and trust** explains what you control, how verification works and what verification does and does not mean. * **Developers** is the home for APIs, integrations and developer tools as they become available. ## What is final and what is not [#what-is-final-and-what-is-not] The $TRIBES token is live. The Tribes trading app is still in development. Some parts of the product and its underlying mechanics may continue to evolve before release. When a detail has not yet been published or finalised, we mark it clearly: Everything that is not yet final is listed in one place: [What is not final yet](/docs/getting-started/not-yet-final). These docs do not invent details to fill gaps. If a number, date, network, provider, contract detail or product mechanic has not been published here, it should not be treated as official. As Tribes develops, these docs will be updated to reflect the latest published information. ## These docs and tribes.wtf [#these-docs-and-tribeswtf] [tribes.wtf](https://tribes.wtf) introduces Tribes and explains the bigger picture. These docs are the reference for how Tribes and $TRIBES work. The main site, blog, Learn pages and Answers are designed to make Tribes easy to discover and understand. The documentation goes deeper into the product, mechanics and terminology. ## Where to begin [#where-to-begin] # Multiplayer trading (/docs/getting-started/multiplayer-trading) Most trading products are built around one person, one account and one screen. But the way people actually discover and understand markets is often social. Someone shares a token. A friend spots momentum. A community debates a thesis. A Call gets posted. People react. Multiplayer trading brings those moments into the same place as the market and the trade. It means discovering together, talking together, following the same opportunities and building a shared record over time, while every person still makes their own trading decisions. ## What changes [#what-changes] * **Discovery becomes social.** Markets can surface through people, Tribes, Calls, token communities and shared activity. * **Discussion happens next to the market.** Chat, voice, research and market context live in the same experience. * **Calls turn ideas into something actionable.** A Call gives structure to a market idea and can bring members back into the moment through notifications. * **Trading stays personal.** Everyone chooses whether to trade, how much to trade and when to enter or exit. * **Activity becomes visible.** Trades, Calls and participation can contribute to profiles, Tribe history and shared market activity. * **Reputation is built from real activity.** Verified history gives people and Tribes a record based on attributable results over time. ## Shared experience, individual decisions [#shared-experience-individual-decisions] Multiplayer trading does not mean everyone takes the same position. People can see the same market and make completely different decisions. One member might enter immediately. Another might wait. Someone else might decide not to trade at all. If multiple members trade the same market and assign those trades to a Tribe, that activity can come together in a [Tribe Trade](/docs/core-concepts/tribe-trades) while each position remains individually controlled. **The market is shared. The decision is yours.** ## More than trading [#more-than-trading] Multiplayer trading is also about what happens around the trade. People can discover new communities, follow traders, talk in chat or voice, receive Calls, compete through Tribe Battles and build reputation from the activity they create. The result is a trading experience built around people instead of adding a social feed on top of an otherwise individual product. # What is not final yet (/docs/getting-started/not-yet-final) Last reviewed 2026-09-14. These docs do not invent details to fill gaps. This page lists every detail that is still unpublished or unfinalised, section by section, in the words of the page it belongs to. Nothing here has a date or a timeline: when a detail is published, it moves from this list into its page. If a number, date, network, provider, contract detail or product mechanic is on this list, it should not be treated as official anywhere else. ## Core concepts [#core-concepts] * [Profiles](/docs/core-concepts/profiles): profile controls and visibility settings. * [Public trading activity](/docs/core-concepts/public-trading-activity): visibility controls available for different types of activity. * [Tribe Trades](/docs/core-concepts/tribe-trades): the exact statistics, calculations and presentation used inside Tribe Trades. * [Tribes](/docs/core-concepts/tribes): membership limits, roles and the exact access options available to Tribe owners. ## Trading [#trading] * [Assigning a trade to a Tribe](/docs/trading/assigning-a-trade-to-a-tribe): whether a trade can be reassigned or removed from a Tribe after it has been opened. * [Finding markets](/docs/trading/finding-markets): market data, filters, rankings and discovery tools available inside Tribes. * [Perpetuals](/docs/trading/perpetuals): available markets, leverage limits, funding, margin requirements, liquidation rules and the trading venue used for perpetuals. * [Spot trading](/docs/trading/spot-trading): supported assets, order types, minimum trade sizes and network availability will be documented as they are finalised. See [Supported networks](/docs/trading/supported-networks). * [Your wallet](/docs/trading/your-wallet): wallet creation, recovery, supported assets, deposits and withdrawals. ## Social [#social] * [Chat](/docs/social/chat): mentions, moderation tools, message retention and other chat controls. * [Following](/docs/social/following): notification controls available for followed accounts. * [Friends](/docs/social/friends): friend controls, requests, privacy options and friend-only experiences. * [Token communities](/docs/social/token-communities): creation, ownership and moderation controls for token communities. * [Voice](/docs/social/voice): voice room limits, recording, moderation and other voice controls. ## Reputation [#reputation] * [Calls and performance](/docs/reputation/calls-and-performance): resolution and scoring rules for Calls, including targets, stops, time horizons and partial outcomes. * [Leaderboards](/docs/reputation/leaderboards): the leaderboards available at launch, their scoring methods, time windows and whether they are global, per Tribe, per market or category-specific. * [Milestones](/docs/reputation/milestones): milestone list, unlock conditions, rewards and where milestones appear in the product. * [Rating and rank](/docs/reputation/rating-and-rank): rating formula, weighting, time periods, rank tiers and how ratings are used across Tribes. * [Verified by Tribes](/docs/reputation/verified-by-tribes): integrity checks used for Verified Results and the review criteria used for Verified Tokens. * [Verified history](/docs/reputation/verified-history): metrics, time periods and presentation used for verified history. * [XP and levels](/docs/reputation/xp-and-levels): XP actions, values, level thresholds, rewards and how XP is used across features such as Tribe Battles. ## Activity Rewards [#activity-rewards] * [Eligible activity](/docs/activity-rewards/eligible-activity): list of eligible activity, minimum requirements, attribution rules and any activity-specific conditions. * [How attribution works](/docs/activity-rewards/how-attribution-works): attribution model, including attribution windows, qualifying interactions, how multiple contributors are handled and how fee shares are calculated. * [Activity Rewards](/docs/activity-rewards): attribution model, reward percentages, eligibility rules and economics of Activity Rewards. * [Integrity and abuse prevention](/docs/activity-rewards/integrity-and-abuse-prevention): additional enforcement rules, penalties and review procedures. * [Reward states](/docs/activity-rewards/reward-states): review periods, how Available rewards are credited or claimed, and whether additional reward states are used. ## Tribe Battles [#tribe-battles] * [Battle history](/docs/tribe-battles/battle-history): information shown for each Battle, how Battle history affects ratings and how long-term Battle records are presented. * [Battle types](/docs/tribe-battles/battle-types): battle types, available durations, eligible market categories and XP mechanics. * [Challenges](/docs/tribe-battles/challenges): who can issue or accept challenges, how open challenges work, counter rules and any rating-based matchmaking. * [Tribe Battles](/docs/tribe-battles): battle types, scoring formulas, matchmaking rules, eligible markets and XP mechanics. * [Scoring](/docs/tribe-battles/scoring): scoring formula, weighting, tie rules, member-count normalisation, risk adjustments and Battle-specific scoring methods. ## Token [#token] * [Contract addresses](/docs/token/contract-addresses): Official vesting contract addresses and verification links will be published here once available. Official liquidity contract and pool information will be published here once available. * [Tokenomics](/docs/token/tokenomics): buyback venue, execution cadence, burn reporting process and any additional implementation details. * [Utility](/docs/token/utility): Additional $TRIBES utility inside the product, including any potential access, benefits, discounts, staking, governance or other token functionality, will only be documented once officially defined. Until then, the Buyback & Burn mechanism is the published utility described in these docs. * [Vesting and unlocks](/docs/token/vesting-and-unlocks): the vesting contracts, custody structure for locked allocations and where unlocks can be independently verified on-chain will be documented once those details are published. See [Contract addresses](/docs/token/contract-addresses). ## Security & trust [#security--trust] * [Audits](/docs/security-and-trust/audits): No audit has been published yet. When audits of the $TRIBES token contracts, wallet infrastructure or other security-critical parts of the platform are completed, they will be listed here with their scope and date. * [Integrity](/docs/security-and-trust/integrity): review process, reporting tools, appeal process and additional enforcement rules. * [Security](/docs/security-and-trust/security): account security features, wallet recovery, infrastructure security practices, incident response and vulnerability reporting procedures. * [Token verification](/docs/security-and-trust/token-verification): review criteria, verification process and conditions for removing a Verified Token badge. ## Developers [#developers] * [Developers](/docs/developers): No public API and no integrations are available yet. When they are, they are documented in this section: authentication, endpoints, rate limits and terms for the API, and the integrations themselves as they exist. # What is Tribes? (/docs/getting-started/what-is-tribes) Tribes is a multiplayer trading app built around people and communities. You can discover markets, meet traders, talk in chat or voice, share what you are watching, post Calls and open your own trades, all in one place. Trade on your own, or make a Tribe part of the experience. Share ideas, follow what others are seeing and stay connected while the market moves. ## The principles [#the-principles] * **Trade together. Win together. Build a tribe.** * **Discover markets through people and communities.** * **Share and receive Calls when opportunities appear.** * **Talk, trade and follow the market together.** * **Build reputation from real, attributable activity.** ## Built around people [#built-around-people] Trading is already social. People share charts, talk about markets, send tokens to friends, debate ideas and react to opportunities together. Tribes brings those moments into the same place as the market and the trade itself. A Tribe gives people a shared space to discover, discuss and trade around the same markets while building a history together over time. ## One wallet [#one-wallet] You have one Tribes wallet. You can trade completely on your own or optionally assign a trade to one Tribe. When a trade is assigned, it can contribute to that Tribe's activity, statistics and history. Joining a Tribe does not move your money or create a separate Tribe wallet. See [Your wallet](/docs/trading/your-wallet). ## Who it is for [#who-it-is-for] Tribes is built for everyone who wants trading to feel more connected. A Tribe can be a group of friends, a public community, a competitive team or a creator-led community. You can join with people you already know or discover new Tribes and meet people following the same markets. Whether you are making your first trade or have been trading for years, you can discover, talk, share ideas and take part at your own pace. # Calls and performance (/docs/reputation/calls-and-performance) Calls can build a performance record based on how the market moved relative to the setup that was shared. Because a Call can include an asset, direction, entry, target, stop and time horizon, its outcome can be evaluated after the fact. ## Call performance [#call-performance] Call performance is separate from the caller's personal trading performance. A Call can be evaluated based on things such as: * whether the market moved in the expected direction * whether a target was reached * whether a stop was hit * how the market behaved within the intended time horizon * the overall outcome of the setup Positive and negative outcomes can both become part of [verified history](/docs/reputation/verified-history). ## Calls and trading performance [#calls-and-trading-performance] Posting a Call and trading that Call are two different things. A caller may post a Call without opening a position themselves. That means someone can have: * a Call performance record based on the ideas they shared * a trading performance record based on the positions they actually opened The two can be related, but they are not the same record. ## Why the distinction matters [#why-the-distinction-matters] A good market idea does not automatically mean the caller traded it well. In the same way, someone's personal trade can perform differently from the original Call because they entered at another price, used a different size or exited at another moment. Keeping Call performance and trading performance separate makes both records easier to understand. Resolution and scoring rules for Calls, including targets, stops, time horizons and partial outcomes. See [What is not final yet](/docs/getting-started/not-yet-final). # Reputation (/docs/reputation) Reputation on Tribes is built from real activity. Calls, trades, results and participation can contribute to a record that shows what someone has actually done over time. The goal is simple: make reputation useful because it is backed by attributable activity, not screenshots, claims or selective wins. ## How reputation is built [#how-reputation-is-built] Reputation can come from different parts of the Tribes experience: * verified trading history * Calls and their outcomes * trading performance * participation and contribution * XP and levels * leaderboard performance * milestones and achievements Different systems measure different things. Performance shows how someone traded. XP can reflect participation and contribution. Rankings help compare activity over time. ## Verified history matters [#verified-history-matters] A verified record includes both wins and losses. Results are not verified because they are good. They are verified because they are attributable to real activity on Tribes. **A verified loss is still verified.** That means people and Tribes build a history that reflects the full record rather than only the best moments. ## Explore reputation [#explore-reputation] * [Verified by Tribes](/docs/reputation/verified-by-tribes): what verification means and what it does not. * [Verified history](/docs/reputation/verified-history): how attributable results become part of a lasting record. * [Calls and performance](/docs/reputation/calls-and-performance): how Calls contribute to performance history. * [Rating and rank](/docs/reputation/rating-and-rank): how performance can translate into ranking. * [XP and levels](/docs/reputation/xp-and-levels): how participation and contribution are recognised. * [Leaderboards](/docs/reputation/leaderboards): how people and Tribes compare. * [Milestones](/docs/reputation/milestones): progress and achievements over time. # Leaderboards (/docs/reputation/leaderboards) Leaderboards show how people and Tribes compare based on verified performance and activity. They make strong records easier to discover and give traders and communities a way to see where they stand over time. ## What leaderboards can reflect [#what-leaderboards-can-reflect] Leaderboards can be based on signals such as: * verified trading performance * Call performance * Tribe performance * ratings and rank * Battle results * activity within a defined time period Different leaderboards can measure different things, so the metric should always be clear. ## Built on verification [#built-on-verification] A leaderboard is only useful if the activity behind it can be trusted. Leaderboards on Tribes are built from attributable activity and verified records rather than screenshots, claims or popularity alone. That means a high position should reflect a real record, not just a strong profile or large audience. ## People and Tribes [#people-and-tribes] Leaderboards can rank both individual traders and Tribes. Individual leaderboards can highlight strong personal performance. Tribe leaderboards can show how communities are performing as a group based on the trades and results assigned to them. Leaderboards can also connect to competitive experiences such as [Tribe Battles](/docs/tribe-battles). The leaderboards available at launch, their scoring methods, time windows and whether they are global, per Tribe, per market or category-specific. See [What is not final yet](/docs/getting-started/not-yet-final). # Milestones (/docs/reputation/milestones) Milestones mark meaningful points in the progress of a person or a Tribe. They can recognise firsts, streaks, levels, participation and other moments that show how a record develops over time. ## Examples of milestones [#examples-of-milestones] Milestones can include things such as: * first verified Call * first verified trade * first Tribe Battle * a number of Battles completed * reaching a new XP level * reaching a new rank * building a verified history over time * Tribe-wide achievements Milestones are not a separate performance score. They are markers of progress across the wider Tribes experience. ## Personal and Tribe milestones [#personal-and-tribe-milestones] Some milestones can belong to an individual trader. Others can belong to a Tribe and reflect what the community has achieved together. This gives both people and communities a way to look back at how their record has grown. Milestone list, unlock conditions, rewards and where milestones appear in the product. See [What is not final yet](/docs/getting-started/not-yet-final). # Rating and rank (/docs/reputation/rating-and-rank) Ratings and ranks help turn verified performance into something that is easier to understand and compare. They are based on attributable activity and results, rather than follower count, popularity or self-reported performance. ## What a rating can reflect [#what-a-rating-can-reflect] A rating can take into account performance signals such as: * verified trading results * Call performance * consistency over time * risk and the way performance was achieved * other verified performance data The goal is to recognise strong performance without simply rewarding the biggest wallet, the highest leverage or the most activity. ## Rank [#rank] Rank turns performance into a visible position within Tribes. It can help people understand how a trader or Tribe has performed relative to others and can be used across profiles, leaderboards and competitive experiences. A higher rank represents a stronger verified record, not a guarantee of future performance. ## Ratings for Tribes [#ratings-for-tribes] Tribes can build their own performance rating from the attributable trading activity of their members. Because members trade from separate wallets and can assign trades to a Tribe, their results can contribute to a shared Tribe performance record over time. Ratings can also help inform competition and matchmaking in [Tribe Battles](/docs/tribe-battles). ## Rating is different from XP [#rating-is-different-from-xp] Rating and XP measure different things. **Rating** is focused on performance. **XP** is focused on participation, contribution and progress across Tribes. Someone can therefore be highly active without having the highest trading rating, or have strong trading performance without being the most active member. See [XP and levels](/docs/reputation/xp-and-levels). Rating formula, weighting, time periods, rank tiers and how ratings are used across Tribes. See [What is not final yet](/docs/getting-started/not-yet-final). # Verified by Tribes (/docs/reputation/verified-by-tribes) Verification on Tribes means that something has been checked against defined criteria rather than accepted as a claim. It is used in two different contexts: * **Verified Result** for attributable trading activity * **Verified Token** for tokens reviewed by the Tribes team They mean different things and should be read separately. ## Verified Result [#verified-result] A Verified Result is based on attributable trading activity recorded through Tribes. Verification is used to confirm what happened, not whether the outcome was good. A verified result can be: * profitable * unprofitable * still part of an open record Wins and losses can both be verified. **A verified loss is still verified.** Verification confirms the record of an outcome. It does not predict future performance and does not mean another person should take the same trade. ## Verified Token [#verified-token] Some tokens can receive a **Verified Token** badge after review by the Tribes team. The badge is intended to help distinguish reviewed tokens from unknown, impersonated or potentially misleading assets. A Verified Token does not mean: * the token is risk free * the token is guaranteed to remain legitimate * the price will increase * Tribes recommends buying it **Verified means checked. It does not mean guaranteed.** See [Token verification](/docs/security-and-trust/token-verification). ## Verification and integrity [#verification-and-integrity] Verification depends on the integrity of the underlying activity or information. Trading records that are fraudulent, manipulated or otherwise invalid can be excluded or removed after review. Verification exists to make the record more trustworthy, not to turn performance or tokens into endorsements. Integrity checks used for Verified Results and the review criteria used for Verified Tokens. See [What is not final yet](/docs/getting-started/not-yet-final). # Verified history (/docs/reputation/verified-history) Verified history is the part of your record built from real, attributable activity on Tribes. It can include trades you opened, Calls you posted and the outcomes connected to them. The goal is to create a record based on what actually happened, not on what someone chooses to show. ## Wins stay. Losses stay. [#wins-stay-losses-stay] A verified record includes both positive and negative outcomes. A losing Call or trade does not disappear simply because it performed badly. That is what gives the record value: it reflects the full history. **A verified loss is still verified.** ## What can be removed [#what-can-be-removed] Fraudulent, manipulated or otherwise invalid activity can be excluded or removed after review. Removing invalid activity is a correction to the record, not a way to improve someone's performance history. See [Integrity](/docs/security-and-trust/integrity). ## What can contribute to verified history [#what-can-contribute-to-verified-history] Verified history can include: * Calls and their outcomes * trades opened through Tribes * trades assigned to Tribes * positive and negative results * other attributable activity that meets the requirements for verification Not every piece of activity is automatically verified. Verification depends on whether the underlying activity can be attributed and validated. ## Why verified history matters [#why-verified-history-matters] Verified history gives people and Tribes a record that can be evaluated over time. It can contribute to: * verified performance * reputation * profiles * leaderboards * Tribe statistics and history Verification records what happened. It does not guarantee what will happen next. Metrics, time periods and presentation used for verified history. See [What is not final yet](/docs/getting-started/not-yet-final). # XP and levels (/docs/reputation/xp-and-levels) XP measures participation and contribution across Tribes. It can reflect how active and useful someone is over time: taking part in a Tribe, sharing useful market context, contributing to discussions, joining Battles and helping create activity around the community. Levels are milestones built on top of XP. ## What XP is for [#what-xp-is-for] XP is designed to recognise contribution beyond trading performance. That can include activity such as: * participating in Tribes * sharing useful Scans or market context * contributing to discussions * taking part in Tribe Battles * other eligible activity across Tribes The exact actions that grant XP and how much they are worth will be defined separately. ## XP is not a trading score [#xp-is-not-a-trading-score] XP and Rating measure different things. **XP** reflects participation, contribution and progress. **Rating** reflects verified trading performance. Someone can have a high XP level without having the highest trading rating, and someone with strong trading performance does not automatically have the highest XP. See [Rating and rank](/docs/reputation/rating-and-rank). ## XP and Activity Rewards [#xp-and-activity-rewards] XP is also separate from [Activity Rewards](/docs/activity-rewards). XP recognises useful participation even when that activity does not directly create a trade. Activity Rewards are economic rewards tied to eligible activity that can be attributed to real trading activity. The two systems can recognise the same contribution in different ways. ## Levels [#levels] Levels give long-term progress a visible form. As members earn XP, they can reach new levels that reflect their continued participation across Tribes. XP actions, values, level thresholds, rewards and how XP is used across features such as Tribe Battles. See [What is not final yet](/docs/getting-started/not-yet-final). # Audits (/docs/security-and-trust/audits) Independent security reviews and audits related to Tribes will be published on this page. When an audit is completed, the entry can include: * auditor * scope * date * systems or contracts reviewed * report link * relevant findings * remediation status where applicable ## Current status [#current-status] No audit has been published yet. When audits of the $TRIBES token contracts, wallet infrastructure or other security-critical parts of the platform are completed, they will be listed here with their scope and date. ## Why audits matter [#why-audits-matter] Audits are one part of the wider security process. They can help identify vulnerabilities and provide an independent review of specific contracts or systems, but an audit does not guarantee that a system is free of risk. # Security & trust (/docs/security-and-trust) Security and trust on Tribes are built around a few simple principles: * users keep control of their own wallets and positions * public activity should be attributable and verifiable * verification should explain what has been checked, not imply guarantees * trading risk should be clear * invalid or manipulated activity should not remain part of trusted records This section explains how those principles apply across the product. ## Explore security and trust [#explore-security-and-trust] * [User control](/docs/security-and-trust/user-control): how wallet and position control works. * [Trading risk](/docs/security-and-trust/trading-risk): the risks involved in trading and why nothing on Tribes is financial advice. * [Token verification](/docs/security-and-trust/token-verification): what a Verified Token means and what it does not mean. * [Integrity](/docs/security-and-trust/integrity): how invalid, fraudulent or manipulated activity is handled. * [Security](/docs/security-and-trust/security): how Tribes approaches product and infrastructure security. * [Audits](/docs/security-and-trust/audits): published security reviews and audit information. ## Trust through evidence [#trust-through-evidence] Tribes is designed around real activity rather than screenshots or self-reported claims. Verified history, Calls, assigned trades and other attributable activity can create a record that people can evaluate over time. **Verified means checked. It does not mean guaranteed.** # Integrity (/docs/security-and-trust/integrity) Reputation, Activity Rewards and Tribe Battles all depend on records that people can trust. Integrity is the system behind those records: making sure activity is attributable, outcomes are not selectively edited and invalid behaviour does not remain part of the trusted record. ## Core principles [#core-principles] * **Real activity only.** Verified records are based on attributable activity and integrity checks, not screenshots or self-reported claims. * **Wins and losses stay.** Genuine outcomes remain part of verified history, whether they were positive or negative. * **Invalid activity can be removed.** Fraudulent, manipulated or otherwise invalid activity can be excluded or removed after review. * **Attribution must hold.** Activity used for rewards, reputation or competition must be connected to the people and actions it claims to represent. * **Rewards are checked before becoming available.** Activity Rewards can remain pending until the underlying activity and attribution have passed the required checks. * **Battle results depend on valid activity.** Activity that does not meet the relevant Battle or integrity rules should not contribute to a Battle result. ## Correcting the record [#correcting-the-record] Integrity reviews exist to correct the record, not to improve it for the person or Tribe being reviewed. A legitimate loss is not removed because it looks bad. A fraudulent win does not stay because it looks good. The goal is for verified history to reflect what actually happened. ## Reviews and enforcement [#reviews-and-enforcement] Where activity is found to be invalid, Tribes can take actions such as: * removing or excluding activity from verified history * voiding Activity Rewards * excluding activity from reputation or rankings * excluding activity from Tribe Battle scoring * applying additional enforcement where appropriate See [Reward states](/docs/activity-rewards/reward-states) and [Integrity and abuse prevention](/docs/activity-rewards/integrity-and-abuse-prevention). Review process, reporting tools, appeal process and additional enforcement rules. See [What is not final yet](/docs/getting-started/not-yet-final). # Security (/docs/security-and-trust/security) Security on Tribes starts with user control. Every user trades from their own non-custodial wallet. Tribes does not hold or control user assets, and Tribe membership does not change ownership of funds or positions. ## Wallet security [#wallet-security] Your wallet remains under your control. That means: * Tribes does not custody user assets * Tribe members cannot access or manage each other's wallets * assigning a trade to a Tribe does not move the position into a shared wallet * Calls, Scans and social activity do not move funds by themselves See [Your wallet](/docs/trading/your-wallet) and [User control](/docs/security-and-trust/user-control). ## Product security [#product-security] Security also applies to the wider Tribes platform, including account access, wallet interactions, transaction flows and the integrity of activity shown across the product. Security-sensitive systems and practices should be documented clearly once they are finalised and available. ## Reporting and reviews [#reporting-and-reviews] Published security reviews and audits will be listed separately on [Audits](/docs/security-and-trust/audits). Account security features, wallet recovery, infrastructure security practices, incident response and vulnerability reporting procedures. See [What is not final yet](/docs/getting-started/not-yet-final). # Token verification (/docs/security-and-trust/token-verification) Some tokens can receive a **Verified Token** badge after review by the Tribes team. The badge is designed to help users distinguish reviewed tokens from unknown, impersonated or potentially misleading assets. ## Verified means checked [#verified-means-checked] A Verified Token has been reviewed against defined criteria by Tribes. Verification reflects that review at a point in time. It does not remove the risks of trading the token, and it does not mean the project or asset cannot change after verification. ## What verification does not mean [#what-verification-does-not-mean] A Verified Token does not mean: * the token is risk free * the project is guaranteed to remain legitimate * the token price will increase * Tribes recommends buying or trading it **Verified means checked. It does not mean guaranteed.** A Verified Token can still lose value, experience liquidity problems or change materially after review. Always verify the asset and understand the risks before trading. ## Verification can change [#verification-can-change] Verification is not necessarily permanent. If material information changes, a token no longer meets the relevant criteria or new integrity concerns are identified, its verification status can be reviewed or removed. ## $TRIBES [#tribes] The official $TRIBES contract information is published on [Contract addresses](/docs/token/contract-addresses). Always verify the full contract address and network before interacting with $TRIBES. Review criteria, verification process and conditions for removing a Verified Token badge. See [What is not final yet](/docs/getting-started/not-yet-final). # Trading risk (/docs/security-and-trust/trading-risk) Trading involves risk, including the possible loss of the amount invested. Nothing on Tribes or in these docs is financial advice, investment advice or an offer to buy or sell any asset. ## What Calls, Scans and verified records mean [#what-calls-scans-and-verified-records-mean] * A **Call** is a trade idea shared by a user. It can be wrong. * A **Scan** brings a market to the Tribe for inspection and discussion. It is not a recommendation to trade. * **Verified history** records attributable activity and outcomes. Past performance does not predict future results. * A **Verified Token** means the token has been checked against defined criteria. It does not mean the token is risk free or guaranteed. ## Market risk [#market-risk] Crypto markets can move quickly and prices can change significantly in a short period of time. You can lose some or all of the amount committed to a trade. Liquidity, volatility, execution conditions and network activity can also affect the price at which a trade is completed. ## Perpetuals and leverage [#perpetuals-and-leverage] Perpetual trading can involve leverage. Leverage increases exposure to price movements and can magnify both gains and losses. A leveraged position can be liquidated, potentially resulting in the loss of the full amount committed to the position. See [Perpetuals](/docs/trading/perpetuals). ## Social activity is not advice [#social-activity-is-not-advice] Seeing another user's position, Call, performance or Tribe activity does not mean the same trade is appropriate for you. Different users can have different entries, position sizes, risk tolerance and exit decisions. Public activity provides context. It is not a recommendation to follow another user's trade. ## Product availability [#product-availability] The $TRIBES token is live. The Tribes trading app described throughout these docs is still in development. Product features, availability and implementation details may change before release. # User control (/docs/security-and-trust/user-control) User control is a core principle across Tribes. Every user trades from their own non-custodial wallet and manages their own positions. ## What you control [#what-you-control] * **Your wallet is yours.** Tribes does not hold or control your assets. * **Your positions are yours.** You decide when to enter, how much to trade and when to exit. * **Your funds are not pooled.** Joining a Tribe does not move your assets into a shared wallet. * **Assigning a trade does not transfer control.** A trade can be assigned to one Tribe while remaining fully under your control. * **A Call does not execute a trade.** It gives you a trade setup and context. You decide whether to act on it. * **Visibility does not change ownership.** Other users may be able to see your public trading activity, but they cannot manage it. * **Leaving a Tribe does not affect your positions.** Open positions remain yours, while legitimate historical activity can remain part of the Tribe's record. ## Shared experience, individual control [#shared-experience-individual-control] Tribes is built so people can discover, discuss and trade markets together without combining control of their wallets or positions. Members can participate in the same Call or Tribe Trade while using different entries, position sizes and exits. **The experience is shared. The decision is yours.** # Chat (/docs/social/chat) Every Tribe has chat. It is where members share markets, react to Scans, discuss Calls and stay in the conversation while trades are live. Chat keeps the people and the market in the same place, without needing to move the discussion to another app. ## What chat is for [#what-chat-is-for] * discussing tokens, markets and Scans * sharing research, context and reactions * talking through a Call before or after members decide to trade it * following a market or a Tribe Trade while it is live * ordinary conversation between people in the Tribe ## From conversation to action [#from-conversation-to-action] A discussion in chat can lead to a Scan, a Call or a trade, but it does not have to. Someone might drop a contract address, another member might add context, and the conversation can develop from there. If a member wants to turn an idea into a clear trade setup, they can create a [Call](/docs/core-concepts/calls). ## Chat and trading [#chat-and-trading] Chat is part of the trading experience, but messages themselves do not execute trades. Members decide for themselves when they want to move from conversation to action. Mentions, moderation tools, message retention and other chat controls. See [What is not final yet](/docs/getting-started/not-yet-final). # Following (/docs/social/following) Following someone on Tribes helps you stay connected to the traders and people you care about. Their public activity can appear in your experience, including things such as trades, Calls, market activity and verified performance. ## What following helps you see [#what-following-helps-you-see] Depending on what a person shares publicly, following can help you keep up with: * markets they are trading * Calls they post * recent trading activity * verified performance * Tribe activity * new ideas and markets they are watching Following makes discovery more personal by letting the people you trust or find interesting become part of how markets reach you. ## Following and discovery [#following-and-discovery] A trader you follow might surface a market before you would have found it yourself. You can inspect what they are doing, read the context around a Call, join the discussion and decide what you want to do next. Following is part of the discovery layer of Tribes, connecting people directly to markets and activity. ## Notifications [#notifications] You may also be able to receive notifications when people you follow create relevant activity, such as posting a new Call. Notification controls available for followed accounts. See [What is not final yet](/docs/getting-started/not-yet-final). # Friends (/docs/social/friends) You become friends on Tribes when you follow each other. Friends make the social side of Tribes more personal. You can keep up with each other's activity, share markets, send Calls and trade together inside the same communities. ## Trading with friends [#trading-with-friends] A group of friends can create or join a Tribe and use it as a shared place to follow markets together. Friends can: * share Scans and markets * discuss ideas in chat or voice * post Calls to each other * follow each other's trading activity * join the same Tribe Trades * build a shared history as a group Over time, that activity creates a record of how the group trades together. ## Friends and discovery [#friends-and-discovery] Friends can also become part of how you discover markets on Tribes. A market one of your friends is watching, a Call they post or activity from a Tribe you share can surface opportunities you might not have found on your own. Friend controls, requests, privacy options and friend-only experiences. See [What is not final yet](/docs/getting-started/not-yet-final). # Social (/docs/social) Trading on Tribes is built around people. The social layer connects the conversations, communities and people behind the market. It is where members share Scans, receive Calls, talk through ideas, follow traders and stay connected while trades are live. Social activity is part of the trading experience, not a separate feed added on top of it. ## Social on Tribes [#social-on-tribes] * [Chat](/docs/social/chat): talk with your Tribe while following markets and trades. * [Voice](/docs/social/voice): join live conversations without leaving the trading experience. * [Following](/docs/social/following): follow traders and keep up with their public activity. * [Friends](/docs/social/friends): connect through mutual relationships on Tribes. * [Token communities](/docs/social/token-communities): join the conversation around a specific token or market. ## Built around shared moments [#built-around-shared-moments] A market can move quickly. Someone might share a Scan, another member might create a Call, people can join the conversation and members can start opening their own positions. Tribes keeps those moments connected, so the people, market, conversation and trading activity do not have to live across different apps. # Token communities (/docs/social/token-communities) A token community is the social space around a specific token. It brings together the people watching it, trading it, holding it or simply following what is happening around the market. Instead of the conversation living somewhere else, the market and the community around it can live in the same place. ## What happens in a token community [#what-happens-in-a-token-community] People can: * follow the token and its market activity * share Scans and context * discuss the market in chat or voice * post Calls around the token * follow public trading activity * see how people and Tribes are interacting with the market * discover other traders and communities around the same asset A token community can become the place people return to while a market is active. ## Connected to the wider Tribes network [#connected-to-the-wider-tribes-network] Token communities connect markets to the rest of Tribes. A Call posted around a token can lead people into the market. Trading activity can surface across profiles and Tribes. People following the same asset can discover each other through the activity around it. This makes a token more than a ticker on a list. It becomes a market with people around it. ## Token verification [#token-verification] Some tokens may receive a **Verified by Tribes** badge after review by the Tribes team. Verification means the token has been checked. It does not mean the token is risk free, guaranteed, endorsed as an investment or expected to increase in value. **Verified means checked. It does not mean guaranteed.** See [Token verification](/docs/security-and-trust/token-verification). Creation, ownership and moderation controls for token communities. See [What is not final yet](/docs/getting-started/not-yet-final). # Voice (/docs/social/voice) Every Tribe can use voice alongside chat. Voice is built for the moments when talking is faster than typing: walking through a chart, reacting to a move, discussing a Scan or following a Call while the market is live. ## What voice is for [#what-voice-is-for] * talking through markets in real time * discussing Scans and Calls * reacting quickly when a market moves * sharing context while members are watching the same trade * staying connected without leaving the trading experience ## From voice to action [#from-voice-to-action] A voice conversation can lead to a Call or a trade, but it does not have to. Members can talk through an idea, compare views and decide for themselves what they want to do next. If the discussion turns into a clear trade setup, someone can create a [Call](/docs/core-concepts/calls). ## Voice and trading [#voice-and-trading] Voice is part of the shared experience around a trade. Talking about a market does not execute anything. Every member still opens and manages their own position. See [Opening a trade](/docs/trading/opening-a-trade). Voice room limits, recording, moderation and other voice controls. See [What is not final yet](/docs/getting-started/not-yet-final). # Contract addresses (/docs/token/contract-addresses) This page is the source of truth for the official contract information for $TRIBES. The official network and contract address are published here and nowhere else first. Until they appear on this page, no address shared anywhere else is official. Always verify the contract address here before interacting with the token. ## $TRIBES token [#tribes-token] $TRIBES exists on Robinhood Chain only. The same address on any other network is not $TRIBES. ## Vesting contracts [#vesting-contracts] Official vesting contract addresses and verification links will be published here once available. ## Liquidity [#liquidity] Official liquidity contract and pool information will be published here once available. ## Verify before you trade [#verify-before-you-trade] Contract addresses can be copied, impersonated or shared incorrectly. Before interacting with $TRIBES: * verify the network * verify the full contract address * use the address published on this page * do not rely on contract addresses shared in replies, DMs or unofficial communities If an address does not match the official $TRIBES contract listed on this page, do not interact with it. ## Official source [#official-source] This documentation is the reference for official $TRIBES contract information. If contract details change or additional official contracts are introduced, this page will be updated. # Distribution (/docs/token/distribution) The maximum supply of $TRIBES is **1,000,000,000 tokens**, distributed across seven core allocations. The allocation structure is designed to support the long-term development of Tribes while limiting how much supply can enter circulation early. | Allocation | Share | $TRIBES | Lock / vesting | | --------------------- | -------: | ------: | ---------------------------------------- | | Community & Ecosystem | 20% | 200M | 24-month lock + 36-month linear release | | Investors | 20% | 200M | 12-month cliff + 12-month linear vesting | | Team | 20% | 200M | 24-month cliff + 36-month linear vesting | | Liquidity | 15% | 150M | DEX liquidity, locked at launch | | Treasury | 15% | 150M | 12-month lock + 36-month linear release | | Partnerships & Growth | 7.5% | 75M | 12-month cliff + 36-month linear release | | Advisors | 2.5% | 25M | 24-month cliff + 24-month linear vesting | | **Total** | **100%** | **1B** | | ## What each allocation is for [#what-each-allocation-is-for] 200M $TRIBES allocated to support long-term participation, incentives and growth across the Tribes ecosystem. 200M $TRIBES allocated to investors. The allocation has a 12-month cliff before linear vesting begins. 200M $TRIBES allocated to the team, with no team tokens vesting during the first 24 months. 150M $TRIBES reserved to establish and support liquid markets for the token, including DEX liquidity. 150M $TRIBES reserved for the token treasury and long-term needs of the ecosystem. The token treasury is separate from platform revenue generated through Tribes. 75M $TRIBES allocated to strategic partnerships, integrations, distribution and ecosystem growth. 25M $TRIBES allocated to advisors, with no advisor tokens vesting during the first 24 months. ## Initial supply locks [#initial-supply-locks] Most of the maximum supply is subject to an initial lock or cliff. The following allocations have an initial lock or cliff of at least 12 months: * Community & Ecosystem — 20% * Investors — 20% * Team — 20% * Treasury — 15% * Partnerships & Growth — 7.5% * Advisors — 2.5% Together, these allocations represent **850M $TRIBES, or 85% of the maximum supply**. The remaining **15% Liquidity allocation** follows its separate launch liquidity structure. An initial lock or cliff does not mean the full allocation becomes circulating immediately when that period ends. Most allocations continue into linear vesting or release schedules. See [Vesting and unlocks](/docs/token/vesting-and-unlocks) for the full schedules. These figures represent the published $TRIBES allocation structure. Any official changes to the allocation or vesting schedules will be reflected in these docs. # $TRIBES overview (/docs/token) $TRIBES is the native token of the Tribes ecosystem. It is designed to connect activity on the trading platform to the wider Tribes economy through a Buyback & Burn mechanism funded by trading fees. ## How $TRIBES connects to Tribes [#how-tribes-connects-to-tribes] Trading activity on Tribes generates platform fee revenue. Under the Buyback & Burn mechanism, **50% of Tribes trading fee revenue is allocated to purchasing $TRIBES from the market and permanently burning the tokens acquired.** This connects usage of the trading platform to the token economy: **Trading activity → Tribes trading fees → $TRIBES buybacks → Permanent burns** As trading activity grows, the amount of fee revenue available for the Buyback & Burn mechanism can grow with it. Every $TRIBES token purchased through the mechanism and burned is permanently removed from circulation. Because the maximum supply is fixed at **1,000,000,000 TRIBES**, burned tokens cannot be replaced through additional minting. ## Trading fees [#trading-fees] The fee generated by a trade depends on the type of transaction. Standard trading fees can vary based on factors such as the asset, transaction size and execution route. Perpetual trades have a **0.05% Tribes trading fee per transaction**, separate from any applicable protocol fees, funding payments or other execution costs. The applicable fee is shown before a trade is confirmed. See [Fees](/docs/trading/fees). ## What is documented [#what-is-documented] * [Utility](/docs/token/utility): how $TRIBES fits into the Tribes ecosystem. * [Tokenomics](/docs/token/tokenomics): Buyback & Burn, platform revenue and the wider token economy. * [Distribution](/docs/token/distribution): how the token supply is allocated. * [Vesting and unlocks](/docs/token/vesting-and-unlocks): how allocated tokens enter circulation over time. * [Contract addresses](/docs/token/contract-addresses): the official $TRIBES contract information. $TRIBES is a crypto asset and its value can rise or fall. Buybacks and token burns reduce supply but do not guarantee demand, price appreciation or future value. Nothing in these docs is financial advice or an offer to buy or sell any asset. # Tokenomics (/docs/token/tokenomics) ## Token supply [#token-supply] $TRIBES has a fixed maximum supply of **1,000,000,000 tokens**. No additional $TRIBES can be minted beyond this maximum supply. The token economy is designed to connect activity on Tribes to the supply of $TRIBES through a Buyback & Burn mechanism funded by platform trading fees. ## Trading fee structure [#trading-fee-structure] Trading fees depend on the type of transaction. Standard trades can have variable fees based on factors such as: * transaction size * asset * execution route * underlying market or protocol Perpetual trades have a **0.05% Tribes trading fee per transaction**. The applicable Tribes fee is shown before a trade is confirmed. Additional costs such as network fees, protocol fees or perpetual funding payments may apply separately. See [Fees](/docs/trading/fees). ## Revenue allocation [#revenue-allocation] Tribes trading fee revenue is divided into two equal allocations: | Destination | Share of Tribes trading fee revenue | | ---------------------- | ----------------------------------: | | $TRIBES Buyback & Burn | 50% | | Tribes Revenue | 50% | The Buyback & Burn allocation and Tribes Revenue allocation are separate. Affiliate commissions are funded from the Tribes Revenue portion and do not reduce the Buyback & Burn allocation. ## $TRIBES Buyback & Burn [#tribes-buyback--burn] **50% of Tribes trading fee revenue** is allocated to the $TRIBES Buyback & Burn program. That allocation is used to purchase $TRIBES from the market. Tokens acquired through the program are then permanently burned. ### How it works [#how-it-works] * Trading on Tribes generates platform fee revenue. * 50% of that revenue is allocated to Buyback & Burn. * The allocation is used to purchase circulating $TRIBES. * Purchased tokens are permanently burned. * Burned tokens cannot be minted again. The program is funded by platform activity rather than by a separate token reserve. **Trading activity → Tribes trading fees → $TRIBES buybacks → Permanent burns** ## What activity means for buybacks [#what-activity-means-for-buybacks] The amount allocated to Buyback & Burn depends on the actual Tribes trading fee revenue generated by the platform. Because standard trading fees can vary, trading volume alone does not determine the exact amount of fee revenue generated. For example: | Tribes trading fee revenue | Buyback & Burn | Tribes Revenue | | -------------------------: | -------------: | -------------: | | $100,000 | $50,000 | $50,000 | | $1,000,000 | $500,000 | $500,000 | | $10,000,000 | $5,000,000 | $5,000,000 | The number of $TRIBES tokens removed from circulation depends on the market price at which each buyback is executed. The allocation itself remains fixed at **50% of Tribes trading fee revenue**. ## Tribes Revenue [#tribes-revenue] The remaining **50% of Tribes trading fee revenue** belongs to Tribes as platform revenue. It can support the operation, development and growth of the platform. This revenue is separate from the Buyback & Burn allocation. ## Affiliate system [#affiliate-system] The affiliate system rewards users who bring active traders to Tribes. Affiliate commissions are paid from Tribes Revenue, not from the Buyback & Burn allocation. For activity generated by an eligible referred user: 1. Tribes trading fee revenue is split: * **50% → Buyback & Burn** * **50% → Tribes Revenue** 2. The affiliate can receive **75% of the Tribes Revenue** generated by that referred activity. This means the affiliate receives 75% of Tribes' half, not 75% of the full trading fee revenue. | Destination | Affiliate-attributed fee revenue | Non-affiliate fee revenue | | -------------- | -------------------------------: | ------------------------: | | Buyback & Burn | 50% | 50% | | Affiliate | 37.5% | 0% | | Tribes Revenue | 12.5% | 50% | | Total | 100% | 100% | The Buyback & Burn allocation remains unchanged whether trading activity comes from an affiliate-referred user or not. ## Economic flywheel [#economic-flywheel] The economic model connects platform growth to the $TRIBES token economy. **More users → More trading activity → More Tribes trading fee revenue → More $TRIBES buybacks → More $TRIBES permanently burned** Affiliate incentives can help bring additional users and trading activity to Tribes while leaving the Buyback & Burn allocation unchanged. The mechanism links platform usage to recurring market purchases and permanent reductions in circulating supply. It does not guarantee demand, token price appreciation or future returns. ## Core economic structure [#core-economic-structure] Buyback venue, execution cadence, burn reporting process and any additional implementation details. See [What is not final yet](/docs/getting-started/not-yet-final). The figures on this page describe the published economic structure of $TRIBES. They are not projections of trading volume, token price, demand or returns. Buybacks and burns reduce supply but do not guarantee price appreciation. # Utility (/docs/token/utility) The published utility of $TRIBES starts with a direct connection between activity on the Tribes platform and the token economy. Trading on Tribes generates platform fee revenue. Part of that revenue is used to buy $TRIBES from the market and permanently remove those tokens from circulation. ## Buyback & Burn [#buyback--burn] The documented mechanism works as follows: * Trading activity generates Tribes trading fee revenue. * **50% of Tribes trading fee revenue** is allocated to the $TRIBES Buyback & Burn program. * $TRIBES is purchased from the market using that allocation. * Tokens purchased through the program are permanently burned. * The maximum supply is fixed at **1,000,000,000 TRIBES** and cannot be increased. This creates a direct economic link between usage of Tribes and the $TRIBES supply. **Trading activity → Tribes trading fees → $TRIBES buybacks → Permanent burns** See [Tokenomics](/docs/token/tokenomics). ## Why it matters [#why-it-matters] As activity on Tribes grows, the amount of trading fee revenue available to the Buyback & Burn mechanism can grow with it. Every token burned through the program is permanently removed from circulation and cannot be replaced through additional minting. Buybacks and burns reduce supply, but they do not guarantee demand, price appreciation or future token value. ## Additional utility [#additional-utility] Additional $TRIBES utility inside the product, including any potential access, benefits, discounts, staking, governance or other token functionality, will only be documented once officially defined. Until then, the Buyback & Burn mechanism is the published utility described in these docs. # Vesting and unlocks (/docs/token/vesting-and-unlocks) The $TRIBES allocation and vesting structure is designed to support controlled long-term distribution of the token supply. Different allocations follow different lock, cliff and linear release schedules. ## Lock and vesting structure [#lock-and-vesting-structure] A **lock** or **cliff** is a period during which no tokens from that allocation are released. A **linear release** or **linear vesting** distributes the allocation gradually over the stated number of months after the initial lock or cliff. | Allocation | Initial lock / cliff | Then | Fully released | | ---------------------------- | -------------------------------------------- | ----------------------- | -------------- | | Community & Ecosystem (200M) | 24 months | 36-month linear release | Month 60 | | Investors (200M) | 12-month cliff | 12-month linear vesting | Month 24 | | Team (200M) | 24-month cliff | 36-month linear vesting | Month 60 | | Liquidity (150M) | Locked at launch, allocated to DEX liquidity | — | — | | Treasury (150M) | 12 months | 36-month linear release | Month 48 | | Partnerships & Growth (75M) | 12-month cliff | 36-month linear release | Month 48 | | Advisors (25M) | 24-month cliff | 24-month linear vesting | Month 48 | ## Allocation schedules [#allocation-schedules] * **Community & Ecosystem.** 200M $TRIBES remain locked for the first 24 months, followed by a 36-month linear release. Fully released by month 60. * **Investors.** 200M $TRIBES are subject to a 12-month cliff followed by 12 months of linear vesting. Fully vested by month 24. * **Team.** 200M $TRIBES remain locked for the first 24 months, followed by 36 months of linear vesting. Fully vested by month 60. * **Liquidity.** 150M $TRIBES are allocated to DEX liquidity and locked at launch. * **Treasury.** 150M $TRIBES remain locked for the first 12 months, followed by a 36-month linear release. Fully released by month 48. * **Partnerships & Growth.** 75M $TRIBES are subject to a 12-month cliff followed by a 36-month linear release. Fully released by month 48. * **Advisors.** 25M $TRIBES remain locked for the first 24 months, followed by 24 months of linear vesting. Fully vested by month 48. ## The first 12 months [#the-first-12-months] During the first 12 months, the following allocations are subject to an initial lock or cliff: * Community & Ecosystem — 200M * Investors — 200M * Team — 200M * Treasury — 150M * Partnerships & Growth — 75M * Advisors — 25M Together, that represents **850M $TRIBES, or 85% of the maximum supply**. The Liquidity allocation follows its separate launch liquidity structure. An allocation reaching the end of its initial lock or cliff does not mean the full allocation becomes available at once. Most allocations continue into a linear vesting or release period. Months are counted from the $TRIBES token launch date. The vesting contracts, custody structure for locked allocations and where unlocks can be independently verified on-chain will be documented once those details are published. See [Contract addresses](/docs/token/contract-addresses). # Assigning a trade to a Tribe (/docs/trading/assigning-a-trade-to-a-tribe) When you open a trade, you can assign it to one Tribe. Assigning a trade connects that position and its result to the Tribe's shared activity, statistics and history. ## What assigning does [#what-assigning-does] * The trade becomes part of that Tribe's activity and performance. * If other members are trading the same market and assigning their trades to the same Tribe, the group can follow the combined activity as a [Tribe Trade](/docs/core-concepts/tribe-trades). * The result can contribute to the Tribe's trading history and verified performance. * Where eligible, attributable activity around the trade can also connect to [Activity Rewards](/docs/activity-rewards). ## Shared performance [#shared-performance] Every member keeps their own position, but assigned trades can be brought together to show how the Tribe is performing as a group. Members can have different: * entries * position sizes * exits * individual profit or loss Their individual results remain their own, while the assigned results can be combined into Tribe statistics and performance. ## The rules [#the-rules] * A trade can be assigned to **one Tribe**. * A trade that is not assigned to a Tribe remains part of your personal trading activity only. * Only assigned trades contribute to that Tribe's trading activity and performance. * Assigning a trade does not move the position out of your wallet. Whether a trade can be reassigned or removed from a Tribe after it has been opened. See [What is not final yet](/docs/getting-started/not-yet-final). # Fees (/docs/trading/fees) Tribes shows the applicable trading costs before you confirm a transaction. Fees can differ depending on the type of trade and how it is executed. ## Spot and standard trades [#spot-and-standard-trades] Fees for buying and selling crypto assets can vary depending on factors such as: * transaction size * the asset being traded * the execution route * underlying protocol costs The exact Tribes trading fee is shown before you confirm the transaction. ## Perpetuals [#perpetuals] Perpetual trades have a **0.05% trading fee per transaction**. This fee is separate from other costs associated with perpetual trading, including: * funding payments * underlying protocol fees * other execution costs ## Additional costs [#additional-costs] Depending on the transaction, additional costs can include: * blockchain network fees * third-party protocol fees * payment provider fees * funding payments for perpetual positions These costs are separate from the Tribes trading fee where applicable. ## Before you trade [#before-you-trade] The applicable fee and available execution information are shown before you confirm a trade. You always have the opportunity to review the transaction before submitting it. # Finding markets (/docs/trading/finding-markets) On Tribes, markets come from people as much as from lists. A token can reach you because someone in your Tribe shared it, a trader posted a Call, a market is moving, or you found it yourself. The difference is that the market, the people talking about it and the trading activity around it can all live in the same place. ## Ways a market reaches you [#ways-a-market-reaches-you] * **Scans.** A member shares a token, ticker, contract address or market with the Tribe. See [Scans](/docs/core-concepts/scans). * **Calls.** Someone shares a specific trade setup around a market. See [Calls](/docs/core-concepts/calls). * **Tribe activity.** Assigned trades show which markets members of a Tribe are actively trading. * **Token communities.** Markets can have their own community where people follow activity and discussion around the asset. * **Discover.** Markets, Calls, Tribes and activity can surface through the wider Tribes discovery experience. * **Your own search.** You can look up a market yourself and decide what to do with it. ## Inspecting a market together [#inspecting-a-market-together] A Scan brings the market directly into the Tribe. Members can inspect the available market data, look at the chart and discuss what they are seeing in chat or voice. From there, the market might simply stay on the Tribe's radar, become a Call or lead members to open their own trades. There is no required path. ## From discovery to action [#from-discovery-to-action] Finding a market is only the beginning. You can keep watching it, discuss it with others, follow a Call or open your own position. If you trade it, you can assign that trade to one Tribe so the result can contribute to that Tribe's activity and performance. See [Opening a trade](/docs/trading/opening-a-trade). Market data, filters, rankings and discovery tools available inside Tribes. See [What is not final yet](/docs/getting-started/not-yet-final). # Trading (/docs/trading) Trading on Tribes stays personal. You trade from your own wallet, open your own positions and decide when to enter or exit. What makes Tribes different is everything around the trade: discovery, Calls, Tribes, shared activity and the record that gets built over time. * [Your wallet](/docs/trading/your-wallet): your wallet, your assets and your control. * [Finding markets](/docs/trading/finding-markets): discover markets through Scans, Tribes and shared activity. * [Opening a trade](/docs/trading/opening-a-trade): what happens when you place a trade. * [Assigning a trade to a Tribe](/docs/trading/assigning-a-trade-to-a-tribe): assign a trade to one Tribe so it can contribute to that Tribe's [Tribe Trades](/docs/core-concepts/tribe-trades), activity and performance. * [Spot trading](/docs/trading/spot-trading) and [Perpetuals](/docs/trading/perpetuals): the trading products available on Tribes. * [Fees](/docs/trading/fees): trading fees and how they are used. * [Supported networks](/docs/trading/supported-networks): the networks and markets available through Tribes. Trading involves risk, including the possible loss of the amount invested. Nothing on Tribes is financial advice or an offer to buy or sell any asset. # Opening a trade (/docs/trading/opening-a-trade) Opening a trade on Tribes is straightforward. You choose the market, set up the trade and decide whether you want to assign it to a Tribe. ### Choose the market [#choose-the-market] Start from a Scan, a Call, Tribe activity, Discover or your own search. ### Set up the trade [#set-up-the-trade] Choose the direction, size and any parameters available for that market. If you are trading from a Call, you can use the setup as context and decide how you want to enter the trade yourself. See [Calls](/docs/core-concepts/calls). ### Assign it to a Tribe [#assign-it-to-a-tribe] A trade can be assigned to one Tribe, or to none. When you assign it to a Tribe, the trade can contribute to that Tribe's activity, statistics and performance. See [Assigning a trade to a Tribe](/docs/trading/assigning-a-trade-to-a-tribe). ### Review and confirm [#review-and-confirm] Review the trade details, including the market, position size, fees and any other relevant execution information before confirming. The trade is then executed from your own non-custodial wallet. See [Fees](/docs/trading/fees). ### Manage the position [#manage-the-position] Once the trade is open, you manage the position from your wallet. You decide when to add, reduce or close the position based on the options available for that market. ## Trading from a Call [#trading-from-a-call] A Call gives you a direct path from an idea to the market. When you receive a Call, you can open it, review the setup and market information, join the discussion and move directly into the trading flow. You still choose how you want to trade it. If you assign your trade to the Tribe, your position can become part of the shared [Tribe Trade](/docs/core-concepts/tribe-trades) and contribute to the Tribe's performance. Trading involves risk and you can lose the amount you trade. Calls, Scans and Tribe activity provide context and should not be treated as financial advice. # Perpetuals (/docs/trading/perpetuals) A perpetual future, or perp, is a contract that tracks the price of an asset without an expiry date. Perpetuals let you take a long or short position and can include leverage. Tribes supports perpetuals alongside spot trading. ## On Tribes [#on-tribes] * A perp position is opened and managed by you. * A perp trade can be assigned to one Tribe, or to none. * Assigned positions can contribute to that Tribe's activity, statistics and performance. * Trading fees apply to perpetuals executed through Tribes. See [Fees](/docs/trading/fees). ## Perpetuals with a Tribe [#perpetuals-with-a-tribe] If you assign a perp trade to a Tribe, the position remains yours while its result can become part of the Tribe's shared trading record. If other members are trading the same market and assigning their positions to the same Tribe, that activity can be brought together in a [Tribe Trade](/docs/core-concepts/tribe-trades). Members can still have different entries, leverage, position sizes and exits. Leverage increases both potential gains and potential losses. A leveraged position can be liquidated, and you can lose the full amount committed to the position. Perpetuals are not suitable for everyone. Available markets, leverage limits, funding, margin requirements, liquidation rules and the trading venue used for perpetuals. See [What is not final yet](/docs/getting-started/not-yet-final). # Spot trading (/docs/trading/spot-trading) Spot trading means buying or selling the asset itself. When you buy a spot asset, you hold that asset in your wallet. When you sell it, you sell the asset you already hold. Tribes supports spot trading for crypto assets. ## On Tribes [#on-tribes] * Every spot trade is opened from your own non-custodial wallet. * A spot trade can be assigned to one Tribe, or to none. * Assigned trades can contribute to that Tribe's activity, statistics and performance. * Trading fees apply to spot trades executed through Tribes. See [Fees](/docs/trading/fees). ## Spot trading with a Tribe [#spot-trading-with-a-tribe] If you assign a spot trade to a Tribe, the position remains yours while its result can become part of the Tribe's shared trading record. If other members are trading the same asset and assigning their trades to the same Tribe, that activity can be brought together in a [Tribe Trade](/docs/core-concepts/tribe-trades). Supported assets, order types, minimum trade sizes and network availability will be documented as they are finalised. See [Supported networks](/docs/trading/supported-networks). # Supported networks (/docs/trading/supported-networks) Tribes is built to make trading across multiple networks feel simple. You choose the market. Tribes handles the network context behind it. ## Supported networks [#supported-networks] Tribes supports: * Solana * Base * BNB Chain * Monad * Robinhood Chain * Ethereum * Arc The assets and markets available on each network can differ. ## One trading experience [#one-trading-experience] You do not need to think about Tribes as a separate app for every chain. Markets from supported networks can live inside the same trading experience, alongside Tribes, Calls, activity and your wallet. The goal is simple: **We handle the chains. You focus on the market.** ## Network availability [#network-availability] Not every asset, trading product or market type is necessarily available on every supported network. Availability can depend on: * the asset * liquidity * trading venue * market type * network support The relevant network and execution information is shown when you trade. # Your wallet (/docs/trading/your-wallet) Every user trades from their own non-custodial wallet. You control your assets and positions. Tribes does not hold or manage your funds, and joining a Tribe does not move your money or create a shared Tribe wallet. ## What that means [#what-that-means] * Your wallet is **non-custodial**. Tribes does not hold or control your assets. * Your funds are not split between different Tribes. * A Tribe does not hold a shared pool of member funds. * Each member opens and manages their own positions. * Joining or leaving a Tribe does not move your assets. * A trade can be assigned to one Tribe without moving the assets into a separate wallet. ## Trading with a Tribe [#trading-with-a-tribe] When you open a trade, you can assign it to one Tribe. Assigning a trade connects that position and its result to the Tribe's activity, statistics and history. The position itself stays in your wallet and remains fully under your control. For example, several members can trade the same market from their own wallets and assign those trades to the same Tribe. Their individual results can then be combined to show how the Tribe performed as a group. See [Assigning a trade to a Tribe](/docs/trading/assigning-a-trade-to-a-tribe). ## Your wallet, your positions [#your-wallet-your-positions] Calls, Scans and Tribe activity do not move funds by themselves. You decide when to open a position, how much to trade and when to exit. Wallet creation, recovery, supported assets, deposits and withdrawals. See [What is not final yet](/docs/getting-started/not-yet-final). # Battle history (/docs/tribe-battles/battle-history) Every completed Tribe Battle becomes part of the history of both participating Tribes. A Battle record can show who they faced, the Battle type, the duration, the final result and other verified information from the competition. ## What Battle history can show [#what-battle-history-can-show] A Battle record can include things such as: * opponent * Battle type * start and end time * final score * winner and loser * verified performance during the Battle * Battle-specific achievements Over time, this creates a competitive record for each Tribe. ## Part of Tribe reputation [#part-of-tribe-reputation] Battle history can contribute to how a Tribe is understood across Tribes. A Tribe with a long history of strong Battle performance can build a competitive identity alongside its trading history, rating and leaderboard position. Battle history is about what happened, not just the final score. ## A lasting record [#a-lasting-record] Completed Battles remain part of the Tribe's history. Results are not removed or rewritten simply because a Tribe lost. Invalid or manipulated activity can still be corrected through the integrity process where necessary. See [Verified history](/docs/reputation/verified-history). Information shown for each Battle, how Battle history affects ratings and how long-term Battle records are presented. See [What is not final yet](/docs/getting-started/not-yet-final). # Battle types (/docs/tribe-battles/battle-types) Tribe Battles can be configured in different ways depending on what the Tribes want to compete on. Every Battle has a defined duration and scoring format, so both Tribes know what counts before it begins. ## What can define a Battle [#what-can-define-a-battle] A Battle type can determine things such as: * which markets or market categories are eligible * how long the Battle runs * which trading activity contributes to the score * how performance is measured * any Battle-specific rules This makes it possible for different Battles to test different kinds of trading performance. ## Friendly Battles [#friendly-battles] Some Battles can be purely competitive. A Friendly Battle lets two Tribes compete without putting anything financial at stake. The result can still contribute to Battle history, reputation and competitive records. ## XP Battles [#xp-battles] Where supported, a Battle can also involve Tribe XP. The exact XP mechanics, including how XP is committed, won or distributed, depend on the final Battle rules. ## Clear rules before the start [#clear-rules-before-the-start] The Battle type, duration, eligible activity and scoring rules should be visible before either Tribe accepts the challenge. Once the Battle begins, the agreed rules determine what activity counts toward the result. See [Scoring](/docs/tribe-battles/scoring). Battle types, available durations, eligible market categories and XP mechanics. See [What is not final yet](/docs/getting-started/not-yet-final). # Challenges (/docs/tribe-battles/challenges) A Tribe Battle starts with a challenge from one Tribe to another. The challenging Tribe proposes the Battle, and the other Tribe can accept, decline or counter it. ## What a challenge can define [#what-a-challenge-can-define] A challenge can include things such as: * the opponent * the Battle type * the market or category * the duration * any Battle-specific rules Once both Tribes agree to the terms, the Battle can begin. ## Accept, decline or counter [#accept-decline-or-counter] The challenged Tribe does not have to accept the Battle as proposed. It can: * **Accept** the challenge * **Decline** the challenge * **Counter** with different terms A counter can change parts of the proposed Battle before both sides agree. ## Matchmaking [#matchmaking] Challenges can also connect to matchmaking and ratings, helping Tribes find opponents that make sense for the type of competition. Who can issue or accept challenges, how open challenges work, counter rules and any rating-based matchmaking. See [What is not final yet](/docs/getting-started/not-yet-final). # Tribe Battles (/docs/tribe-battles) Tribe Battles are time-bound competitions between two Tribes. They turn trading performance into a shared competitive experience, where Tribes can challenge each other and compare how they perform over the same period. ## What a Battle can involve [#what-a-battle-can-involve] Depending on the Battle type, Tribes can compete for: * reputation * rating * XP * leaderboard position * the result itself Battles are about performance and competition between Tribes. They are not a way for users to bet money against another Tribe. ## How a Battle works [#how-a-battle-works] 1. One Tribe challenges another. See [Challenges](/docs/tribe-battles/challenges). 2. The Battle is given a type, market scope and duration. See [Battle types](/docs/tribe-battles/battle-types). 3. Members trade from their own wallets and assign eligible trades to their Tribe. 4. Verified activity during the Battle contributes to the score. See [Scoring](/docs/tribe-battles/scoring). 5. When the Battle ends, a winner is determined and the result becomes part of both Tribes' history. See [Battle history](/docs/tribe-battles/battle-history). ## Built around the Tribe [#built-around-the-tribe] A Battle is won by the performance of the Tribe, not by one shared position. Members can trade different markets, use different position sizes and enter or exit at different times depending on the Battle rules. The scoring system is designed to reward strong trading performance without simply rewarding the biggest wallet or the highest leverage. ## Battle history [#battle-history] Battles create another layer of history between Tribes. Over time, a Tribe can build a record of: * Battles entered * wins and losses * opponents faced * Battle performance * competitive achievements That record can become part of the Tribe's reputation and competitive identity on Tribes. Battle types, scoring formulas, matchmaking rules, eligible markets and XP mechanics. See [What is not final yet](/docs/getting-started/not-yet-final). # Scoring (/docs/tribe-battles/scoring) A Tribe Battle is scored from verified activity that happens during the Battle period and is assigned to the participating Tribe. Only activity that meets the Battle rules contributes to the score. ## What can count [#what-can-count] Depending on the Battle type, scoring can take into account things such as: * verified trading results * Call performance * assigned trades * combined Tribe performance * participation from eligible members * Battle-specific performance metrics The exact inputs depend on the Battle format. ## Fair competition [#fair-competition] Battle scoring is designed to reward strong performance without simply rewarding the biggest wallet, the highest leverage or the largest Tribe. That means factors such as member count, position size and risk can be handled in a way that keeps Battles competitive between different kinds of Tribes. Participation can matter, but more activity should not automatically mean a better score. ## Verified activity only [#verified-activity-only] Battle results are based on attributable activity that can be validated. Trades that are not assigned to the Tribe, fall outside the Battle period or do not meet the Battle rules do not contribute to the score. See [Assigning a trade to a Tribe](/docs/trading/assigning-a-trade-to-a-tribe). Scoring formula, weighting, tie rules, member-count normalisation, risk adjustments and Battle-specific scoring methods. See [What is not final yet](/docs/getting-started/not-yet-final).