# Introduction to FLock.io FLock.io seeks to decentralise training and [value alignment](https://en.wikipedia.org/wiki/Reinforcement_learning_from_human_feedback). We ensure that AI objectives match the public’s ethics and societal aims, that decision-making falls to communities, and that usefulness is a top priority. FLock knocks down barriers impeding participation in the ecosystem. We allow developers to provide models, data, or compute in a modular way. The result: a plethora of fit-for-purpose models created by, for, and under the stewardship of the communities. Our incentivised platform democratises AI agent training, fine-tuning and inferencing. It halts user data collection, and enables equitable distribution of rewards and widespread governance. Leveraging blockchain technology and AI, FLock provides a powerful environment for dealing with large datasets. # The Centralisation Problem This year, Decentralised AI (dAI) has captured the industry spotlight. The [resignation](https://stability.ai/news/stabilityai-announcement) of Stability AI CEO Emad Mostaque highlighted this concern. His departure reflects a growing consensus that AI development should fall under the stewardship of a diverse global community. This followed a series of controversies in the governance of generative AI: deepfakes, the OpenAI boardroom fiasco, Gemini AI's data bias, and the Getty Images lawsuit against Stability AI. #### The problem with centralised control over AI creation The centralisation problem presents an overbearing barrier to AI innovation. Under the status quo, the world’s largest corporations hold sway over the trajectory of AI development based on their own objectives, which do not necessarily align with the public interest. The danger of AI being controlled by centralised corporations is that their biases and values are amplified on a global scale. They decide who gains access to the models, and their value alignment often downgrades the performance of models. We consequently see low public participation, less access to computing power, amplified data bias and inaccuracies from less and lower quality training data, and a missed opportunity for AI to realise its maximal potential as a force for good. There is a pressing need for an equitable distribution of rewards for those who help to refine these models.
# Architectural Breakdown {% hint style="success" %} Get started with decentralized training on AI Arena platform: [This way](https://train.flock.io/)! {% endhint %} This section provides a high-level overview of FLock's system, including its system design as well as its blockchain and AI layers. # System Design This section gives a high-level overview of FLock's system design. FLock's system logic is comprised of three major components, namely, AI Arena, FL Alliance and AI Marketplace.

Figure1. FLock's system logic.

As shown in Figure 1, upon a task creation, the model is first trained and validated in ***AI Arena***, a blockchain-based decentralised training platform, and then optionally further fine-tuned in ***FL Alliance*** using participants’ local data. Finally, the model is deployed by applications in the ***AI Marketplace***, where feedback will be used to further improve the model.

Figure2. FLock's system design.

Specifically, as shown in Figure 2, when a task is first created in AI Arena, it is first trained by training nodes. These nodes then submit their models to validators, who evaluate and propose scores for each submission. The validators reach a consensus on these scores to determine the ranking of the submitted models. The consensus model can then be assigned to FL clients, who fine-tune and improve it using their local data, resulting in the FL global model. The AI Arena consensus model or the FL global model can be deployed and hosted in the AI Marketplace, providing interfaces to various applications. AI Arena training nodes, validators and FL clients need to stake to participate the system, and will be rewarded based on their performance. # Blockchain Layer This section describes how the blockchain layer of FLock enhances both incentivisation and security. ## Incentivisation The blockchain layer plays a pivotal role in reward distribution. It ensures that participants can securely lock in their stakes, fostering an environment of trust and transparency. The process is designed to incentivise participation by allocating rewards based on contributions, thus encouraging a more engaged and active community. Through the use of smart contracts, the system automates the rewards process, making it both efficient and fair. This automation not only reduces the potential for human error but also ensures that rewards are distributed in a timely and fair manner. ## Security At FLock, we propose a generic framework that can integrate an FL system with a blockchain system and can defend against poisoning attacks without adopting complex cryptographic protocols, which is adopted from our peer-reviewed work [here](https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=\&arnumber=10471193). Specifically, FLock employs a proof-of-stake mechanism with the goal of ensuring robust security and consensus within the network. Such system enhances Byzantine fault tolerance by aligning participants' incentives with network integrity— those who act dishonestly or fail to reach consensus risk losing their staked tokens. This economic disincentive promotes honest behaviour, ensuring the network remains secure and reliable. The table below describes how FLock mitiagtes vairous types of risks which could occur in decentralised training platforms. | Attacks | Description | FLock Mitigation | | -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Sybil Attacks | An attacker might gain disproportionate influence in the FLock system by creating and controlling multiple fake identities of participants. | | | DoS Attacks | An attacker might exhaust the FLock system resource and make it unavailable to honest participants. | | | Free-rider Attacks | Free riders benefit from a system without contributing fairly. In the FLock system, a free rider training node may randomly submit models without actuall training. Similarly, free rider validators give random scores instead of honestly evaluating models. | | | Lookup Attacks | Training nodes could cheat by learning to predict past validation score calculations. | | | FL Model Poisoning Attacks | In FL Alliance, an attacker may use biased or corrupted data during the training process to degrade the model's performance. | | # AI Layer ## AI Arena AI layer supports a conventional machine learning (ML) model training paradigm, optimising mod- els directly on users’ devices with their own or public data. To maximise the generalisation ability and performance of the final trained models, this layer is designed to encourage community members to contribute various public or local data, harnessing the broader community’s power. By leveraging blockchain, it ensures contributors are continually engaged and rewarded based on the quantifiable impact of their data on improving the models. ## FL Alliance Ultilising Federated Learning (FL) approach, the AI layer enables thousands of participants to collaboratively train a global model, where data sovereignty is preserved by ensuring that no local data are transmitted at any stage of the training process. Within the AI layer, a model aggre- gation component allows participants to upload weights from models trained on their unique local data. These weights are then aggregated to build an optimal global model, enhancing its generalisation capabilities and performance. The integration of training task automation and deployment orchestration components simplifies the process for users to join tasks and contribute valuable knowledge extracted from their data. ## AI Marketplace Once models are trained and fine-tuned through AI Arena and FL Alliance, they can be hosted on our platform. This platform serves as a comprehensive environment for deploy- ing ML models, making them accessible within blockchain networks of virtual machines (VMs). By integrating with these networks, the platform facilitates the seamless execution and inference of complex ML models, providing real-time, scalable, and secure solutions. # AI Arena Onboarding guide for AI Arena, a pioneer decentralised AI training platform AI Arena is FLock.io's decentralised AI training platform. Through train.flock.io, the AI Arena gateway, users can stake FLOCK, FLock.io's token deployed on Base, in order to participate and earn staking rewards. There are four ways to participate: * Task Creators\*: Define desired models and submit tasks to the platform * Training Nodes: Develop or finetune models required by task creators * Validators: Evaluate the models submitted by training nodes * Delegators: Delegate tokens to training nodes and validators, increasing reward distribution *\*Currently all tasks are created by the FLock.io team. We will open up task creation to the community in the coming months.* # Participants This section describes the roles played by various participants in AI Arena. ## Training Nodes Training nodes are responsible for training models and are required stake tokens to be eligible. This requirement ensures a commitment to the network’s integrity and facilitates a distributed, trust-based mechanism for task assignment. This stake acts both as a gatekeeper to maintain a high standard and as a foundational element in the network’s security protocol, ensuring that nodes have a vested interest in proper execution and the overall health of the ecosystem. ## Validators Validators are responsible for evaluating work done by training nodes, submitting validation scores that influence reward distribution. They participate by staking tokens, which grants them the opportunity to validate tasks assigned to them, ensuring hardware compatibility and fair task distribution proportional to their stake. Upon completion of a task, they can withdraw heir stake and claim rewards, which are calculated based on their performance and adherence to the expected outcomes. The design ensures that validators are incentivised to provide accurate and honest validations, thereby maintaining the quality and reliability of the network’s computational tasks. ## Delegators\* Delegators contribute to the FLock system by supporting other participants’ staking process, enhancing the network’s validation capacity without directly participating in the task training or validation process. Delegators share in the rewards earned by their associated delegatees, based on predefined algorithms that account for their staked contribution. This role allows individuals to participate in the network’s training, validation and economic activities, leveraging their tokens to support delegatees, without needing the technical capabilities to train or validate tasks themselves. Note that training nodes and validators who choose to accept delegation are free to choose a reward share ratio. The higher the ratio, the bigger the reward share their delegators will receive. FLock.io acts solely as a facilitator in the delegation process. The platform provides the technical infrastructure to enable interactions between delegators and delegatees within the ecosystem. FLock.io DOES NOT: * Act as a financial advisor or provide recommendations on delegation decisions. * Influence or control the actions, performance, or decisions of delegators or delegatees. * Guarantee any specific outcomes or returns for delegators. FLock.io disclaims all liability for any losses, damages, or issues arising from: * Mismanagement by delegatees, including, but not limited to, poor decision-making or unethical behavior. * Token slashing penalties incurred by delegatees. * Technical errors, delays, or malfunctions in the delegation process. Delegator Responsibilities: * Risk Acknowledgment: By participating, delegators accept all risks associated with delegation, including the loss of rewards or tokens due to delegatee actions or network vulnerabilities. * Independent Decision-Making: delegators are responsible for selecting delegatees and must conduct their own research before staking tokens. * Compliance: Delegators must comply with all applicable laws and regulations in their jurisdiction. Delegatee Responsibilities: * Reward Share Ratio Transparency: Delegatees must disclose their reward share ratio before accepting stakes and adhere to it consistently. This ratio is entirely determined by the delegatee, and FLock.io does not control or operate it. * Risk Disclosure: Delegatees must inform delegators of potential risks, including slashing penalties or other network-related risks. * Compliance: Delegatees must comply with all applicable laws and regulations in their jurisdiction. \*Note that the delegation function may not be available in some regions due to local regulations. # Quickstart Follow the steps in the following sections to participate in AI Arena. # Pre-requisites Requirements for decentralised AI training participation ## Set up requirements checklist * [ ] A Web3 Wallet - You will use this to connect to the web app at [train.flock.io](https://train.flock.io) * [ ] ETH on Base mainnet for gas fees * [ ] gmFLOCK tokens which can be converted from \[LINK] {% hint style="info" %} After you've joined the platform, head over to our [discord server](https://discord.com/invite/ay8MnJCg2W). To access the developer channels, you can verify your wallet in the [#ai-arena-role](https://discord.com/channels/977200106531082240/1254731167543070831) channel. {% endhint %} # WSL installation To install Conda in WSL (Windows Subsystem for Linux), you can follow these steps: #### Step 1: Install WSL and Set Up a Linux Distribution You can find [Ubunto(WSL) ](https://apps.microsoft.com/detail/9pdxgncfsczv?rtc=1\&hl=en-gb\&gl=GB)in Microsoft store #### Step 2: Download and Install Miniconda or Anaconda You can choose to install either Miniconda (a minimal installer for Conda) or Anaconda (a larger distribution including many scientific packages). **Install Anaconda** 1. Open your WSL terminal. 2. Download the Anaconda installer script using `wget` or `curl`: ```bash wget https://repo.anaconda.com/archive/Anaconda3-latest-Linux-x86_64.sh ``` 3. Run the installer script: ```bash bash Anaconda3-latest-Linux-x86_64.sh ``` 4. Follow the prompts during the installation. Accept the license agreement, specify the installation path (default is usually fine), and choose whether to initialize Anaconda. 5. Initialize Conda (if not done during installation): ```bash source ~/anaconda3/bin/activate ``` 6. Update Conda to the latest version: ```bash conda update conda ``` #### Step 3: Verify Installation 1. Close and reopen your WSL terminal or run the following command to activate Conda: ```bash source ~/.bashrc ``` 2. Verify that Conda is installed and working correctly: ```bash conda --version ``` You should see the Conda version printed in the terminal, indicating that Conda has been successfully installed. By following these steps, you will have Conda installed and ready to use in your WSL environment. # Delegator Guide How to delegate your gmFLOCK to training and validation nodes Delegators contribute to the FLock system by supporting other participants’ staking process, enhancing the network’s validation capacity without directly participating in the task training or validation process. Delegators stake `gmFLOCK`on behalf of other participants, and earn rewards in return. {% hint style="info" %} Note that the delegation function may not be available in some regions due to local regulations. {% endhint %} ### Step 0: Go to and connect your wallet. Navigate to . There, connect your wallet.

Step 0.1: Connect wallet

You will see a variety of wallets to choose from. Pick your favourite wallet there, agree terms of use and proceed.

Step 0.2: Choose wallet and agree to terms of use

{% hint style="info" %} If this is the first time you connect this wallet to train.flock.io, you may need to sign a transaction in order to connect your wallet successfully. {% endhint %} ### Step 1: Choose a wallet to delegate to. On the "Stake to Earn" tab, you will see a list of wallet addresses with their respective Delegator estimated Annual Percentage Yield (eAPY), Reward-sharing ratio, Total stake and Weekly Delegation Growth associated with the given address:
{% hint style="info" %} Note: In the new delegation pool update, for training nodes, the delegation pool will freeze 1 day before the end of training stage of a task till 1 day after the results have been finalised i.e. the pool will not be able to receive new delegation during that phase. {% endhint %} #### Understanding the Delegator eAPY (estimated Annual Percentage Yield) In order to make the delegator returns easy to understand, we display eAPY based on the previous rolling 14d and 30d returns of nodes. Those nodes which do not have a 14d history are highlighted separately. We use the following formula to calculate the 14d rolling eAPY If this wallet has delegator stake to him and pool is older then 7 days $$ R\_t = \sum\_{i=1}^{n} \frac{\text{RewardShareRatio}\_i \cdot \text{DelegatorPoolReward}\_i(\text{address})}{n\cdot \text{delegatorStake}\_i(\text{address})} $$ $$ \text{Delegator eAPY} = (1 + R\_t)^{365} - 1 \approx R\_t \cdot 365 $$ Else $$ R\_t = \sum\_{i=1}^{n} \frac{{\text{RewardShareRatio}\_i}\cdot \text{Reward}\_i(\text{address})}{n\cdot \text{stake}\_i(\text{address})} $$ $$ \text{Delegator eAPY} = (1 + R\_t)^{365} - 1 \approx R\_t \cdot 365 $$ \*if the delegator pool is less than 14 days (say 11 days), then n=11 ### Step 2: Approve gmFLOCK transaction. Click on the wallet you would like to stake gmFLOCK to. You will then see a pop-up, in which you can insert the amount of gmFLOCK you intend to delegate. Click "Approve FLOCK" to confirm this transaction:

Step 3: Approve gmFLOCK for staking

Step 3: Stake gmFLOCK. Once you approve the gmFLOCK transaction, you will see another pop-up. Click "Stake gmFLOCK" to confirm staking transaction:
### Step 4: Withdraw stake and Claim Reward. You will see all your delegated stake on: . You can withdraw your stake **one day after your delegation**. The rewards are distributed to the delegation pool daily at **midnight UTC.** You can claim your rewards **anytime** as long as there's rewards claimable for you.
# Training Node Guide How to stake and submit a Training Task This guide provides step-by-step instructions for the entire Training Node workflow. By the end you will have successfully staked as a Training Node, completed a training task, and claimed your staking rewards. {% hint style="info" %} Be sure you have completed all pre-requisite tasks. {% endhint %} {% hint style="warning" %} You can only be either training node OR validator for each task. {% endhint %} ### 0. Navigate to [train.flock.io](https://train.flock.io/) and connect you wallet. Follow the steps [here](https://docs.flock.io/flock-products/ai-arena/quickstart/pages/628PqLScceINNZRrYVWa#step-0-go-to-https-train.flock.io-stake-to-earn-and-connect-your-wallet) to connect your wallet. ### 1. Stake gmFLOCK as Training Node from [train.flock.io](https://train.flock.io/) 1. Once you have gmFLOCK tokens, Navigate to the Training Node tab on the Stake page 2. Select a training task 3. Stake gmFLOCK
Once you’ve confirmed and approved the transaction in your web3 wallet, you will see a box on the Training Node tab with your stake details.
### 2. Accept delegator Note that you have the option to accept delegator. To do so, go to "Accept Delegator" tab. Select your profit-sharing ratio, then click "Create Delegation Contract":
Once the transaction is completed. You have the option to add a profile and a profile picture, as well as to modify your profit-sharing ratio here:
{% hint style="info" %} You can only modify your rewards-sharing ratio once per month. {% endhint %} ### 3. Get API key Your API key is required for all remaining Validator steps. You can get it from the web app.
1. Select dropdown in upper right corner of web app 2. Select API 3. On the API page, copy your API key Once you have your API key, you can proceed to the next step. {% hint style="info" %} NOTE: If you have issues generating an API key try removing any ad blocker extensions and/or clearing your cookies. {% endhint %} ### Video Tutorial {% embed url="" %} ### 4. Set up your environment #### Windows For Windows users, we suggest installing WSL. Follow the guidance: [WSL installation](/flock-products/ai-arena/quickstart/pre-requisites/wsl-installation) #### Mac/Linux You can install Anaconda via [HERE](https://www.anaconda.com/download/success) ### 5. Clone the QuickStart repo The [quickstart repo](https://github.com/FLock-io/testnet-training-node-quickstart.git) contains everything you need to run our [`full_automation.py`](https://github.com/FLock-io/testnet-training-node-quickstart/blob/main/full_automation.py) script. To clone it run: ``` git clone https://github.com/FLock-io/testnet-training-node-quickstart.git ``` To set up all packages within the project directory ``` conda create -n training-node python==3.10 conda activate training-node pip install -r requirements.txt ``` {% hint style="info" %} **File Structure** * [`dataset.py`](https://github.com/FLock-io/testnet-training-node-quickstart/blob/main/dataset.py) - Contains the logic to process the raw data from `demo_data.jsonl`. * [`demo_data.jsonl`](https://github.com/FLock-io/testnet-training-node-quickstart/blob/main/demo_data.jsonl) - Follows the shareGPT format. The training data you receive from the `fed-ledger` is in exactly the same format. * [`merge.py`](https://github.com/FLock-io/testnet-training-node-quickstart/blob/main/merge.py) - Contains the utility function for merging LoRA weights. If you are training with LoRA, please ensure you merge the adapter before uploading to your Hugging Face repository. * [`demo.py`](https://github.com/FLock-io/testnet-training-node-quickstart/blob/main/demo.py) - A training script that implements LoRA fine-tuning for a Gemma-2B model. {% endhint %} ### 6. Get information required to run automation script The script described in the following step automates the following: * Gets a task * Downloads the training data * Finetunes Gemma-2B on training data * Merges weights * Uploads to your Hugging Face model repo * Submits the task to `fed-ledger` To run it, you will need: * `TASK_ID` - the id of the task you are staking on as Training Node * `FLOCK_API_KEY` - available at * `HF_TOKEN` - your Hugging Face Access Token (Hugging Face > Profile > Settings > Access Tokens) * `HG_USERNAME` - your Hugging Face user name {% hint style="info" %} NOTE: If you haven't already done so, please acknowledge license to access Gemma on Hugging Face: {% endhint %} ### 7. Run full automation script Once you have all the information listed in the previous step, paste the script below into your terminal, update the repsective values, and run the command. {% tabs %} {% tab title="Unix/Linux" %} {% code overflow="wrap" %} ``` TASK_ID= FLOCK_API_KEY="" HF_TOKEN="" CUDA_VISIBLE_DEVICES=0 HF_USERNAME="your-hf-user-name" python full_automation.py ``` {% endcode %} {% endtab %} {% tab title="CMD" %} ``` set TASK_ID= && set FLOCK_API_KEY="" && set HF_TOKEN="" && set CUDA_VISIBLE_DEVICES=0 && set HF_USERNAME="your-hf-user-name" && python full_automation.py ``` {% endtab %} {% tab title="PowerShell" %} ``` $env:TASK_ID = "" $env:FLOCK_API_KEY = "" $env:HF_TOKEN = "" $env:CUDA_VISIBLE_DEVICES = "0" $env:HF_USERNAME = "your-hf-user-name" python full_automation.py ``` {% endtab %} {% endtabs %} {% hint style="info" %} NOTE: Tasks can be completed with any [supported base LLM model](https://github.com/FLock-io/llm-loss-validator/blob/main/src/core/constant.py). The only restriction is `max_param.`You can use any technique to train or fine-tune a model, all you need to make sure is that the model can be successfully run by our [validation script](https://github.com/FLock-io/llm-loss-validator/tree/main). {% endhint %} ### 8. Claim rewards Reward distribution is triggered every 24 hours at midnight UTC. The final round of reward distribution is triggered at the once the task training period is complete. You can claim your rewards via [train.flock.io](https://train.flock.io). # Validator Guide How to stake and validate tasks as a Validator This guide provides step-by-step instructions for the entire Validator workflow. By the end you will have successfully staked as a Validator, requested task assignment(s), run a validator script, uploaded loss score(s), and claimed your staking rewards. {% hint style="info" %} Be sure you have completed all pre-requisite tasks. {% endhint %} {% hint style="warning" %} You can only be either training node OR validator for each task. {% endhint %} ### 0. Navigate to [train.flock.io](https://train.flock.io/) and connect you wallet. Follow the steps [here](https://docs.flock.io/flock-products/ai-arena/quickstart/pages/628PqLScceINNZRrYVWa#step-0-go-to-https-train.flock.io-stake-to-earn-and-connect-your-wallet) to connect your wallet. ### 1. Stake gmFLOCK as Validator from [train.flock.io](https://train.flock.io/) In order begin receiving validation assignments, you must stake gmFLOCK to a task at train.flock.io.
1. Navigate to the Validator tab on the Stake page 2. Select task to validate 3. Stake gmFLOCK Once you’ve confirmed and approved the transaction in your web3 wallet, you will see a box on the Validator tab with your stake details.
### 3. Accept delegator Note that you have the option to accept delegator. To do so, go to "Accept Delegator" tab. Select your profit-sharing ratio, then click "Create Delegation Contract":
Once the transaction is completed. You have the option to add a profile and a profile picture, as well as to modify your profit-sharing ratio here:
{% hint style="info" %} You can only motify your rewards-sharing ratio once per month. {% endhint %} ### 4. Get API key Your API key is required for all remaining Validator steps. You can get it from the web app.
1. Select dropdown in upper right corner of web app 2. Select API 3. On the API page, copy your API key Once you have your API key, you can proceed to the next step. {% hint style="info" %} NOTE: If you have issues generating an API key try removing any ad blocker extensions and/or clearing your cookies. {% endhint %} ### Video Tutorial {% embed url="" %} ### 5. Set up your environment To set up your environment, run the following commands: #### Windows For Windows users, we suggest installing WSL. Follow the guidance: [WSL installation](/flock-products/ai-arena/quickstart/pre-requisites/wsl-installation) #### Mac/Linux You can install Anaconda via [HERE](https://www.anaconda.com/download/success) ### 6. Clone the Validator Repo The [validator](https://github.com/FLock-io/llm-loss-validator) repo contains everything you need to run our script. To clone it run: ``` git clone https://github.com/FLock-io/llm-loss-validator.git ``` To set up all packages within the project directory ``` conda create -n llm-loss-validator python==3.10 conda activate llm-loss-validator pip install -r requirements.txt ``` ### 7. Run Validation Script Now that you have staked as a Validator and have your API key you can run the validation script by running the following loop in your command line: {% tabs %} {% tab title="Unix/Linux with Nvidia GPU" %} ```bash cd /src CUDA_VISIBLE_DEVICES=0 \ bash start.sh \ --hf_token your_hf_token \ --flock_api_key your_flock_api_key \ --task_id your_task_id \ --validation_args_file validation_config.json.example \ --auto_clean_cache False ``` {% endtab %} {% tab title="Unix/Linux CPU only" %} ```bash cd /src bash start.sh \ --hf_token your_hf_token \ --flock_api_key your_flock_api_key \ --task_id your_task_id \ --validation_args_file validation_config_cpu.json.example \ --auto_clean_cache False ``` {% endtab %} {% tab title="WSL" %} ``` cd /src set CUDA_VISIBLE_DEVICES=0 wsl bash start.sh \ --hf_token your_hf_token \ --flock_api_key your_flock_api_key \ --task_id your_task_id \ --validation_args_file validation_config.json.example \ --auto_clean_cache False ``` {% endtab %} {% tab title="PowerShell" %} ``` cd /src $env:CUDA_VISIBLE_DEVICES=0 powershell -File .\start.ps1 ` -hf_token ` -flock_api_key ` -task_id ` -validation_args_file validation_config.json.example ` -other_args @("--auto_clean_cache", "False") ``` {% endtab %} {% endtabs %} * `CUDA_VISIBLE_DEVICES=0`: Specifies which GPU to use. `0` indicates the first GPU. Adjust this based on your available GPUs. Remove this line if you are using just the CPU * `--hf_token`: Your Hugging Face token, required for accessing certain models. This should token should have write access. * `--flock_api_key`: Your FLock API key. * `--task_id`: The ID of the task you want to validate. If you are validating multiple tasks, you can pass a list eg. if you are validating tasks 8 and 9, you can pass `--task_id 8,9` * `--validation_args_file`: The path to the validation arguments file. * `--auto_clean_cache`: A flag to determine whether to automatically clean the model cache. * `--lora_only`: A flag to indicate whether to validate only repositories with LoRA (Low-Rank Adaptation) weights. `True` means only LoRA weights will be validated. This is useful for validators with limited network bandwidth, as LoRA weights are significantly smaller (10-500 MiB) compared to full model files (>10 GiB) {% hint style="info" %} NOTE: If you would like to customise your validation script, visit this repo and check out **How to run validation script** section Make sure the `HF_TOKEN` you passed in have access to the gated base models like `gemma`, `llama2`, and `llama3` to succesfully validate models fine-tuned based on those. Links: {% endhint %} ### 8. Claim rewards Reward distribution is triggered every 24 hours at midnight UTC. You can claim your rewards via the web app. Once you’ve connected your web3 wallet to train.flock.io, you can claim rewards with the following steps: 1. Navigate to the Validator tab on the Stake page 2. Verify you have FLOCK available to claim for the task you are staking 3. Click Claim FLOCK
Once you’ve approved the transaction in your web3 wallet you will see a dialogue box confirming your claim. Congratulations! You’ve successfully completed the entire validator workflow. # gmFLOCK What is gmFLOCK and how to get them In order to participate in AI Arena, you will need to use gmFLOCK (game-FLOCK), which is a market-driven mechanism designed to support AI Arena's tokenomics and emission allocation model. It is transferable, but with restrictions: it can only be used for staking as training nodes, validators, or delegators. ### Step 0: Navigate to [train-v2.flock.io](https://train-v2.flock.io/) and connect you wallet. Follow the steps [here](https://docs.flock.io/flock-products/ai-arena/pages/628PqLScceINNZRrYVWa#step-0-go-to-https-train.flock.io-stake-to-earn-and-connect-your-wallet) to connect your wallet.\ (During the migration phase, we would use `train-v2.flock.io` for V2, and will maintain `train.flock.io` for sometime so that everyone can claim and unstake from V1 easily. After the migration phase, we would re-direct all traffic to `train.flock.io` and it will be upgraded to V2.) ### Step 1: Stake FLOCK to get gmFLOCK Here, you decide the amount of FLOCK you want to stake to get gmFLOCK and the duration of the stake {% hint style="info" %} For every 1 FLOCK staked, you will receive 1 gmFLOCK for staking between 0-30 days. For each additional day before that, you will receive an extra 0.006 gmFLOCK {% endhint %} {% hint style="info" %} NOTE: You will receive gmFLOCK as soon as you stake FLOCK. Once the staking period is reached, you may withdraw your staked FLOCK with a transaction fee of 5.13%. The fee remains the same irrespective of the duration of the stake {% endhint %}

Step 1.1: Decide the amount of FLOCK to stake and the stake period

After that, click on "Stake", approve the transaction in the wallet and you've successfully staked FLOCK for gmFLOCK. #### Formulae for exchanging FLOCK with gmFLOCK If a user deposits $$n$$ FLOCK into the gmFLOCK Faucet and chooses a vesting time of $$t$$ days $$(0< t \le t\_1)$$to unlock the tokens, then the number of gmFLOCK minted, $$m$$, is: * if $$0< t \le t\_0$$: $$m=n$$ * if $$t\_0< t \le t\_1$$: $$m = n \times (1+ \epsilon \times \frac{t-t\_0}{t\_1})$$ where $$t$$, $$t\_0$$ and $$\epsilon$$ are the parameters that can be configured by FLOCK DAO. today, $$t\_0=30 days, t\_1=365 days, \epsilon=2.19$$ You can see all your stakes under "My Staking History"

1.2 You can see all your stakes

### Step 2: Use gmFLOCK Now that you have gmFLOCK by staking FLOCK, you can use it to stake as a [Delegator](/flock-tokenomics/network-participation/ai-arena/delegator), [Validator](/flock-products/ai-arena/quickstart/validator-guide) or a [Training Node ](/flock-products/ai-arena/quickstart/training-node-guide) ### Step 3: Redeem FLOCK After the stake period has ended, you can choose to exchange gmFLOCK for FLOCK. Click on "Redeem" under My Staking History {% hint style="info" %} NOTE: The amount of FLOCK you receive upon redemption is equal to your original staked FLOCK, minus a fixed 5.13% transaction fee. The redemption amount is not affected by the staking duration or the amount of gmFLOCK minted. {% endhint %}

Step 3.1: You can see the Stakes which are avaialble to Redeem

Select all the stakes that you would like to redeem and click on "Redeem". At this stage, you've successfully exchanged gmFLOCK for FLOCK! # Task Lifecycle Deep-dive This section offers a deep-dive into a cycle of an AI Arena Task.

Figure3. Workflow of an AI Arena Task.

## 1. Task Creation Task creation is the primary stage of the training cycle. Task creators define the desired models and submit tasks to the platform. To qualify as a task creator, users must meet one or more of the following criteria: • Stake a sufficient amount of FLOCK • Have successfully trained or validated a task previously, as evidenced by on-chain records • Possess a reputation in the ML space or be recognised as a domain expert in relevant fields, as verified by the FLock community ## 2. Training Node and Validator Selection Each participant is required to stake in order to participate either as a training node or a validator. Also, rate limiting is adopted to determine the number of times participants can be eligible as validator for a given task. Essentially, the likelihood of a participant being selected to validate a task submission increases with their stake. However, the rate at which validation frequency increases relative to the staking amount tends to diminish as the staking amount grows. ## 3. Training Each training node is given $$\mathcal{D}{\text{local}}$$*, which contains locally sourced data samples, comprising feature set* $$X$$ *and label set* $$Y$$*, with each sample* $$x\_i \in X$$ *corresponding to a label* $$y\_i \in Y$$*. The goal of training is to define a predictive model* $$f$$*, which learns patterns within* $$\mathcal{D}{\text{local}}$$ such that $$f(x\_i) \approx y\_i$$. To quantify the success (i.e. ability to predict) of the predictive model $$f$$, we introduce a loss function $$L(f(x\_i), y\_i)$$, assessing the discrepancy between predictions $$f(x\_i)$$ and actual labels $$f(y\_i)$$. A generic expression for this function is: $$\begin{equation\*} L = \frac{1}{N} \sum\_{i=1}^{N} l(f(x\_i), y\_i) \end{equation\*}$$ where $$N$$ denotes the total sample count, and $$l$$ signifies a problem-specific loss function, e.g., mean squared error or cross-entropy loss. Ultimately, the optimisation goal of training is to adjust the model parameters $$\theta$$ to minimise $$L$$, typically through algorithms such as gradient descent. ## 4. Validation After the training node produces a trained model $$\theta^{task}*p$$, a selected group of validators, denoted as $$V\_j \in V$$, each equipped with the evaluation dataset $$\mathcal{D}*{\text{eval}}$$ from the task creator, will validate the model. The dataset consists of pairs $$(x\_i, y\_i)$$, where $$x\_i$$ represents the features of the $$i-th$$ sample, and $$y\_i$$is the corresponding true label. To assess the performance of the trained model, we use an general evaluation, which is calculated as follows: $$ \begin{equation\*} eval(\theta^{task}p, \mathcal{D}{\text{eval}}) = \frac{1}{|\mathcal{D}{\text{eval}}|} \sum{(x\_i, y\_i) \in \mathcal{D}\_{\text{eval}}} \mathbf{1}(\hat{y}\_i = y\_i) \end{equation\*} $$ Here, $$\mathbf{1}$$ represents the indicator function that returns 1 if the predicted label $$\hat{y}i$$ *matches the true label* $$y\_i$$*, and* $$0$$ *otherwise. The function* $$|\mathcal{D}{\text{eval}}|$$ denotes the total number of samples within the evaluation dataset. Each predicted label $$\hat{y}\_i$$ from the model $$\theta^{task}p$$ *is compared against its corresponding true label* $$y\_i$$ *within the dataset* $$\mathcal{D}{\text{eval}}$$. The calculated metric result (accuracy here) serves as a quantifiable measure of $$\theta^{task}\_p$$'s effectiveness at label prediction across the evaluation dataset. # Smart Contracts Deep-dive This page gives detailed explanation of AI Arena's smart contracts.

AI Arena Smart Contracts Interactions.

## **Protocol Fee Model** Within the reward-distribution flow, the protocol applies a fee when users claim rewards denominated in **FLOCK**. This fee helps sustain ongoing network operations, security, and ecosystem development. The fee model distinguishes between two major participant groups to reflect their different roles in the protocol: * **Training Nodes & Validators:**\ Claims incur an **8% protocol fee**. * **Delegators:**\ Claims incur a **14.5% protocol fee**. ## Core Contracts ### `AdminUpgradeable.sol` **Role**: Base class that provides admin rights and other access-related methods. * Inherits `AccessControlUpgradeable` from OpenZeppelin. * Exposes `onlyAdmin` modifier and `isAdmin` checks. * Allows flexible role management for upgradeable contracts. ### `FlockMiniPool.sol` **Role**: Represents a “mini pool” that supports user delegation, tracks delegations, calculates claimable rewards, and interacts with the protocol’s managers. * Uses mappings to track each delegator’s stake, claims, temporal stakes, etc. * Integrates with `FlockConfig` for config references, calls back into `FlockPoolManager` and `FlockMainManager`. ### `FlockPoolManagerUpgradeable.sol` **Role**: Manages the creation and configuration of `FlockMiniPool` instances. * Tracks all active pools in sets, plus each user’s associated mini pool. * Maintains system-wide parameters (e.g., min/max Sigma, protocol fees). * Acts as a factory for creating new mini pools: `createMiniPool(...)`. * Handles callbacks to update delegations in a user’s mini pool. ### `FlockStakeInfoUpgradeable.sol` **Role**: Central ledger for all stakes across tasks. * Maintains stake amounts, weights, and distribution logic for nodes, validators, and delegators. * Relies on `FlockConfig` references to connect to other managers (e.g. main manager, pool manager). * Example responsibilities include: * `addStakes()` / `removeStakes()`: Called by the main manager to adjust totals. * `taskStakes[]`, `taskWeights[]`: Summaries for each task’s stake distribution. * “Re-tallying” delegations to keep stake info up to date. ### `FlockTaskManagerUpgradeable.sol` **Role**: Orchestrates tasks in the system. * Maintains references to each task (node stakes, validator stakes, distributions). * Aggregates daily minted rewards from `FlockToken`, then calculates how to distribute among nodes, validators, and delegators. * Offers hooks like `afterDelegationUpdate(...)` so that the pool manager can re-tally the user’s delegation. ### `FlockTokenUpgradeable.sol` **Role**: The upgradeable ERC20 for the entire protocol. * Allows “mint” and “burn” operations. * Implements a blacklist mechanism to restrict malicious actors. * Has “admin” only calls for minting, daily mint limits, etc. * Used as the currency for all staking, delegation, and reward flows. ## Libraries ### `LibABDKMathQuad.sol` **Role**: Quadruple-precision (128-bit) floating-point math. * Based on the [ABDK Consulting library](https://github.com/abdk-consulting/abdk-libraries-solidity), enabling IEEE 754-compatible operations with 16-byte `bytes16` floats. * Key functionalities include: * Converting between `int256`/`uint256` and quad precision. * Arithmetic ops (`add`, `sub`, `mul`, `div`). * Logarithms, exponentiation, square roots. * Used when standard fixed-point or 256-bit integer math is insufficient for advanced computations (such as extremely precise reward calculations). ### `LibFlockTask.sol` **Role**: Utility library for certain math and pseudo-randomness within tasks. * Wraps `LibABDKMathQuad` logic for simpler usage in multiplication/division scenarios. * Provides a “random” function (`rand()`), which generates a random number using block/transaction properties. ### `LibMath.sol` **Role**: Additional numeric utilities, focusing on n-th root calculations. * Provides the function `nthRoot()` which approximates the n-th root of a given number. * Useful for advanced arithmetic or reward distribution models needing, for example, “square root” or other root-based weighting logic. # FL Alliance A guide to FLock's federated learning client.

Overview of FL Alliance

After AI Arena has optimised the model parameters, they are further refined in FL Alliance with proprietary data. Following our research paper published at IEEE Transactions on Artificial Intelligence (see ), we provide a robust incentive mechanism incentivise honest behaviours and penalise malicious behaviours of FL participants. The motivation behind this FL Alliance system is to create a decentralised and secure environment for federated learning. By using random functions to allocate roles and a staking mechanism to ensure commitment, the system promotes trust and reliability among participants. The slash and reward mechanism further incentivises honest behaviour, ensuring the collaborative effort results in a high-quality global model. # Participants This sub-section introduces various participants in the FL alliance and their respective roles and workflow. ## 1. Task Creator * Stakes and creates a FL task * Specifies the basic information of a FL task, such as the number of minimum participants, the expected number of rounds, and the initial reward amount in the pool ## 2. FL Nodes FL nodes are participants in a decentralised learning system where multiple entities collaboratively train a shared machine learning model without exchanging their local data. These nodes can be any devices or servers contributing computational resources and data to the training process. FL nodes play critical roles in ensuring the integrity and efficiency of the FL Alliance working process. They are randomly allocated the roles of proposers and voters with the goal of avoiding collusion and other malicious behaviours. By distributing these roles randomly, the system ensures a fair and unbiased approach to model training and evaluation. Specifically, developers join as FL nodes to collaboratively train a global model while using their local data and computing power. They are randomly allocated the following roles: * **Proposers:** Responsible for performing local training using their own data and proposing updates to the global model. * **Voters:** Responsible for aggregating local model updates, evaluating the global model, and casting votes to either support or oppose the proposed updates. # Components This sub-section introduces the three components comprising our FL Alliance. ## 1. FLocKit * Encapsulates task-specific training logic * Offers predefined templates for various tasks, such as LLM fine-tuning, time series prediction, and more * Provides an effortless way to create a federated learning (FL) task (for instance, to create a LLM finetuning FL task, users only need to specify the target model they want to fine-tune in the configuration file, without requiring any changes to the source code) ## 2. FL Client FL Client serves as both an organiser and an orchestrator, facilitating the interaction between smart contracts and federated learning (FL) training tasks. It also manages all necessary system-level environments, ensuring seamless operation and coordination throughout the process. Specifically, FL Client: * Interacts with smart contracts * Allows proposers to train their local models using their own local data * Allows voters to submit scores based on the performance of the proposers * Aggregates scores submitted by voters ## 3. Smart Contracts * Assigns roles to participants randomly * Allows participants to stake and withdraw rewards * Slashes malicious behaviours # Task Lifecycle Deep-dive This section gives an in-depth explanation of our FL Alliance.

Overview of the workflow of a FLock FL task.

FLock's FL Alliance is adopted from our [previous work](https://arxiv.org/pdf/2307.00543). During each round, FL clients are randomly selected to act as proposers or voters. Their staked amount can be either rewarded or slashed based on the outcome of the majority voting results. Malicious clients will ultimately be removed from the FL system. # 1. Staking and Role Assignment FLock adopts a distributed voting and a reward-and-slash mechanism to construct secure FL Alliance systems. To participate in the training process, each participant is required to stake a specified quantity of $FLOCK. For each FL Alliance task within the ecosystem, rewards are initially secured by transferring them to the respective FL smart contract, provided the task is still in progress and has not surpassed its maximum allotted lifecycle. This preliminary step ensures that the rewards are earmarked and protected for participants actively engaged in the task. Subsequently, upon meeting these conditions, the FL smart contract autonomously distributes the rewards to the participants, according to their contributions. An FL Alliance task should be derived from a finished AI Arena task. The initiation of an FL task automatically triggers the creation of a new FL contract. The reward for the FL task is determined based on the total reward allocated to the corresponding AI Arena version. Task specific training logic is being uploaded to an off-chain storage platform and encapsulated in a hash. This hash is being used when an instance of the FL Task is being instantiated. Here, training logic refers to specific requirements in relation to the given FL task, such as parameters, epochs of training etc. Upon formally joining the training task, each participant’s local dataset is randomly partitioned into a training set and a test set, which will not be shared with other participants at any time. At the beginning of each round in the FL Alliance task, participants are randomly assigned roles as either a proposer or a voter. The random selection of roles for participants is conducted on-chain. A model initialised by one of the proposers is chosen at random temporarily to serve as the pioneering global model. The selected model’s weights or gradients are then distributed to all participants, ensuring a unified starting point for local models. Proposers are responsible for training their local models using their own data and subsequently sharing the updated model weights or gradients with all participants. Voters, on the other hand, aggregate these updates from proposers. They then proceed to validate the aggregated model updates, resulting in the generation of a validation score. # 2. FL Training At the start of each round, proposers initially download the global model, which was finalised in the previous round. Using the proposer’s own local training dataset, proposers then proceed to update the model through local training, and upload the updated model to voters for evaluation. # 3. FL Aggregation and Evaluation Then, each voter gathers the local models from all proposers. These models are then aggregated into the latest global model using a weighted averaging approach. Each voter then proceeds to evaluate the aggregated model, utilising their own local testing datasets. This evaluation phase involves the computation of a local validation score, which functions as a criterion for assessing the model’s performance. These individual validation scores are then submitted to a smart contract for aggregation. Following the aggregation, the aggregated score is compared with the previous round’s score, to assess progress or decline in model performance. The smart contract then determines the next steps for the aggregated model based on these scores: if there is an improvement in performance score, the system will proceed to the next phase of training; if there is a decline, another round of training, aggregation and evaluation will begin using the validated model from the previous round. After receiving all reported voting results from the voters, the aggregator (any participant can call the function through the smart contract) will calculate the aggregated voting result.
# 4. Rewards At each round, the aggregated voting result will also determine the rewards distribution for participants in a FL Alliance task. At any given round, if the aggregated vote is non-negative, all proposers will receive rewards (the reward amount depends on their stake amount). Conversely, if the aggregated vote is negative, staked tokens of all proposers for that round will be slashed. As for voters, if the aggregate vote is non-negative, those who voted with a non-negative score will be rewarded (again, the reward amount depends on their stake amount), and those who voted with a negative score will be slashed. Conversely, if the score is negative, those who voted with negative will be rewarded, or slashed otherwise.
# Smart Contracts Deep-dive This page gives detailed explanation of FL Alliance's smart contracts.

FL Alliance Smart Contract Interactions.

## Core Contracts ### `FlockTaskManager.sol` **Role:** Factory and lifecycle controller for all `FlockTask` instances. * **Task Creation**: Deploys new `FlockTask` contracts, passing in initial parameters like `_totalNumberOfRounds`, `_minStakeThreshold`, `_initialRewardPoolSize`, etc. * **Task Management**: Maintains a list (via `EnumerableSet`) of active or unfinished `FlockTask` addresses. * **Finish Task**: The owner can mark a task as `finished` if necessary (`finishTask(...)`), removing it from the active set. ### `FlockTask.sol` **Role:** This contract implements a decentralized and scalable model for round-based federated learning (“FL tasks”). * **Staking & Roles**: Participants stake tokens to become eligible to join rounds, where they are randomly assigned roles (proposers, voters). * **Proposal & Voting Rounds**: Each round, selected proposers submit model updates, and voters commit/reveal votes that determine the most popular model via stake-weighted voting. * **Rewards & Slashing**: Well-behaved participants (correct contributions/votes) receive rewards; dishonest behaviors can be “slashed,” losing a percentage of their stake. ## Libraries ### `LibABDKMathQuad.sol` **Role**: Quadruple-precision (128-bit) math operations. * Implements IEEE 754–style floating-point arithmetic for `bytes16` values. * Provides precision far beyond typical fixed-point or 256-bit integer math. * Useful for advanced computations like logarithms, exponentials, or rational approximations. ### `LibFlockTask.sol` Role: Provides specialized numeric and utility functions for federated-learning tasks. Key Functions include: * **`mulDiv`(uint256 x, uint256 y, uint256 z)** * Combines multiplication and division with quadruple precision by leveraging `LibABDKMathQuad`. * `rand`() * Generates a pseudo-random number by hashing block and transaction properties. # FL Client This page gives instructions for running a FL client node.
# Pre-Requsites 1. Python version >= 3.11 2. Docker 3. Anaconda 4. Make 5. FLOCK - FLock’s native token is required for staking. You can check out the contract [here](https://sepolia.basescan.org/address/0xeF39985160FEdd389B46E6dB14d6aEa26cb5981A). 6. Base Sepolia ETH - our testnet is deployed on Base Sepolia. You need Base Sepolia ETH to cover gas costs. If you don’t have Base Sepolia ETH, you can get some from the [Alchemy Faucet](https://www.alchemy.com/faucets/base-sepolia). Note that dependant on the task, there is specific hardware requirements. For LLM fine-tuning tasks, you need at least `GPU` with at least `12GB` memory. # Steps to Quickstart 1. Download the client ```bash git clone https://github.com/FLock-io/FL-Alliance-Client.git ``` 2. Prepare Docker ```bash sudo groupadd docker sudo usermod -aG docker $USER ``` 3. Initialise and activiate a new conda environment ```bash conda create -n flock_client python==3.11 source activate flock_client ``` 4. Install dependencies ``` cd FL-Alliance-Client pip install -r requirements.txt ``` 5. Prepare the Makefile * Navigate to Makefile at the root folder * Replace `TASK_ADDRESS` with the address of the task that you intend to join. * Replace `YOUR_ALCHEMY_API_KEY` with your Alchemy API key. * Replace `YOUR_PRIVATE_KEY` with your private key. Ensure that this wallet contains $FML as well as Base Sepolia ETH. Please protect your private key and do not publish it to Github for instance. * Put the data you intent to train with to this repo. Then, replace `YOUR_PATH_TO_DATA` with the path to your datasets. 6. Build and run the client ```bash make build make start ``` # FLocKit Coming soon :smile: # AI Marketplace Guide to beta.flock.io, where AI models can easily be co-created by the community AI Marketplace is a space where people come together to build, improve, and use models. It focuses on spreading the work out (decentralisation) and getting everyone stuck in (community engagement). It allows users to propose models, contribute data, and utilise these models in various applications. FLock invites you to propose models, contribute data and idle resources, evaluate models, refine data, and utilise these models in various applications. FLock’s library ranges from intelligent agents to sophisticated trading and confluence bots. It enables external database integration, and RAG enhances domain-specific accuracy. One use case is BTC-GPT, which has reached 10k model calls. # Quickstart Follow the steps in the following sections to participate in AI Marketplace. # Getting started Manual creation Guide to API Key and Model Creation for Hackathons {% hint style="success" %} Try out our Beta: [This way](https://beta.flock.io)! {% endhint %} ## Acquiring the API Key To embark on model creation, the initial step involves generating an API Key. Follow the OpenAPI standard command below: * Generate API Key
* Click the "Generate the API Key"
* You can copy your API key now
# Guideline Manual Our step-by-step guide will walk you through each function of the platform, including model customisation, knowledge contribution, quality assurance, and model evaluation. ## Model Customisation Create your own chatbot by following these steps: * Connect your Wallet * Go to the co-creation page.
* In the top right corner, you will find a button labeled "Create new model." Click on the button, and a pop-up will appear.
* When you open the pop-up, you'll see an example of how the data is organized. It's important to have documents that are closely related to each other to improve the accuracy of the model. Make sure to review and adjust the documents to ensure they are relevant and coherent, which will help enhance the AI model's performance and effectiveness. ``` Model Name: flock test Description: This is a test flock chat bot enables efficient explain on what is flock doing Data Required: FLock related documentation Example knowledge: Data for fine-tuning ``` | Parameter Name | Description | | ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Model Name | The name for you Chat bot | | Description | Tell us what is your chat bot going to do | | Data Required | What data do you want | | Example Knowledge |

The preset training document can be one of the following options. Users must contribute at least three verified knowledge documents in order to create a model:

  • PDF, TXT
  • Raw text
  • Website links
| * PDF and TXT upload
* Raw text upload
* Link upload
* After the clicking the “Create” we will validate the data you submitted.After clicking the "Create" button, we will validate the data you submitted. * The success page
* To check the model status, you can go to “My models” for more status.
### Knowledge Contribution This interaction allows the user to continuously provide information to the model for accuracy and improvement of the knowledge base. Here, you can truly experience how co-creation can be achieved! * Select a model and click the "Contribute Knowledge" button.
* Before contributing knowledge, please carefully read the "Data Required" field. * Each person can contribute documents in any of the following formats: * PDF,TXT * Raw text * Website links * After selecting the document, click "Complete" to proceed. * The data validation process will approximately take 1 minute to complete. * You can always check the progress of your data contribution in the "My Model" section.
* Similarly, you can go to "My Models" and check the points allocation.
### Quality Assurance Quality assurance is crucial in evaluating and refining the knowledge base to ensure its alignment with specific use cases. To recognize their valuable contributions, we have implemented a reward system to incentivize and appreciate their efforts. By voting on the data sources, we can assess and acknowledge their contributions, ensuring they are duly recognized and rewarded. * Click on the Preview button; here, we will list out all the data sources contributed to the chatbot.
* You can preview the data source to validate the data.
* You can then vote the data source in terms of the quality
### Model Evaluation Evaluate the model and interact with the AI agent to assess the performance and accuracy of the RAG-enhanced LLM by chatting with the chatbot. You can test if the bot has learnt all the data we contributed or not. Each user can chat with the bot **10** **times per day** free of charge. * Simply click on the Chat button
Feel free to ask any questions or seek information about the data provided. For instance, the bot has been trained on a wide range of information concerning FLock. So, don't hesitate to ask anything related to FLock and its associated topics.
# Model API guide Model Guide for you to implement FLock model ## Pre-requirement ### Manual creation via website * Generate API Key via [Getting started Manual creation](/flock-products/ai-marketplace/quickstart/getting-started-manual-creation#acquiring-the-api-key) * Create Model via [Guideline Manual](/flock-products/ai-marketplace/quickstart/guideline-manual#model-customisation) ## Technology Stack * TypeScript * JavaScript ### API Call example {% openapi src="/files/HzQjrXbSg6zuB7V3ac3M" path="/chat/conversational\_rag\_chat" method="post" %} [openapi.json](https://742781353-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1RpcbvTSHzzPwOSUvgKU%2Fuploads%2Fd7duzxHXRu3ZnLBllCJP%2Fopenapi.json?alt=media\&token=3e2b3b87-7de2-4e11-9ce6-021eac3a97e2) {% endopenapi %} ## How it Works ### Setup #### Package installation ```bash npm install --save axios dotenv # or yarn add axios dotenv # or pnpm add axios dotenv ``` ### `.env` * Create an `.env` file in the root directory or in your existing env file, add the followings: ``` // Some code FLOCK_BOT_API_KEY= "" FLOCK_BOT_ENDPOINT="https://rag-chat-ml-backend-prod.flock.io" ``` ### Step by Step guide * Create a `flockModel.ts` * Create a `async/await` function `flockModel` wrapping the API call * use `axios.post` method for request * We will pass two parameters * `question` * `knowledge_source_id` * get the response of the call * We chose to use `try/catch` to handle any error during the call to debug the process. 
import axios from "axios";
import * as dotenv from "dotenv";

// Load environment variables from .env file
dotenv.config({ path: "./.env" }); // Make sure the path is correct

async function main(prompt: string) {
  console.log("Prompt:", prompt);

  try {
    // Construct the request payload
    const payload = {
      question: prompt,
      chat_history: [],
      knowledge_source_id: "<model_id>", // replace with your model id
    };

    // Set the headers
    const headers = {
      "x-api-key": process.env.FLOCK_BOT_API_KEY, // Ensure API key is set in .env
    };

    // Send POST request using axios
    const response = await axios.post(
      `${endpoint}/chat/conversational_rag_chat`,
      payload,
      {
        headers,
      }
    );


    // Output the response data
    console.log(response.data);
  } catch (error) {
    console.error("Error:", error);
  }
}

// Example call to the main function
main("Can you figure out how to make a chatbot?");
# Tutorials In the following sections, you can follow our tutotirals to participate in AI Marketplace. # Create a discord bot with Model API ## Introduction This tutorial guides you through the process of creating a Discord bot powered by the FLockRAG model. The bot can respond intelligently to user queries and automate tasks within the server. ### What You Will Learn * Learn how to create a chatbot on FLock’s AI Co-Creation platform * How to create a simple chat bot on discord * Link up the chat bot with AI endpoint to create a AI-driven Chatbot. ### Technology Stack * JavaScript ## How it Works Before we get into the actual development, lets first run down through the function requirement * We want to interact with the bot using slash comments. * The command should include a `prompt` parameter for the bot. * The new chat should take place in a private thread. * All chats should only be visible to the caller user. There will be three sections we will cover in this tutorial * Setup Discord bot from discord developer portal * Setup your RAG bot from AI Co-Creation platform * Create a Discord bot with Discord.js * Test and run the Discord bot from local environment. ### **Creating Your Bot on Discord** * Go to Discord's [Developer Portal](https://discord.com/developers/applications) and log in with your Discord account. * Click on the "New Application" button and give it a name, which will also be the name of your bot. * On this page, you will find the **APPLICATION ID** and **PUBLIC KEY**. * In the left-hand side menu, click on the "Bot" tab. Here, you will find your **bot token**. * Remember, the bot token is sensitive and should never be shared. You will use this token to log your bot in. ### AI Co-Creation Setup To create a bot from AI Co-Creation platform * First visit * Click on the **Create my Model** * Follow the requirement, and fill in all the details. ### Bot Creation #### **Step 1: Setting Up Your Project** ```bash mkdir flock-io cd flock-io npm init -y ``` These lines helps us to create directory, change to the created directory and setup `package.json` #### Step 2. Install package ```bash npm install discordjs dotenv axios ``` This help us to install all the required package * `discordjs` * `dotenv` * `axios` #### Step 3. Build the bot > Our tutorial is based on [DiscordJS guide](https://discordjs.guide/#before-you-begin) Refer to our previous requirements, we want this bot to achieve: * Allow a `chatbot` slash command * React to slash command with prompt Create an `index.js` file, where we will write our bots’s code. Then, set up your Client as follow: ```jsx import { Client } from "discord.js"; const client = new Client({ intents: ["Guilds", "GuildMessages", "GuildMembers", "MessageContent"], }); client.on("ready", () => { console.log(`${client.user.tag} has logged in.`); }); client.login(process.env.DISCORD_TOKEN); ``` Then we add the slash command #### Step 4. Adding a Slash Command To interact with the Discord API and create slash commands, you'll need to use Discord's application commands API. Here, I'll show you how to register a **`chatbot`** command and respond to it. 1. **Register the Command**: Commands can be registered globally or to a specific guild for testing. For simplicity, we'll register a global command, which might take up to an hour to propagate. 2. **Responding to Commands**: Modify your bot to listen for interactions and respond to the **`chatbot`** command. Further explanation to command variable * `setName` - set the name for this command * `setDescription` - set the description for this command * `addStringOption` - add an option that accepts string input, in our case we want to gather the prompt text from user. ```jsx const commands = [ new SlashCommandBuilder() .setName("chatbot") .setDescription("Chat with the bot") .addStringOption((option) => option .setName("prompt") .setDescription("Prompt for the chatbot") .setRequired(true) ) .toJSON(), ]; const rest = new REST().setToken(process.env.DISCORD_TOKEN); (async () => { try { console.log( `Started refreshing ${commands.length} application (/) commands.` ); const data = await rest.put( Routes.applicationGuildCommands(process.env.APP_ID, process.env.GUILD_ID), { body: commands } ); console.log( `Successfully reloaded ${data.length} application (/) commands.` ); } catch (error) { console.error(error); } })(); ``` #### Step 5. Handle the command Within `Discordjs` , they provided a status called `interactionCreate` where we sets up an event listener that waits for an interaction to occur. ```jsx client.on("interactionCreate", async (interaction) => { // Code to handle the interaction goes here }); ``` Next we check few conditions * Has user inputed command * If user inputed command, is the command name equal to chatbot. ```jsx if (!interaction.isChatInputCommand()) return; if (interaction.commandName === "chatbot") { // Proceed to handle the `chatbot` command } ``` Recapping on the requirement * Create a thread upon user’s command. But in Discord there is an issue if we set the reply as ephemeral(private) the API will not be able to pick it up. Therefore our execution flow should be: User interact → Discord sends out a helper text(Public) → use this helper text as the thread starting node → Create a private thread #### **Step 6. Sending a Preliminary Reply** * Inside the command check, it first sends a reply to the interaction with a message indicating that a personal thread is being prepared: **`const message = await interaction.reply({ ... });`**. * **`fetchReply: true`** tells Discord to return the sent message as a **`Message`** object. * **`ephemeral: false`** specifies that the message should be visible to everyone, not just the user who invoked the command. This is necessary because the bot intends to start a thread based on this message. ```jsx const message = await interaction.reply({ content: "Preparing your personal thread...", fetchReply: true, ephemeral: false }); ``` #### **Step 7. Starting a Thread** * Then we start a thread from the reply message: **`const thread = await message.startThread({ ... });`**. Adding `PrivateThread` to ensure thread is only visible to command caller. ```jsx // Starting a thread from the bot's message const thread = await message.startThread({ name: prompt, autoArchiveDuration: 60, type: ChannelType.PrivateThread, reason: "Needed a separate thread for User Prompt", }); ``` #### **Step 8. Sending a Message to the Thread** * After creating the thread, the bot gets ready to send a message to it. There are discussions about sending a basic greeting message directly or using a function called **`main(prompt)`** you can check the [Model API guide](/flock-products/ai-marketplace/quickstart/model-api-guide), to generate a response based on the user's prompt and then send that response to the thread. ```jsx // Send a message to the thread using the flock-api.js file const response = await main(prompt); thread.send(response.answer); // Option await interaction.followUp({ content: `Your personal thread ${prompt} is ready!`, ephemeral: true, }); ``` ```jsx client.on("interactionCreate", async (interaction) => { if (!interaction.isChatInputCommand()) return; if (interaction.commandName === "chatbot") { // Reply with a non-ephemeral message const message = await interaction.reply({ content: "Preparing your personal thread...", fetchReply: true, ephemeral: false, // This message needs to be non-ephemeral to start a thread }); // Get the prompt from the user const prompt = interaction.options.getString("prompt"); const user = interaction.user; console.log(user); // Starting a thread from the bot's message const thread = await message.startThread({ name: prompt, autoArchiveDuration: 60, type: ChannelType.PrivateThread, reason: "Needed a separate thread for User Prompt", }); // Send a message to the thread using the flock-api.js file const response = await main(prompt); thread.send(response.answer); // Option await interaction.followUp({ content: `Your personal thread ${prompt} is ready!`, ephemeral: true, }); } }); ``` #### Step 9: Deployment and Testing in a Local Environment To deploy the application locally: 1. **Update the `package.json` File**: Insert the following code snippet into your `package.json` file under the `scripts` section: ```json "scripts": { "start": "node index.js" } ``` 2. **Launch the Application**: Execute the command below in your terminal: ```bash npm run start ``` 3. **Verify the Output**: Upon successful execution, you should observe an output similar to the following: ``` > discord-flock@1.0.0 start > node index.js Started refreshing 1 application (/) commands. Successfully reloaded 1 application (/) commands. FLockbot_tim_test#6051 has logged in. ``` These log messages indicate that your bot is now operational and running in your local environment. Next we need to add the bot to a server. * You can add the bot using this URL ``` <**APPLICATION ID**>&permissions=0&scope=bot%20applications.commands ``` * In your server you can type in following command # Farcaster Frames with Model API ## **Video Tutorial** {% embed url="" %} Welcome to this tutorial where we will walk you through the process of creating a Farcaster Frame and communicating with a FLock.io RAG API. This is a comprehensive guide that will give you the confidence to create, modify, and enhance your Farcaster Frames with FLock API. What you will learn: * How to create a Farcaster Frame * Communicate with FLock RAG API. ## Technology Stack * TypeScript * Frog framework ## What is Frame? A Frame is a tool for creating interactive, authenticated apps on Farcaster, allowing features like polls, live feeds, or galleries within Warpcast and other FC clients. Frames enhance the OpenGraph standard, transforming static embeds into interactive experiences. ## What is Frog framework? Frog is a framework built on top of Hono for building Farcaster Frames. The documentation: [Getting started](https://frog.fm/getting-started) ## How it Works ### Setup * Install Frog Framework ```jsx npm install frog hono yarn add frog hono ``` * Create a Bot from the AI Co-Creation platform, where you can follow the guide. * Install the API related package. ```jsx # init frog framework npm init frog # install relavent packages npm install axios dotenv @types/node ```

Frog init

* We will be using the `default` template, feel free to export other ones in the future. ### File structure ```jsx 📦flock-far-frog ┣ 📂public ┃ ┗ 📜icon.png ┣ 📂src ┃ ┣ 📂api ┃ ┃ ┗ 📜flock-api.ts ┃ ┗ 📜index.tsx ┣ 📜.env ┣ 📜.gitignore ┣ 📜README.md ┣ 📜package-lock.json ┣ 📜package.json ┗ 📜tsconfig.json ``` * Pages will stay in our router * FLock API will stay in the utils ### Logic flow We will have one page * Default page - react on user’s input This is a very simple and general approach of how we can use frame with FLock Chat Bot. ### API Now create a folder under `src` called `api` within the `utils` folder create a file called `flock-api.ts` this is the place where your api will sit. And here is the code you can use directly. ```jsx import axios from "axios"; import * as dotenv from "dotenv"; // Load environment variables from .env file dotenv.config(); // Make sure the path is correct async function chatFLockBot(prompt: string, modelId: string) { console.log("Prompt:", prompt); try { // Construct the request payload const payload = { question: prompt, chat_history: [], knowledge_source_id: modelId, // replace with your model id }; // Set the headers const headers = { "x-api-key": process.env.FLOCK_BOT_API_KEY, // Ensure API key is set in .env }; // Send POST request using axios const response = await axios.post( `${process.env.FLOCK_BOT_ENDPOINT}/chat/conversational_rag_chat`, payload, { headers, } ); // Output the response data console.log(response.data); return response.data; } catch (error) { console.error("Error:", error); } } export default chatFLockBot; ``` Next create a `.env` file in the root directory of the project, and add following ``` FLOCK_BOT_API_KEY= "" FLOCK_BOT_ENDPOINT="" FLOCK_BOT_ID="" ``` ### Useful tools for OG image > I personally think that the Vercel OG image playground is a convenient tool to quickly check up on your OG image. So, do utilise it! [Vercel OG Image Playground](https://og-playground.vercel.app/) ### Page Structure ```jsx app.frame('/', (c) => { const { buttonValue, inputText, status } = c const fruit = inputText || buttonValue return c.res({ image: ( ), intents: [ ], }) }) ``` Before diving in, let's first understand the structure of a ‘frame’. A frame consists of two components: the image and the intents. * The **image** is where your visuals are displayed * The **intents** handle interactions, including text input, button reactions, and the new transaction operations. #### **Image** ```jsx image: (
{status === 'response' && `Your question is: ${prompt}`}
{status === 'response' ? response.answer : "Lets chat about FLock!"}
) ``` Here we use status condition to show the content, if status is response, we will show the question and answer. Otherwise, the user will only see “Lets chat about FLock” #### **Intent** ```jsx intents: [ , , status === 'response' && Reset, ], ``` Here we have created three intents * `TextInput` - for questions to be asked to the bot * `Button` - for the interaction * `Button` - for reset after receiving the response #### Main logic flow ```tsx import chatFLockBot from './api/flock-api' app.frame('/', async (c) => { const { buttonValue, inputText, status } = c const prompt = inputText const modelId = buttonValue let response; if (prompt == undefined || modelId == undefined) { response = "Detail not satisfied, please insert prompt"; } else { try { response = await chatFLockBot(prompt, modelId); } catch (e) { response = "There is somthing wrong with the process, please try again" } } return c.res({ image: ( ... ), intents: [ ... ], }) }) ``` In this section, we establish the logic to respond to both user input and an API call. Initially, we extract values from the object **`c`** (representing context), which provides the current state or frame: * **`buttonValue`** - the value assigned to a button, * **`inputText`** - the text entered by the user, * **`status`** - the status of the context within its lifecycle. Next, we initialise two constants, **`prompt`** and **`modelId`**, using the extracted **`inputText`** and **`buttonValue`** respectively. This sets up the parameters we need for the subsequent API call. We then employ an **`if`** statement to check whether either **`prompt`** or **`modelId`** is undefined. This validation is crucial as it ensures that we have the necessary data before proceeding. Finally, we use a **`try-catch`** structure to manage the asynchronous function **`chatFlockBot`**. This function is called with **`prompt`** and **`modelId`** as arguments. The **`try`** block executes the function, and should any errors occur during the API call, the **`catch`** block captures these exceptions and sets an error message. ## Run the test Now you have completed the setup of the frame. Let’s test it in the local environment. ``` # run this command in your terminal npm run dev # you will see followings > dev > frog dev (!) Could not auto-determine entry point from rollupOptions or html files and there are no explicit optimizeDeps.include patterns. Skipping dependency pre-bundling. [running] frog@v0.9.0 ➜ Local: http://localhost:5173/ ➜ Inspect: http://localhost:5173/dev ➜ Network: use --host to expose ``` Go to `http://localhost:5137/dev` You will see the following page
1. The history of access 2. URL tab - similar to web browser URL tab 3. Metadata of current frame 4. Live frame interact 5. Request/Context/Metadata information 6. Request/Context/Metadata information Now you can start typing the questions and chat with the frame! ## Deploy your frame I recommend deploying your project using [Vercel](https://vercel.com/). You can easily deploy it by connecting your GitHub account and pushing your project to a repository. Next, all you need to do is copy your deployed link and post it in any Farcaster Client. Please tag us when you post the cast! “/flock-io” **Lastly here is the GitHub Repository!** > *Reach out to us by Website:* [*https://flock.io/*](https://flock.io/) \ > *Twitter:* [*https://twitter.com/flock\_io*](https://twitter.com/flock_io) \ > *Telegram:* [*https://t.me/flock\_io\_community*](https://t.me/flock_io_community) \ > *Discord:* [*https://discord.gg/ay8MnJCg2W*](https://discord.gg/ay8MnJCg2W) \ > *Farcaster:* [*https://warpcast.com/\~/channel/flock-io*](https://warpcast.com/~/channel/flock-io) # Participants This section describes different participants and the roles they play in AI Marketplace.

Participants & Workflow in AI Marketplace.

## Model Proposer * Conceptualise and introduce new models * Delineate clear use cases and pinpoint relevant data sources that underpin development and efficacy ## Data Contributor * Offer valuable datasets that help the model to learn and adapt ## End User * Offer critical user feedback and insights that drive improvment of models ## Developer * Act as the bridge between the model's capabilities and practical applications * Leverage the API endpoints to integrate the model into diverse software applications, thereby expanding its functional reach and accessibility. At the core of this ecosystem lies a sophisticated chatbot, driven by state-of-the-art LLMs. The chatbot is not only empowered by the computational prowess of LLMs but is also equipped with advanced search and retrieval functionalities. This enables it to extract and leverage information from a dynamically evolving database—a repository enriched by the continuous contributions of Data Contributors. This dual capability ensures that the chatbot remains both intelligent and informed, able to deliver nuanced and contextually relevant responses. # Deep-dive # Function breakdown This system streamlines the process of creating, deploying, and utilising customised AI models. ### Function breakdown AI Marketplace operates through various phases, incorporating model proposals and live chatting. **Core components and workflow:** 1. **Model Proposal:** Submit AI model proposals, describing tasks and required data sources for applications like AI x Web 3 projects or longevity research. 2. **Data Contribution:** To encourage the submission of high-quality data, we offer rewards of tokens. 3. **Voting on Knowledge Base:** Voting system for community members to validate the contributed knowledge, ensuring relevance and safeguarding against malicious content. 4. **Chatbot Deployment:** Top-rated models are deployed as interactive bots on Discord channels, broadening the accessibility of AI to a wider audience. 5. **Reward System:** Model Proposers, Data Contributors and Model Hosts receive rewards based on data relevance, bot usage, and user feedback.
# RAG ### What is RAG RAG is a smart way to make LLMs (e.g. ChatGPT) even better by pulling information from outside sources. This means they can give personalised responses based on the latest and most relevant information, from knowledge snippets to user-specific data. ### How RAG adds value to the Co-Creation Platform Users can easily add their own data to enhance the AI models. **Enhances responses - m**ake the AI's answers more relevant and personalised by using specific data sets. **Reward contributions - c**ombine blockchain to securely reward people who provide and check the data. This combination makes the data more trustworthy and promotes a community-led approach. # Contribution Mechanism Rules for each action a user can perform on the website. | Action | Points | | ------------------------------------------- | ----------------------------------- | | Connect your wallet | 30 Points | | Connect your Discord account | 30 Points | | Join our Discord and acquire a Flockie Role | 30 Points | | Connect your Twitter account | 30 Points | | Follow @flock\_io on Twitter | 30 Points | | Broadcast a tweet about flock.io | 30 Points | | Connect your Telegram account | 30 Points | | Join FLock.io Community on Telegram | 30 Points | | Create a Model | 100 Points | | Contribute to a Model | 10 Points (Cap at 100 points daliy) | # Roadmap * [x] **Creation of RAG models** * [x] **Interaction with available RAG models** * **Chat integration:** Facilitate real-time chat functionalities powered by RAG models, enhancing user engagement and model responsiveness. * **Knowledge contribution mechanism** * **Voting on content relevance & accuracy** * [x] **Task center:** Establish a central hub where users can manage and track their activities. * [x] **Leaderboard:** Introduce a competitive yet collaborative leaderboard system to gamify the experience. * [x] **API key generation for public use:** Enabling developers and users to integrate RAG model capabilities into their own applications. # API Platform FLock API Platform is an enterprise-grade AI model hub that provides a single secure interface to the world’s leading AI models — at significantly lower cost than mainstream inference APIs. The platform offers unified access to foundation models, end-to-end model lifecycle management, and a cloud-agnostic infrastructure fabric, with built-in support for data sovereignty, privacy, and regulatory compliance. This enables organizations to deploy production-grade AI agents reliably across heterogeneous environments. As a core component of FLock’s ecosystem, the API Platform also serves as the primary distribution and monetization layer for tokenized AI models. Real Model Asset Issuers can publish their models to the platform, where they become discoverable, routable, and consumable through standardized APIs. Users can access these models at discounted inference rates by holding model tokens, aligning economic incentives between model owners and consumers while enabling sustainable, decentralized model monetization. # Getting started ### Step 0: Head to [platform.flock.io ](https://platform.flock.io/)and sign up
### Step 1: Create an Team Create a team to manage your organization’s API usage, billing, and access control in one place.\ All API keys, credits, logs, and members will belong to this team.
### Step 2: Create an API key To start using the API, you will be prompted to create the API key first
Please keep your API key safe as you won't be able to see it again. If you lose it, please create a new key. ### Step 3: Use the API Use your API key to authenticate requests from your application. You can integrate the API using: * REST endpoints * Official SDKs (if available) * Command-line tools * Server-side applications Please refer the section [API Endpoints](/flock-products/api-platform/api-endpoint) for request formats, endpoints, and example code. ### Step 4: Buy credits Before making requests, ensure your account has sufficient credits. Navigate to **Settings → Billing** to purchase credits.
We support payments using Stripe, Base Pay, and Coinbase. Credits are deducted automatically based on your API usage. ### Step 5: Track Usage Monitor activity and costs in real time: * **Logs tab** — View detailed request logs for selected time ranges, including status, latency, and errors
* **Usage tab** — Track total requests, token consumption, and average cost per request
This helps you debug issues, optimize usage, and manage spending. ### Step 6: Adding members to your organisation Invite teammates to collaborate on the platform. Go to **Teams → Members** to: * Add new users * Assign roles and permissions * Manage access to API keys, billing, and logs All members will operate under the same team workspace.
### Step 7: API Playground Experiment with the API directly in your browser. The Playground allows you to: * Test different models * Try prompts and parameters * View responses instantly * Generate sample code for integration It’s the fastest way to explore capabilities before building your application.
# API Endpoint ### Endpoint The endpoint is OpenAI-compatible, if you are using the OpenAI client, simply switch the base URL to `https://api.flock.io/v1` *** ### Example Request ```bash curl -X POST 'https://api.flock.io/v1/chat/completions' \ -H 'accept: application/json' \ -H 'Content-Type: application/json' \ -H 'x-litellm-api-key: sk-your-api-key' \ -d '{ "model": "qwen3-30b-a3b-instruct-2507", "stream": true, "messages": [ {"role": "system", "content": "You are a helpful assistant."}, {"role": "user", "content": "Hello, can you help me?"} ] }' ``` *** ### Request Body Parameters #### Required * **model** `string` * The ID of the model to use. * Use the \[List Models API] to see all available models. * **messages** `string | array` * Input(s) for the model. * Can be a string, array of strings, array of tokens, or array of token arrays. * `<|endoftext|>` is used as a document separator. #### Optional * **best\_of** `integer` * Defaults to `1`. * Generates multiple completions server-side and returns the one with the highest log probability. * Not supported with `stream`. * **frequency\_penalty** `number` * Defaults to `0`. * Range: -2.0 to 2.0. * Positive values penalize repetition. * **logit\_bias** `map` * Defaults to `null`. * Adjust likelihood of specific tokens. * Example: `{"50256": -100}` prevents `<|endoftext|>`. * **logprobs** `integer` * Defaults to `null`. * Returns log probabilities for top `n` tokens. * Max: `5`. * **max\_tokens** `integer` * Defaults to `16`. * Maximum tokens to generate in the completion. * **n** `integer` * Defaults to `1`. * Number of completions to generate. * **presence\_penalty** `number` * Defaults to `0`. * Range: -2.0 to 2.0. * Positive values encourage new topics. * **seed** `integer` * If provided, makes sampling deterministic when possible. * **stop** `string | array` * Defaults to `null`. * Up to 4 sequences that will stop token generation. * **stream** `boolean` * Defaults to `false`. * If `true`, responses are streamed as server-sent events. * **stream\_options** `object` * Only used when `stream: true`. * **temperature** `number` * Defaults to `1`. * Range: 0–2. * Higher values = more random output. * **top\_p** `number` * Defaults to `1`. * Nucleus sampling alternative to `temperature`. * **user** `string` * Unique identifier for the end-user. *** ### Response Returns a **completion object**, or a sequence of completion objects if streaming is enabled. *** ### Notes * Use `max_tokens` and `stop` wisely to control output length. * For deterministic results, combine `seed` with fixed parameters. # FOMO A guide to FLock Open Model Offering, a launchpad for real model assets that lets anyone turn model usage into a shared, on-chain economy.
FOMO (FLock Open Model Offering) is a protocol for launching, operating, and monetizing AI model deployments as real, usage-backed economic assets. It connects model deployment, inference usage, and token incentives into a single, deterministic system where value accrues only through real API consumption. FOMO operates alongside the FLock API Platform, forming a full-cycle AI infrastructure that spans launch, hosting, usage, and long-term incentive alignment. ### System Architecture FOMO is composed of four tightly coupled layers: 1. **Inference Layer (FLock API Platform)** Hosts models and serves production inference. All economic activity originates from real API calls paid in fiat or USDC. 2. **Launch Layer (Real Model Asset Offering, RMO)** Enables RMA (Real Model Asset) Issuers to raise $FLOCK to fund a concrete deployment. Tokens are only minted if the launch meets predefined economic thresholds. 3. **Token Layer ($FLOCK + Model Tokens)** * $FLOCK coordinates incentives at the network level. * Model Tokens ($MT) represent individual model deployments with fixed supply and direct exposure to usage-driven buybacks. 4. **Economic Engine (Revenue Routing & Emissions)** Routes inference revenue into deterministic buybacks, operator yield, and protocol sustainability. Bootstrap emissions are conditional on real usage and decay over time. # Participants This section describes the roles played by various participants in FOMO.
1. RMA Issuers — the Operator / Builder The Real Model Asset Issuer is the initiator and operator of a specific model deployment. They launch the model through FOMO, define its deployment configuration, and are responsible for bringing a real, usable AI model into production. As the operator, the RMA Issuer earns a share of ongoing inference revenue, aligning long-term incentives with model quality and adoption. **Who they are** * The individual or team that launches a model deployment via FOMO * Can be an AI builder, a startup, or a company using AI internally **What they do** * Define the model + deployment configuration * Initiate a Real Model Asset Offering (RMO) * Operate the “franchise” for that model **What they get** * A share of real inference revenue * Bonus $FLOCK emissions tied to actual usage
2. Supporters — the Bootstrap Capital Supporters participate during the model’s launch phase, providing early capital to bootstrap deployment, liquidity, and incentives. They take on initial risk in exchange for early exposure to the model’s economic upside. Their role enables models to reach production quickly while aligning early belief with long-term usage-driven value. **Who they are** * Community members who participate in RMOs * Early believers in a model’s utility **What they do** * Provide upfront capital in exchange for MT * Help fund hosting, liquidity, and incentives **What they get** * Early access to a model-backed asset before deployment * Exposure to usage-driven upside through future buybacks and supply contraction
3. Users — the Power Users Users are the consumers of AI inference who actively rely on the model in real applications. By staking the model token, they unlock discounted inference costs and receive protocol rewards, while their usage directly drives token buybacks. In FOMO, users are not just customers — they are economically aligned stakeholders in the models they depend on. **Who they are** * Developers, companies, or agents that actively use a model’s API * Often the same people who supported the model launch **What they do** * Buy Model Tokens (MT) during the RMO or on the market * Stake MT to unlock discounted inference * Consume inference in real applications **What they get** * Lower inference costs * $FLOCK emissions routed to actively used models * Exposure to MT scarcity via usage-driven buybacks
4. The Protocol (FLock / FOMO) — the Franchisor The protocol provides the infrastructure, rules, and economic coordination layer for all model deployments. It enforces deterministic revenue routing, emission logic, and token mechanics based on real usage, not speculation. Like a franchisor, the protocol standardizes operations and ensures that value flows fairly between operators, users, and supporters. **Who it is** * The FLock ecosystem operating FOMO and the API platform **What it does** * Hosts and serves models as production APIs * Enforces revenue splits, emissions logic, and buyback rules * Routes network-level value into $FLOCK **What it gets** * A portion of inference revenue for sustainability * Deflationary pressure on $FLOCK via protocol-level buybacks * Network effects as more models and users join
### The Mental Model FOMO participants form a closed economic loop: * Builders → launch real models * Users → consume inference * Usage → generates revenue * Revenue → buybacks + rewards contributors * No usage → no rewards At its core, FOMO is designed as a self-contained economic loop where value only flows when real work is done. Models must exist before tokens exist, and tokens only gain value through actual inference usage. # Launch Lifecycle Deep-dive This section gives an in-depth walkthrough of the model launch lifecycle.
This section describes the full lifecycle of a model launch on FOMO, from capital formation to long-term incentive alignment. The lifecycle is designed to ensure that token issuance, rewards, and value accrual are strictly downstream of real model usage. # 1. Launch Initiation Real Model Asset Offering (RMO) A model launch begins with a Real Model Asset Offering (RMO) initiated by the Real Model Asset (RMA) Issuer. During this phase: * The RMA Issuer defines a concrete model deployment configuration, including model architecture and hosting tier. * A 7-day fundraising process is opened where participants commit $FLOCK to support the deployment. * Fundraising follows predefined minimum and maximum targets that reflect the economic requirements of hosting and operating the model. Crucially, no Model Tokens ($MT) are minted during this stage. If the minimum fundraising target is not met within the launch window, the deployment does not proceed and pledged funds are redeemable (excluding platform fees). This ensures that model assets only come into existence when sufficient economic backing is secured. # 2. Hosting & Tokenization Deployment Activation Once the fundraising succeeds and the launch graduates: * The model is deployed on the FLock API Platform, where it becomes available for production inference. * The associated Model Token ($MT) is minted according to a fixed supply defined at launch. * Initial liquidity is created and locked, enabling secondary market trading. At this point, the model transitions from a proposed deployment into a live, revenue-generating AI service. Each $MT now represents a claim on the economic activity of a specific model deployment, not a speculative abstraction. # 3. Revenue Allocation Usage-Driven Value Flow All model usage on the FLock API Platform is paid in fiat or USDC. Revenue is processed as follows: * Hard operating costs (compute and infrastructure) are paid first. * Net revenue is then routed deterministically by protocol logic. The allocation includes: * Buyback of the model’s $MT * Buyback of the network token $FLOCK * Treasury allocation for protocol sustainability * Organic yield distributed to the RMA Issuers This design enforces deflation at both the model level and the network level, ensuring that token supply contracts as real inference demand increases. # 4. Token Utility Staking, Discounts, and Model Alignment Model Tokens ($MT) have direct utility within the system. By staking $MT: * Users receive discounted inference costs for the associated model. * Staked tokens are removed from circulation, reinforcing supply discipline. * Users gain access to additional protocol-level incentives. Discounts are capped and calculated at the protocol level to preserve sustainable revenue, ensuring that inference pricing never collapses below viable operating thresholds. # 5. Early Incentives Bootstrap Emissions During the early phase of a model’s lifecycle, the protocol distributes $FLOCK emissions to accelerate adoption. * Emissions are allocated only to models with real usage. * Distribution is weighted by usage volume and deployment age. * Within each model, emissions are routed primarily to $MT stakers. As the model matures and organic revenue grows, emissions decay and become a secondary incentive. Over time, usage-funded buybacks dominate emissions, allowing the system to transition from subsidized growth to sustainable operation. # Quickstart This guide walks through the FOMO launch lifecycle from both sides: * Real Model Asset Issuers launching a model * Users and RMAs Supporters participating in a model’s fundraising # Real Model Asset (RMA) Issuer Guide {% stepper %} {% step %} ### Step 1: Select a Model
1. Go to the Launch page. 2. Select your desired model. {% hint style="info" %} Each model corresponds to a predefined inference pricing tier and an allowed fundraising range. These parameters are fixed by the platform to ensure economic sustainability. {% endhint %} {% endstep %} {% step %} ### Step 2: Configure Your Model Token ($MT)
Configure $MT economics: 1. Name your deployment and define: * Model token name * Ticker symbol * Description 2. Review the pre-configured parameters, including: * Inference pricing tier * Fundraise min / max range * Token distribution summary These values are automatically populated based on the selected model and cannot be arbitrarily changed. {% endstep %} {% step %} ### Step 3: Bundle the First Buy Order (Optional)
RMA Issuers may choose to bundle an initial token purchase at launch. * This provides a first-mover advantage by locking in the lowest point on the bonding curve * The first buy is executed atomically with token deployment, removing market-timing risk {% hint style="info" %} The bundled first buy is subject to a hard cap of 25% of the total $MT supply to prevent excessive concentration at launch. {% endhint %} {% endstep %} {% step %} ### Step 4: Confirm Launch Fee Before initiating the Real Model Asset Offering (RMO), the RMA Issuers must confirm and approve the launch-related fees. This confirmation is required to proceed with model deployment and on-chain configuration. {% tabs %} {% tab title="One-time launch fee" %} **One-time launch fee.** A fixed, non-recurring fee of $32768 FLOCK payable by the MTO at the time of initiating the RMO. This fee covers deployment setup, onchain configuration, and protocol overhead associated with launching a new model economy. {% endtab %} {% tab title="Combined Tax" %} **Combined tax** (base fee plus anti-sniping tax) starts at 99% and decreases by 1% per minute, until it reaches the base fee. {% endtab %} {% endtabs %} {% endstep %} {% step %} ### Step 5: Launch the Model Token Once confirmed: * The RMO is created * The fundraising period 7 days begins * Tokens are not minted during fundraising period You can now find your deployment on the Marketplace page.
Status indicators: * `Owned` — launched by you * `Live` — fundraising in progress * `Failed` - fundraising target not met and pledged principal refunded {% endstep %} {% step %} ### Step 6: Fundraising Period * Fundraising remains open for 7 days * Progress toward the minimum and maximum targets is tracked in real time * No action is required by RMA Issuers during this period {% endstep %} {% endstepper %} # Users and RMAs Supporters Guide {% stepper %} {% step %} ### Step 1: Discover a Model Token 1. Navigate to the Marketplace page. 2. Browse available model deployments and select a model token you want to support. {% endstep %} {% step %} ### Step 2: Participate in the Fundraise
* Swap $FLOCK → $MT through the bonding curve mechanism. * Token pricing is dynamic and increases as additional $FLOCK flows into the fundraise. * A 1.5% platform transaction fee is applied to each swap at execution. {% hint style="info" %} Note: Pricing during the fundraise follows a bonding curve and is not fixed. {% endhint %} {% endstep %} {% step %} {% hint style="warning" %} Note: $MT purchased during fundraising cannot be sold back into the internal market during fundraising period. {% endhint %} ### Step 3: Wait for the Fundraise Outcome * The fundraise remains open for a fixed period. * Progress toward the minimum and maximum funding targets is tracked in real time. * No further action is required until the fundraise concludes. {% endstep %} {% endstepper %} # Fundraise Outcomes After 7 days of fundraise, one of the following paths will apply.
Scenario 1: Happy Path — Maximum Target Reached * Graduation is triggered automatically * Tokens are minted * Liquidity is created * The model proceeds to deployment
Scenario 2: Happy Path — Minimum Target Reached * Graduation must be triggered manually * Graduation is permissionless that anyone can trigger it
**Action:** * Click “Graduate Token” to launch the liquidity pool
Scenario 3: Unhappy Path — Minimum Target Not Reached * The fundraise fails * Tokens are not minted
**Action:** * Click **“Redeem”** to reclaim pledged funds {% hint style="warning" %} Launch fees and transaction fees are not refundable. Only the pledged $FLOCK principal is returned. {% endhint %}
### After Graduation Once graduated: * The model token becomes tradable * Marketplace status updates to “Tradable on Deluthium” * Clicking the token redirects users to the Deluthium swap page {% hint style="warning" %} Note: Deluthium is currently not available in the US {% endhint %} From this point forward:
* The model will be deployed on the FLock API Platform * Inference usage drives revenue, buybacks, and rewards # Roadmap The 2025–2026 roadmap outlines FLock’s long-term trajectory as a decentralised AI coordination and assetisation platform. Rather than a fixed delivery schedule, it serves as a directional framework that maps how core infrastructure, ecosystem layers, and governance mechanisms evolve over time. This roadmap is designed to communicate strategic priorities, sequencing logic, and system-level progression across platform development, ecosystem expansion, and global adoption. As the protocol and market conditions evolve, specific initiatives may iterate or adapt, while the underlying direction remains focused on building scalable, interoperable, and permissionless AI infrastructure. # 2025 Roadmap FLock Roadmap for 2025
#### **FLock Roadmap 2025** **Q4 2024: Launch & Strategic Foundation**\ FLock enters a major growth phase with the deployment of the $FLOCK token (TGE) and launch of its decentralized training platform on **Base mainnet**. This quarter also includes the **strategic round led by DCG** and the introduction of the **FLock Foundation Model for Web3**, laying the groundwork for decentralized AI model collaboration and governance. **Q1 2025: Web3 Benchmarks & Partnerships**\ The focus shifts to establishing **FLock Web3 model benchmarks** and onboarding **multi-task partnerships** with leading Web2 and Web3 firms, including **Alibaba Cloud’s Qwen, Base Network, and HKG AI**. The **Elite Trainer Plan** launched to empower advanced contributors within the ecosystem. **Q2 2025: Tokenomics v2 & Research Recognition**\ FLock upgrades its tokenomics to **V2 (gmFLOCK)**, enhancing incentives for federated AI participation. The **Bittensor Subnet 96** went live, integrating on-chain federated training into broader AI economies. FLock’s innovation was recognized globally with selection for the **ICML 2025 Workshop** and inclusion in the **CB Insights AI 100 for 2025**. **H2 2025: Edge AI & Ecosystem Expansion**\ The second half of 2025 marks a major expansion across the FLock ecosystem. The **FL Alliance Beta (Edge AI Training)** will be released, followed by **Moonbase Beta**, FLock’s platform for AI Agent deployment and earning. The inaugural **FLockCON** will convene global developers and partners, and **Task Creation Support** will be added to **AI Arena**, enabling open participation in AI model training. The roadmap concludes with the establishment of **FLock CVC**, catalyzing strategic investments and long-term ecosystem growth. # 2026 Roadmap FLock Roadmap for 2026
#### **FLock Roadmap 2026** **Q1 · Platform & Infrastructure**\ Q1 focuses on establishing FLock’s core platform and infrastructure layer. **The FOMO platform will launch in beta**, marking the first public-facing deployment of model assetization and distribution. In parallel, FLock will initiate its first **Robotic AI collaboration** with a leading Asian AI and gaming provider to validate real-world embodied AI use cases. **API Platform 2.0** will also be released, introducing enhanced developer tooling and smoother integration to support external builders and early ecosystem partners. **Q2 · Ecosystem & Community**\ Q2 shifts toward ecosystem formation and capital coordination. **FLock Venture Studio** will be launched as a corporate venture arm to incubate and invest in early-stage AI-native projects. **AI Arena will undergo a major upgrade** to support advanced reinforcement learning use cases, including tokenised securities, stablecoin dark pools, and prediction markets. At the research layer, FLock will establish **institutional partnerships with UK-US-APAC academic teams** to explore decentralised AI frontiers, alongside an FLock EIP upgrade built on ERC-8004. This quarter will also see **the launch of permissionless model tokens** and the hosting of **FLockCON Dubai** as the flagship ecosystem conference. **Q3 · Market Expansion**\ Q3 centers on geographic and vertical expansion. FLock will begin **global governance pilots with influential IGOs**, starting in southern China and the Middle East, to explore AI coordination in public and quasi-public sectors. **FOMO 2.0** will roll out with model token ($MT) voting mechanisms and key feature upgrades. **AI Arena will expand beyond text and RL** to support image and video generation models, while **cross-platform integration** will enable AI Arena models to be deployed directly through the API Platform and FOMO. At the same time, FLock will deepen **strategic engagement with publicly listed companies** as AI partners and enterprise clients. **Q4 · Global Adoption**\ Q4 focuses on scaling toward global adoption and infrastructure maturity. **FOMO will expand worldwide** to drive broad user adoption of model assets and decentralised AI workflows. **AI Arena will evolve into a multi-model platform**, adding support for audio and speech generation. On the infrastructure side, **FLock will collaborate with major AI inference gateway providers** to strengthen production-grade deployment capabilities, while **continuing network scaling**, ecosystem growth, and protocol hardening to support long-term global usage. # Overview Tokenomics forms the backbone of our permissionless, performant, decentralised AI system which currently comprises three elements - [AI Arena,](https://docs.flock.io/flock-product/ai-arena) [FL Alliance](https://docs.flock.io/flock-product/fl-alliance), and [FOMO](/flock-tokenomics/network-participation/fomo). * **AI Arena:** Developers compete on the best AI models on common validation datasets in a Kaggle-style leaderboard, using their own or decentralised compute. * **FL Alliance:** Developers collaborate to fine-tune and improve the AI models (usually the best models from AI Arena) with proprietary data. * **FOMO:** Models trained on AI Arena or fine-tuned on FL Alliance are displayed here for community members to use or host. In following sections, we lay out the role our token plays in incentivising participation and ensuring security in a permission-less manner. # Incentivising open source model development FLock incentivises training participants (training nodes, validators, delegators, FL clients, etc) to behave honestly and actually contribute to the system. Their rewards are based on the accumulative staking amounts in training tasks and each participants’ relative performance. Weight of staking amounts is decided by a Decentralised Autonomous Organisation (DAO) voting. Each individual’s relative performance is decided by FLock consensus. FLock incentivises training in AI Arena and FL Alliance by daily token emission. The proportion between the two is dynamic per month and can be refined by the community through the DAO voting. In AI Arena, for training nodes, rewards depend on the relative staking amount of this task against all tasks, the stake of a given training node in a given task, as well as the quality of the training node’s submission, measured by its rank amongst its peers . As for validators, rewards depend on three factors: (i) the quality of the validation, determined by how validators vote compared to the majority consensus; (ii) how much validators stake; (iii) the number of submissions that the given validator has successfully validated. For delegators, rewards depend on the quality of the validations produced by the delegated validator, as well as how much the delegators stake. As for FL Alliance, the participants will assigned to be the roles of voter and proposer randomly at each round. Their rewards at each round depends on the reward pool for the given task (initialised when a task is first created), remaining rounds in the task, stake amount of participants, and the total stake amount of all good participants (see [here](/flock-tokenomics/network-participation/fl-alliance/fl-nodes) for how “good” is being determined). In FOMO, rewards are distributed to Real Model Asset (RMA) Issuers, model token ($MT) stakers, inference users through a combination of daily $FLOCK emissions, inference-linked buybacks, staking incentives, and revenue sharing. For RMA Issuers, rewards depend on the net inference revenue generated by the deployment, creator fees earned during the Real Model Offering (RMO), deployment-level $FLOCK emissions, and the long-term performance of the associated model economy. For $MT stakers and inference users, rewards depend on the amount of $MT staked, the user’s gross inference usage, the deployment’s relative revenue contribution across all active deployments, and the deployment’s freshness score, which decays gradually over time. # Security The FLock system is designed to be resilient against a wide array of potential attacks, ensuring the integrity and security of its operations. For instance, Sybil attacks are mitigated by requiring participants to stake a minimum amount of assets, making it costly to control multiple identities. Furthermore, validators are kept unaware of the model origins, reducing the risk of collusion, and only the top-performing training nodes and validators receive rewards, discouraging poor performance and manipulation. To mitigate DoS attacks, the Flock system implements rate limiting, preventing any single participant from monopolising resources. Free-rider attacks are addressed by rewarding only the top contributors, ensuring that participants who do not genuinely contribute cannot benefit. The use of dual datasets (Dataset A and B) in evaluations prevents lookup attacks, as optimizing for one dataset does not guarantee success in the other. For FL model poisoning attacks, a majority voting system and slashing mechanism protect the model's integrity, punishing malicious actors and discouraging future attempts. These measures collectively fortify the FLock system against a range of threats, promoting a secure and reliable environment for participants. # Token Utility In the following sections, you will understand both the supply for and demand of our native token FLOCK # Supply ### 1. Emission FLock's ecosystem will feature `FLOCK` tokens, set to be distributed to various stakeholders through an initial token emission and a strategically designed reward allocation system over time. Participants will receive rewards in FLOCK tokens based on their contributions to the system. The total supply of `FLOCK` is capped at 1 billion tokens. See [here](/flock-tokenomics/token-allocations) for token allocations details. ### 2. Slashing FLock has robust mechanisms in place to ensure the system's integrity and reliability by penalising participants who engage in malicious activities. Specifically, in FL Alliance, if a participant is found to be violating the system's rules or attempting to undermine the network through malicious actions, they may face slashing. Parts of the slashed tokens are rewarded to the honest participants (specifically, it goes to the ones who call the slashing function). This slashing mechanism protects the system from immediate threats by removing or deterring malicious actors, thereby fostering a culture of trust and cooperation among participants. # Demand 1**. Utility** In order to participate in the FLock’s ecosystem, users first need to stake FLOCK, whether it’s for model creation, training, or validation. This is to ensure that participants are incentivised to behave honestly in the system. In the event of abusive or dishonest behaviour, the user’s staked tokens will be slashed as a punishment. In addition, FLock allows participants to be supported by delegators through FLOCK token delegation - delegators delegate FLOCK to participants; in return, delegators take a share of the rewards earned by participants. Consequently, it creates a dynamic and competitive environment where participants are incentivised to not only perform optimally but also establish and maintain appealing conditions in order to attract current and prospective delegators. *Note: The delegation feature may not be accessible in some countries due to local laws and regulations.* **2. Payment** Our FLOCK community holders may periodically assess lists of top and trending models hosted at FLock’s platforms. This allows for rewarding prominent model contributors and creates a healthy competitive environment for the community to build better models. Users participate directly in the ecosystem's economy by spending FML tokens to access models hosted on FLock. This mechanism is intended to drive demand for FLOCK as the platform expands and usage rises. Developers within the FLock system may also be required to pay fees in FLOCK to join the system. This measure helps mitigate potential DoS attacks by malicious participants. **3. Governance** FLock token holders are empowered to actively engage in the system’s governance through a DAO, a pivotal mechanism that democratises decision-making process. This participatory model allows token holders to propose, debate and vote on various aspects of the ecosystem’s development and management, ranging from technical updates and protocol modifications to treasury management and community initiatives. The voting process in the FLock ecosystem is designed to be transparent, fair, and resistant to manipulation. To submit a proposal for voting, a proposer must first stake a specific number of tokens. This staking requirement acts as a barrier to frivolous or potentially scam proposals, as the proposer risks losing their staked tokens if the community deems the proposal to be invalid or malicious. In return, FLock’s platform offers proposal rewards to incentivise users to submit high-quality, valuable proposals that contribute to the growth and development of the ecosystem. *NOTE: The FLock team is carefully considering the specifics of DAO design, governance mechanisms, legal structure, and on-chain tooling to support DAO operations. The information above describes our initial high level vision for the DAO. It is subject to change and we will share more detailed information for FLock’s implementation as we approach its launch date.* # Network Participation In this section, you will understand various reward mechanisms for different participants in FLock’s ecosystem in great details. Each sub-section is accompanied with examples. The FLock system enables participants to contribute models, data, or computing resources in a modular way. The FLock network promotes the creation of diverse, purpose-built models developed and maintained by and for communities, with incentive-compatible mechanisms. Participants can earn rewards by participating in the creation, training or validation of a machine learning task, or by delegating their tokens to other FLock participants. The rewards are determined by the efforts, such as staking amounts or computational resources, that participants contribute to the system, fostering a fair, equitable and transparent ecosystem running on blockchain. Moreover, the requirement of staking can mitigate potential Sybil attacks from malicious participants. ### Task Creation Each newly created AI Arena and FL Alliance task has the option to undergo a verification process conducted by the community-led DAO. This process is designed to ensure that tasks meet the necessary standards of quality and alignment with the ecosystem's goals. Once a task successfully passes verification, it becomes eligible for FLOCK's daily emissions, providing the task creator with additional resources to incentivise participation and collaboration. On the other hand, if a task is created permissionlessly without the FLock DAO’s verification, the responsibility falls on the task creator to self-fund the task. This involves using their own FLOCK to cover the costs associated with reward allocations for various participants. While this route allows for greater flexibility and decentralisation in task creation, it also places the financial burden of supporting the task’s ecosystem on the creator. This mechanism is designed to balance innovation with quality control, ensuring that only well-constructed tasks benefit from community-supported rewards while still allowing for creative freedom in the ecosystem. ### Reward between AI Arena and FL Alliance Once tasks are created, the distribution of rewards between DAO-verified AI Arena and FL Alliance tasks is dependent on the their relative stake amount of active tasks. As such, the rewards of FLOCK allocated to all active AI Arena tasks will be: $$ R^{AI} = C\_0 \cdot \frac{S^{AI}}{S^{AI} + S^{FL}} $$ and for all active FL Alliance tasks: $$ R^{FL} = C\_0 \cdot \frac{S^{FL}}{S^{AI} + S^{FL}} $$ in which $$C\_0$$ is the daily emission of FLOCK, $$S^{AI}$$ refers to the total stake amount of all active AI Arena tasks and $$S^{FL}$$ refers to the total stake amount of all active FL Alliance tasks. # AI Arena AI Arena is FLock.io's decentralised AI training platform. For more details about AI Arena, check the docs [here](/flock-products/ai-arena). This section introduces the tokenomics for different participants in AI Arena. # Task Creator Task creation is the first stage of FLock’s decentralised AI training cycle. Creators define the desired models and submit tasks to the platform. Anyone who satisfies the following conditions can participate as a task creator. Thus, the system is, by design, democratic, making it accessible to a broad range of stakeholders. This fosters a sense of ownership and active involvement amongst the FLock community. In order to become a task creator, one has to fulfil one or more of the requirements below: (1) stake a sufficient amount of FLOCK (2) have successfully trained or validated a task before, based on on-chain records (3) have a reputation in the ML space or is a domain expert in relevant fields, which is verified by the FLock community In addition to the desired model becoming available for the task creator’s use, the creator may also receive rewards proportional to their stakes. \*This feature is not public yet. # Data Provider Data plays a crucial role in training models. Data generators provide data to FLock’s ecosystem and gain rewards in FLOCK in return. Data generator follow a similar requirements for task creators: (1) stake a sufficient amount of FLOCK (2) had successfully trained or validated a task before, based on on-chain records (3) had a reputation in the ML space or is a domain expert in relevant fields, which is verified by the FLock community \*This feature is not public yet. # Training Node Training nodes are responsible for training and fine-tuning the AI tasks initiated by the task creators. This mechanism ensures the integrity and health of the ecosystem, as nodes have vested interests via staking. In return, the nodes will be rewarded in proportion to their contributions. To become a training node, a user has to stake FLOCK. ### 0. Overview: reward drivers for training nodes Put simply, a training node’s daily return from a task depends on three factors: (1) the relative staking amount of this task against all tasks, meaning a training node’s stake in a particular task will indirectly affect it’s rewards from that task; and (2) a training node’s stake in this task as well as stake delegated to this training node; and (3) quality of the node’s submission, as shown by the node’s relative ranking. Specifically, it is a geometric series, along with its ranking, multiplied by the relative stake of this task. It’s important to note that rank is being used here to determine the quality of the training node’s work, not other metrics such as absolute scores, primarily because scores can come very closely between nodes. Such design decision is believed to make reward calculation fairer and easier. Calculation of reward distributions for training nodes follow a three-step formula: ### 1. Reward distribution within a single AI Arena task Within a single AI Arena task, the reward distribution between training nodes and validators is determined based on their relative stake amounts. We assume there are 𝑛 submissions $$(𝑂\_1, . . . , 𝑂\_𝑛 )$$ from 𝑛 training nodes with stakes $$(𝑡\_1, . . . , 𝑡\_𝑛 )$$, and 𝑚 validators $$(𝑉\_1, . . . , 𝑉\_𝑚 )$$ with stakes $$(𝑠\_1, . . . , 𝑠\_𝑚)$$. Each validator $$𝑉\_𝑗 (1 ≤ 𝑗 ≤ 𝑚)$$ evaluates the $$n$$ models submitted by the training nodes. Let the total daily reward allocated to a task be denoted as $$R\_0$$​ and the parameter $$\gamma$$ controls the split rewards, defining the balance between fixed and stake-dependent reward components. The total rewards for training nodes are: $$ R\_0 \cdot \left( \gamma + (1 - 2\gamma) \cdot \frac{\sum\_{i=1}^{n} t\_i}{\sum\_{i=1}^{n} t\_i + \sum\_{j=1}^{m} s\_j} \right) $$ ### 2. Rewards for training nodes & their delegators We can now compute the total rewards allocated for the training nodes as well as their delegators, which is based on the quality of their submission and their total amount of stake: $$ f\_i(g\_i, t\_i) = \frac{g\_{i} \cdot t\_i^{\alpha\_t}}{\sum\_{k=1}^{n} g\_{k} \cdot t\_k^{\alpha\_t}} $$ In which $$t\_i$$ the total stake amount from the training node 𝑖 as well as its respective delegators, $$g\_i$$ is the scores of the submitted models from training node, whereas $$k$$ denotes a given training node’s rank amongst its peers in the same task. On the other hand, $$\alpha\_t$$ is a system parameter that determines the influence of the stake on the reward distribution. ### 3. Rewards for training nodes If a training node $$i$$’s stake in the task is $$t\_n$$ and stakes delegated to training node $$i$$ is $$t\_d$$ i.e. $$t\_i = t\_n + \epsilon \cdot t\_d$$, in which $$\epsilon$$ refers to the effective delegation amount. Specifically, effective delegation amount adjusts how much of the delegated stake $$t\_d$$​ is actually counted (i.e., how “effective” it is) when computing node $$i$$'s total stake $$t\_i$$. When $$\epsilon = 1$$, then the delegated stake $$t\_d$$ ​ is counted fully—delegations are treated just like the training node’s own stake. When $$\epsilon < 1$$, then the delegated stake is “discounted,” so training node $$i$$ only gets a fraction of $$t\_d$$ when accounting for its total stake, and vice versa. \ \ Thus, the actual reward for training node $$i$$ is: $$ f\_i \cdot \left(\sigma + (1-\sigma) \cdot \frac{t\_n}{t\_n+ t\_d}\right) $$ *Note that in the front-end, you will see a “reward-sharing ratio”, which refers to* $$(1 - \sigma)$$*, which means when reward-sharing ratio is 60%,* $$\sigma$$ *is 0.4. This ratio is set by training nodes and validators permissionlessly.* ### 4. Example Let’s assume daily total rewards for all AI Arena tasks for a given day is 309,157.68. We have 1 task with 2 nodes and 3 validators. Nodes A and B stake 3,000 and 3,500 FLOCK respectively, while validators A, B and C stake 3,000, 6,000 and 3,000 respectively. Node A also receives an additional 1,000 FLOCK from its delegators, which brings the $$t\_i$$ (total stake including delegated stake) to be 4,000 for Node A. For simplicity, we assume $$\gamma$$ to be 0 and $$\epsilon$$ to be in this example. First, for this given task, total rewards for \*all\* training nodes are: $$ R\_0 \times \frac{\sum\_{i=1}^n t\_i}{\sum\_{i=1}^n t\_i + \sum\_{j=1}^m s\_j} ;=; 309{,}157.68 \times \frac{6500}{6500 + 12000} \approx 108{,}623.7 $$ We can then compute the rewards for \*Node A and its delegators\*. We are assuming that the scores for Node A and B are 0.501435 and 0.498565 respectively. Consider αt​=1, rewards for Node A (together with delegators) are: $$ f\_i(g\_i, t\_i) \= \frac{g\_i \cdot t\_i}{\sum\_{k=1}^{n} g\_k \cdot t\_k} \= \frac{0.501435 \times 4000}{(0.501435 \times 4000) + (0.498565 \times 3500)} \times 108{,}623.7 \= 58{,}084 $$ Finally, given 𝜎=0.4, the actual rewards for \*Node A alone\* is: $$ f\_i \cdot \Bigl(\sigma + (1-\sigma),\frac{t\_n}{t\_n + t\_d}\Bigr) \= 58{,}084 \times \Bigl(0.4 + 0.6 \times \tfrac{3000}{4000}\Bigr) \= 49,371.40 $$ # Validator Validators are responsible for evaluating the work submitted by training nodes. Similarly, validators have to stake before the evaluation tasks, and can be rewarded upon task completion. This is essential to maintaining the quality and reliability of the FLock network. ### 0. Overview: reward drivers for validators The reward percentage for validator depends on: 1. how close the score is to the consensus among all the validators, measured by score variance (calculated off-chain) 2. amount the validator (and its delegators) staked 3. the number of submissions that the validator validated Specifically, the reward distribution for validators follows a two-step calculation: ### 1. Reward distribution within a single AI Arena task Similar to reward calculation for training nodes, the rewards for all validators in the same given AI Arena task is: $$ R\_0 \cdot \left( \gamma + (1 - 2\gamma) \cdot \frac{\sum\_{j=1}^{m} s\_j}{\sum\_{i=1}^{n} t\_i + \sum\_{j=1}^{m} s\_j} \right) $$ Here, we assume there are 𝑛 submissions $$(𝑂1, . . . , 𝑂𝑛 )$$from $$n$$ training nodes with stakes $$(t\_1, . . . , 𝑡\_n)$$, and 𝑚 validators $$(𝑉\_1, . . . , 𝑉\_𝑚 )$$ with stakes $$(𝑠\_1, . . . , 𝑠\_𝑚 )$$. Each validator $$𝑉𝑗 (1 ≤ 𝑗 ≤ 𝑚)$$ evaluates the $$n$$ models submitted by the training nodes. The total daily reward allocated to a task is denoted as $$R\_0$$​ and the parameter $$\gamma$$ controls the split rewards, defining the balance between fixed and stake-dependent reward components. ### 2. Reward distribution for validators The formula for a given validator’s daily return is calculated as such: Consider a validator' stake in the task is $$s\_v$$ and stakes delegated to validator is $$s\_d$$ i.e. $$s\_i = s\_v + \epsilon \cdot s\_d$$, in which $$\epsilon$$ refers to the effective delegation amount. Specifically, effective delegation amount adjusts how much of the delegated stake $$s\_d$$​ is actually counted (i.e., how “effective” it is) when computing validator's total stake $$si$$. When $$\epsilon = 1$$, then the delegated stake $$s\_d$$ ​ is counted fully—delegations are treated just like the training node’s own stake. When $$\epsilon < 1$$, then the delegated stake is “discounted,” so the validator only gets a fraction of $$s\_d$$ when accounting for its total stake, and vice versa. $$ f\_i\cdot F \cdot (\sigma + (1-\sigma) \cdot \frac{s\_v}{s\_v+ s\_d}) $$ Specifically, * F refers to the performance of the validation, which is calculated through off-chain consensus * $$f\_i$$ is the rewards for all validators * σ is the guaranteed validator return against delegators * $$S\_v$$​ is the stake amount of this validator * $$S\_d$$ is the stake amount delegated to this validator ### 3. Example Let’s assume daily total rewards for all AI Arena tasks for a given day is 309,157.68. We have 1 task with 2 nodes and 3 validators. Nodes A and B stake 3,000 and 3,500 FLOCK respectively, while validators A, B and C stake 3,000, 6,000 and 3,000 respectively. Node A also receives an additional 1,000 FLOCK from its delegators, which brings the $$t\_i$$(total stake including delegated stake) to be 4,000 for Node A. For simplicity, we assume $$\gamma$$ to be 0, and $$\epsilon$$ to be 1 in this example. First, for this given task, total rewards for \*all\* validators are: $$ R\_0 \times \frac{\sum\_{j=1}^m s\_j}{\sum\_{i=1}^n t\_i + \sum\_{j=1}^m s\_j} \= 309{,}157.68 \times \frac{12000}{6500 + 12000} \approx 200{,}534.0 $$ Then, if we assume validator A has a score of 0.472768, the the reward for \* validator A only\* is: $$ f\_i \cdot F \cdot \Bigl(\sigma + (1 - \sigma),\tfrac{S\_v}{S\_v + S\_d}\Bigr) \= 200{,}534 \times 0.369 \times \Bigl(0.4 + 0.6 \times \tfrac{3000}{3000 + 0}\Bigr) ;\approx; 73{,}997 $$ # Delegator Delegators are responsible for delegating stake to training nodes and/ or validators. ### 0. Overview: reward drivers for delegators Reward for the delegator depends on: 1. quality of the training nodes/ validators selected, as measured by the scores/ ranks training nodes/ validators received based on the quality of their work 2. amount of stake delegator delegated ### 1. Reward distribution for delegators If we consider $$f\_i$$ to the the rewards distributed to training nodes ***and*** their delegators as explained [here](/flock-tokenomics/network-participation/ai-arena/training-node), then the reward for delegator to this given training node is: $$ f\_i \cdot (1-\sigma)\cdot\tfrac{ t\_d }{t\_n + t\_d} $$ Here, $$t\_d$$ refers to the amount the delegator delegated to the given training node, whereas $$t\_n$$ is the stake amount from the same training node. Similarly, if a delegator delegated FLCOK to a validator, the reward for this delegator is: $$ f\_i\cdot (1 - \sigma) \cdot \frac{\ s\_d}{s\_v+ s\_d} $$ Here, $$f\_i$$ refers to the rewards earned by validators ***and*** their delegators as explained [here](/flock-tokenomics/network-participation/ai-arena/validator). $$s\_d$$ is the delegated amount from delegator to this validator, whereas $$s\_v$$ refers to the stake amount from the validator. *Note that in the front-end, you will see a “reward-sharing ratio”, which refers to* $$(1 - \sigma)$$*, which means when reward-sharing ratio is 60%,* $$\sigma$$ *is 0.4. This ratio is set by training nodes and validators permissionlessly.* ### 2. Example Let's assume rewards for a given training node and its delegator ( $$f\_i)$$ is 58,084, $$\sigma$$ to be 0.[^1]4, the training node stakes 3,000 and the delegator delegate 1,000. Consider $$\epsilon$$ to be 1 in this example. The reward for the delegator alone (excluding that to the training node) is: $$ f\_i \cdot (1-\sigma)\cdot\tfrac{t\_d}{t\_n + t\_d} \= 58,084 \times \Bigl(0.6 \times \tfrac{1000}{3000 + 1000}\Bigr) ;\approx; 8{,}712.6 $$ Note that rewards in delegation pools are time-weighted to balance fairness for long-term participants and incentivize new delegations. As pools grow, rewards stabilize, promoting sustained engagement. Also, delegators must maintain their stake for at least 24 hours before un-delegating. This ensures meaningful contributions and prevents exploitative behaviors. Parameters like reward splits ( $$\gamma$$) are fine-tuned through DAO voting. This democratized control keeps the ecosystem adaptive and equitable. [^1]: here is 0.4? # Delegation Pool Rewards Explainer This page gives a detailed explanation about rewards for delegation pools. ### Overview The rewards transferred to a delegation pool are distributed based on a time-weighted delegation amount. Within the same pool, if more delegators join, the rewards (temporally fixed, as they are transferred every 24 hours at 0:00 UTC) will be shared among all participants, potentially reducing the rewards for an individual in the short term. However, as the pool grows with larger delegation amounts, the daily rewards transferred to the pool can also increase. This leads to a gradual rise in the total claimable rewards for all participants. For instance, when a new participant delegates a significant amount, the proportional share of rewards for existing participants might initially decrease due to the adjustment in the total time-weighted delegation amount. This happens because the `claimable` function calculates the rewards for each participant based on their time-weighted contribution relative to the overall pool size. However, as the system stabilizes and the increased delegation amount results in higher daily rewards, all participants, including the new and existing ones, benefit from the larger pool of rewards over time. This mechanism ensures a dynamic balance between fairness and incentive for long-term delegation. Existing participants are rewarded for their earlier contributions through accumulated time-weight factors, while new participants contribute to the growth of the reward pool. As the delegation pool matures, the fluctuations in individual rewards diminish, creating a more stable and predictable distribution. This equilibrium encourages sustained engagement and supports the long-term sustainability of the reward system. For more details, please check our code at ### Calculation On Day 1, at 00:01 UTC, Address A delegates $$a$$ FLOCK to a pool. Over the course of $$n$$ days, with daily rewards of $$r\_1$$ FLOCK transferred to the pool, the total claimable rewards in the pool are $$n×r\_1$$ FLOCK. By the end of Day $$n$$, Address A can claim the rewards: $$ R\_1=n\times r\_1 $$ On Day $$n+1$$, at 00:01 UTC, another participant, Address B, delegates $$b$$ FLOCK into the same pool. At 12:00 UTC on Day $$n+1$$, the rewards for Day $$n+1$$have not been transferred to the pool (because the new daily reward will be transferred at 00:00 UTC on Day $$n+2$$), but the claimable rewards for Address A remain based on the previous time-weighted contributions. At this point: * Total claimable rewards in the pool remain $$n \times r\_1$$ FLOCK. * Because B joined only 12 hours ago, based on our time‐weight logic, B’s stake has “0.5 days” of weighting, while A’s stake has $$n+0.5$$ days accumulated. Thus, address A's claimable rewards are updated as: $$ R\_2=n\times r\_1 \times \frac{(n + 0.5) \times a}{(n + 0.5) \times a+ b \times 0.5} $$ However, as the delegation amount in the pool increases, the rewards transferred for Day $$n+1$$ also increase. For example, if $$r\_2$$ FLOCK are transferred to the pool as rewards for Day $$n+1$$, then: * The total claimable rewards in the pool become: $$n \times r\_1 + r\_2$$ FLOCK * Address A’s claimable rewards are recalculated as: $$ R\_3=(n\times r\_1 +r\_2) \times \frac{(n + 1) \times a}{(n + 1) \times a+ b \times 1} $$ **Assume that other network conditions do not change, and the rewards transferred to the pool are proportional to the total delegation amount**, i.e., $$\frac{r\_2}{r\_1} = \frac{a+b}{a}$$. Therefore: $$ R\_3=(n +\frac{a+b}{a}) \times r\_1 \times \frac{(n + 1) \times a}{(n + 1) \times a+ b \times 1} $$ Thus, the ratio between $$R\_3$$ and $$R\_3$$ is: $$ \frac{R\_3}{R1} = \frac{1}{n} \times (n +\frac{a+b}{a}) \times \frac{(n + 1) \times a}{(n + 1) \times a+ b \times 1} = \frac{1}{n} \times \frac{(n+ 1) \times a+b}{a} \times \frac{(n + 1) \times a}{(n + 1) \times a+ b} = \frac{n+1}{n} $$ ***This means that the overall rewards for the address A are increasing over time*** [***under the***** network assumption**](#user-content-fn-1)[^1]***.*** ### Examples For $$n=2, a= 100, b= 1000, r\_1 = 10, r\_2 = 110$$: * $$R\_1$$: Address A’s rewards on Day $$n$$ before Address B joins: `20 FLOCK`. * $$R\_2$$: Address A’s rewards on Day $$n+1$$ after Address B joins but before new rewards are transferred: `6.67 FLOCK`. * $$R\_3$$: Address A’s rewards on Day $$n+1$$ after new rewards are transferred to the pool: `27.69 FLOCK`. And for $$n=30, a= 1000, b= 1000, r\_1 = 10, r\_2 = 20$$: * $$R\_1$$: Address A’s rewards on Day $$n$$ before Address B joins: `300 FLOCK`. * $$R\_2$$: Address A’s rewards on Day $$n+1$$ after Address B joins but before new rewards are transferred: `295.1612903 FLOCK`. * $$R\_3$$: Address A’s rewards on Day $$n+1$$ after new rewards are transferred to the pool: `310 FLOCK`. Here are more examples with various settings: | r0 | 10 | 10 | 10 | 10 | 10 | | --------- | ------- | ------- | ------- | ------- | ------- | | **r1** | 110 | 110 | 20 | 20 | 12 | | **a** | 100 | 100 | 1000 | 1000 | 5000 | | **b** | 1000 | 1000 | 1000 | 1000 | 1000 | | **n** | 2 | 30 | 30 | 60 | 60 | | **R1** | 20 | 300 | 300 | 600 | 600 | | **R2** | 6.67 | 257.75 | 295.16 | 595.08 | 599.01 | | **R3** | 30 | 310 | 310 | 610 | 610 | | **R2/R1** | 33.33% | 85.92% | 98.39% | 99.18% | 99.83% | | **R3/R1** | 150.00% | 103.33% | 103.33% | 101.67% | 101.67% | ### Code & Remarks ```solidity /** * @notice Get the total claimable rewards for a delegator * @param _delegator The delegator address */ function claimable(address _delegator) public view returns (uint256) { uint256 rewards = config.getFlockToken().balanceOf(address(this)).sub(totalDelegationAmount); uint256 receiverTemporalDelegationAmount = receiverTemporalDelegation(_delegator); uint256 totalTemporalDelegationAmount = totalTemporalDelegation(); if (totalTemporalDelegationAmount == 0) { return 0; } return receiverTemporalDelegationAmount.mul(rewards).div(totalTemporalDelegationAmount); } ``` Such significant changes in claimable rewards typically occur when $n$ is small, and the newly joined delegation amount is relatively large compared to the existing delegation amounts in the pool. This is because, during these early stages, the time-weighted delegation factor (represented by `receiverTemporalDelegationAmount` and `totalTemporalDelegationAmount` in the `claimable` function) is more sensitive to changes introduced by new participants. From the function logic: 1. The total rewards available for distribution (`rewards`) are derived from the balance of the FLOCK token in the pool, excluding the total delegation amount (`totalDelegationAmount`). 2. The claimable rewards for a specific delegator are proportional to their `receiverTemporalDelegationAmount`, which reflects their time-weighted contribution to the pool. 3. Any large addition to the pool's delegation amount significantly alters the `totalTemporalDelegationAmount`, impacting the proportional share of claimable rewards for all participants. However, as the delegation pool operates over an extended period, and more participants join, the pool's `totalTemporalDelegationAmount` stabilizes due to accumulated time weights across all participants. At this point, the relative impact of any single new delegation becomes negligible. Consequently, fluctuations in claimable rewards diminish, and the system approaches a steady state where the rewards distribution is more predictable and less volatile. ### Free-Rider Delegation? Impossible! One might wonder if Address B, in our example, could exploit the system by performing malicious activities to gain rewards without making a meaningful contribution—essentially attempting free-rider delegation. Such actions might involve the following steps: 1. Address B delegates to the pool and immediately gains a share of the unclaimed rewards already in the pool. 2. Address B quickly claims the rewards from the shared pool. 3. Address B then undelegates from the pool before the rewards for Day n+1 are transferred, thereby avoiding the need to actually contribute to the delegation amount when rewards are distributed in the FLock Task Manager contract. This sequence might appear to allow Address B to game the system by gaining rewards without a genuine long-term commitment to the pool. ### Why is Free-Riding not Possible? This kind of exploit is effectively prevented by a critical safeguard in our system: **delegators are required to maintain their delegation for at least 24 hours before they are eligible to undelegate their stake.** This mechanism ensures that all participants in the pool contribute meaningfully to the delegation amount for a sufficient period before benefiting from the shared rewards. By enforcing this time constraint, the system maintains fairness and eliminates opportunities for free-rider delegation. See the code: ```solidity /** * @notice Undelegate tokens * @param _amount The amount of tokens to undelegate */ function undelegate(uint256 _amount) external { address delegator = msg.sender; require(lastStakeTimestamp[delegator] + 1 days < block.timestamp, "You can't undelegate before 1 day"); require(delegationOf(delegator).amount >= _amount, "User has insufficient token delegated"); require(config.getFlockToken().transfer(delegator, _amount), "transfer failed"); addPastTemporalDelegation(delegator, delegationMap[delegator]); delegationMap[delegator] = DelegationInfo(delegationMap[delegator].amount.sub(_amount), block.timestamp); updateTotalDelegationInfoAndPastTemporalDelegation(0, _amount, 0, 0); totalDelegationAmount -= _amount; if (delegationOf(delegator).amount == 0) { delegators.remove(delegator); } config.getMainManager().afterDelegationUpdate(user); emit Undelegate(delegator, user, _amount); } ``` See [here](/flock-products/ai-arena/smart-contracts-deep-dive) for deep-dive into our smart contracts for AI Arena. [^1]: # FOMO ### The Franchise Model for AI Inference FOMO introduces a new economic model for AI inference: a franchise-style system where every model deployment becomes its own programmable micro-economy. Instead of treating inference as a stateless commodity sold by centralized gateways, FOMO transforms model usage into an onchain economic loop powered by: * Revenue-backed model economies * Usage-linked token burns * Demand-driven emissions * Programmable inference discounts * Transparent value routing * Stake-gated model-specific incentives At the center of the system are two assets: **$FLOCK** is the macro-level ecosystem token. It is used for protocol incentives, governance, emissions, launch participation, and platform-level value capture. Inference revenue can also be routed into $FLOCK buybacks and burns, linking network-wide demand to long-term token scarcity. **$MT**, or Model Token, is a deployment-specific token. Each $MT corresponds to a particular model deployment and its associated economic setup. A single model may have multiple deployments, and therefore multiple $MTs, depending on hosting configuration, pricing, and use case. In the current design, each deployment mints a fixed supply of **1,000,000 $MT**. Each Model Token represents a specific model deployment and its associated inference economy. As the model is used, revenue can be routed into token buybacks, burns, staking rewards, and protocol-level value accrual. In this design, API usage remains the primary signal of real demand, while staking determines who is economically aligned with a specific model deployment. Global ecosystem emissions remain accessible to active users, but model-specific incentive pools are reserved for participants who both use and stake the corresponding Model Token. #### Quick Reference | Lever | Global FLOCK effect | Reserved FLOCK / MT Reward effect | Notes | | -------------------- | --------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | API spend on MT | Multiplies `global_score` by `usage_share` | Multiplies `incentive_score` by `usage_share` | Usage is the base demand signal. Spend splitting does not increase total share. | | Stake on MT | Boosts `global_staking_factor` from `α` toward `1.0` using `α + (1 − α) × √stake_share` | Unlocks model-specific incentives through linear `stake_share` | No stake = no Reserved FLOCK or MT Reward. | | gmFLOCK balance | Multiplies `global_score` | Multiplies `incentive_score`, but only if the user has positive stake and usage | Uses effective gmFLOCK balance, weighted by remaining lock duration. Longer remaining lock duration gives more weight. | | MT incentive vintage | N/A | Larger pool while incentive is fresh | Time-limited, approximately 180 days per MT. | #### $MT Supply Distribution Each Model Token has a fixed supply of **1,000,000 $MT**, distributed as follows: | Allocation | Share | Purpose | | --------------------------- | ----: | ------------------------------------------------------- | | Public Sale | 40% | Sold during the RMO / FOMO launch | | Liquidity Pool | 20% | Paired with raised $FLOCK and migrated to DEX liquidity | | Incentive Reserve | 20% | Emitted to users and stakers over the incentive period | | RMA Issuer / MTO Allocation | 10% | Vested allocation for the issuer | | Platform Treasury | 10% | Vested allocation for FLock Platform | This structure gives each model deployment its own micro-economy: a fundraising phase, a liquidity base, user incentives, issuer upside, and platform alignment. #### Launch and Fundraising When a new model deployment is launched, participants can purchase $MT using $FLOCK through an internal market. The current design uses a **constant-product bonding curve**, similar to Uniswap v2, where price increases as more $FLOCK flows into the pool and $MT inventory decreases. Users cannot sell $MT back into the internal market during the fundraising phase. If the launch fails to reach its target by the deadline, pledges are cancelled and the token is not minted or distributed. If the launch succeeds, liquidity is migrated to an external DEX such as Aerodrome. #### Revenue Waterfall Once a model is live on the FLock API Platform, users pay for inference in fiat, USDC, or equivalent supported payment methods. After compute costs are paid, the remaining amount is treated as **Net Revenue**. The current waterfall is: | Destination | Share of Net Revenue | Function | | ---------------------- | -------------------- | -------------------------------------------- | | $FLOCK Buyback / Burn | 30% | Supports macro-token value capture | | Platform Treasury | 30% | Funds operations and platform sustainability | | $MT Buyback / Burn | 30% | Creates model-level deflation | | RMA Issuer / MTO Yield | 10% | Rewards the model deployment operator | This is the core usage-to-value loop: real inference demand creates revenue, revenue triggers buybacks, buybacks reduce token supply, and token scarcity reinforces the model economy. #### Daily Reward Streams Each supported $MT can distribute **three kinds of daily rewards**: 1. **Global $FLOCK Emission**\ A fixed daily amount of $FLOCK divided across supported MTs according to model usage. Within each MT, participants can earn from this pool through API usage. Staking improves a participant’s score, but non-stakers can still receive a share through the global non-staker floor. 2. **Reserved $FLOCK**\ A $FLOCK incentive pool dedicated to a specific MT, paid out over approximately 180 days. This pool is staker-gated: users must stake the relevant MT to be eligible, and actual distribution depends on their incentive score, which also includes API usage. 3. **MT Reward**\ A pool of the MT’s own token, also distributed over approximately 180 days. Like Reserved $FLOCK, this pool is staker-gated. Distribution is based on each eligible participant’s incentive score, which combines usage share, linear stake share, and the gmFLOCK multiplier. Together, these streams separate ecosystem-level usage rewards from model-specific stakeholder rewards. API usage alone can still earn Global $FLOCK, but unlocking Reserved $FLOCK and MT Reward requires staking the corresponding MT. #### Transition Emission During the first transition phase, emissions come from the **emission gap period**. This means FOMO can begin distributing incentives before the full long-term incentive structure is fully activated. This transition phase is useful because it gives the system a bootstrapping window: models can begin competing for usage, users can begin forming habits around the API Platform, and $MT economies can start producing measurable demand signals before the mature incentive regime takes over. #### Competition-Based Reward Share Within each supported $MT, rewards are distributed according to two parallel scoring systems: `global_score = usage_share × global_staking_factor × gmFLOCK_multiplier` `incentive_score = usage_share × incentive_staking_factor × gmFLOCK_multiplier` The normalized `global_score` determines a participant’s share of Global FLOCK Emission. The normalized `incentive_score` determines a participant’s share of Reserved FLOCK and MT Reward. Both scores are based on three factors: API usage share, staking factor, and gmFLOCK multiplier. The difference is that the staking factor is calculated differently for global rewards and model-specific incentives. **1. API Usage Share** Usage share measures how much API spending a participant contributes to a specific $MT compared to all other users of that $MT. ``` usage share = user spending on this MT / total spending on this MT ``` In **Season 1**, usage may be automatically mapped through the API Platform. In **Season 2 and forward**, usage should be mapped more explicitly through **model ID**, meaning users will need to generate usage through the correct model identity in order for that activity to count toward the corresponding $MT. This is important because FOMO rewards are model-specific. Spending on one model should not dilute or inflate reward share on another model. **2. Staking Factor** The staking factor now differs by reward bucket. For **Global $FLOCK Emission**, FOMO continues to use a square-root staking curve with a non-staker floor: `global_staking_factor = α + (1 − α) × √stake_share` This preserves accessibility for active API users. A participant who generates real usage can still earn Global $FLOCK even without staking, while stakers receive a higher score at equal usage. For **Reserved $FLOCK** and **MT Reward**, the staking factor is linear: `incentive_staking_factor = stake_share` There is no α floor for these model-specific incentive pools. A participant with zero stake has an incentive staking factor of zero, which means they receive no Reserved $FLOCK or MT Reward from that MT regardless of API usage. This creates a clear separation between demand contribution and model-specific economic alignment: usage can earn global emissions, but staking is required to unlock the incentive pools attached to a specific model deployment. **3. gmFLOCK Multiplier** gmFLOCK acts as a global score multiplier across supported $MTs. The multiplier is designed to be **non-linear**. As a participant holds more effective gmFLOCK, their boost approaches a higher effectiveness level, potentially close to **2x**, but with diminishing returns. This means large holders receive an advantage, but whales do not dominate the reward system linearly. Conceptually: ``` gmFLOCK multiplier = 1 + λ × G ``` Where G reflects a user’s effective gmFLOCK balance, normalized on a log-style or diminishing-return scale. Effective gmFLOCK balance is time-weighted by the remaining lock duration of the user’s gmFLOCK position. In other words, gmFLOCK that remains locked for longer contributes more weight than gmFLOCK that is close to unlocking. For example, conceptually, `100 gmFLOCK` with `1 year` remaining until unlock can have the same effective weight as `200 gmFLOCK` with `6 months` remaining until unlock, assuming a linear duration-weighting model. The key design principle is: gmFLOCK should reward long-term ecosystem alignment, but it should not allow pure capital size to overpower real model usage. gmFLOCK can also be used across both FOMO and AI Arena, creating an incentive bridge between the demand side of the ecosystem and the model training / supply side. #### Worked Examples One MT, daily Global FLOCK pool = 100 FLOCK, linear usage, square-root staking for the global pool, and nobody holds gmFLOCK. Reserved FLOCK and MT Reward are separate model-specific incentive pools. They use linear stake share instead of the square-root global staking factor. * **Alice** stakes the MT and is the **only staker** (stake\_share = 1.0). Accounts for 50% of API spending. * **Bob** doesn't stake, accounts for the other 50% of spending. With early-stage `α = 0.9`, staking helps, but only a little: | | usage\_share | global\_staking\_factor | global\_score | | ----- | ------------ | ----------------------- | ------------------- | | Alice | 0.5 | `0.9 + 0.1·√1` = 1.000 | 1.000 × 0.5 = 0.500 | | Bob | 0.5 | `α` = 0.900 | 0.900 × 0.5 = 0.450 | Alice earns 0.500 / (0.500 + 0.450) ≈ 52.6 FLOCK. Bob earns 47.4 FLOCK. This is because Alice’s global staking factor is `1.0`, while Bob’s non-staker floor is `0.9`. However, the Reserved FLOCK and MT Reward pools work differently. These model-specific incentive pools are staker-gated. Since Alice is the only staker and Bob has no stake, Alice receives 100% of the Reserved FLOCK and MT Reward distributed for this MT, while Bob receives 0 from those pools. Now suppose Alice is no longer the only staker and holds only 10% of the MT’s total stake. Her global staking factor would be: `0.9 + 0.1 × √0.1 ≈ 0.932` With equal usage, Alice would earn roughly `50.9 FLOCK` from the Global FLOCK pool, while Bob would earn `49.1 FLOCK`. That is intentional: early global rewards are not meant to heavily favor people who were already staked. For the Reserved FLOCK and MT Reward pools, Alice’s incentive staking factor would be `0.1`, while Bob’s would still be `0`. If Alice is the only participant with both positive stake and API usage on this MT, she receives 100% of the distributed model-specific incentives. If another staker also generates usage, the model-specific incentive split follows the incentive score based on usage share, stake share, and gmFLOCK multiplier. With mature-stage `α = 0.5`, staking has a much stronger effect on the Global FLOCK pool: | | usage\_share | global\_staking\_factor | global\_score | | ----- | ------------ | ----------------------- | ------------------- | | Alice | 0.5 | `0.5 + 0.5·√1` = 1.000 | 1.000 × 0.5 = 0.500 | | Bob | 0.5 | `α` = 0.500 | 0.500 × 0.5 = 0.250 | Alice earns `0.500 / (0.500 + 0.250)` ≈ 66.7 FLOCK. Bob earns 33.3 FLOCK. If Alice held only 10% of the MT’s total stake, her global staking factor would be: `0.5 + 0.5 × √0.1 ≈ 0.658`. With equal usage, Alice would earn roughly `56.8 FLOCK` from the Global FLOCK pool, while Bob would earn `43.2 FLOCK`. The lift from staking is smaller when Alice has only 10% of the stake, but much more visible than it was at `α = 0.9`. For Reserved FLOCK and MT Reward, the same rule still applies: Bob receives nothing without staking. Alice can only earn from these model-specific pools because she has a positive stake share. Now suppose Bob has enough effective gmFLOCK for his multiplier to become 2×. For the Global FLOCK pool, Bob’s score doubles, shifting the global split further in his favour. At `α = 0.9`, Bob’s global score becomes `0.450 × 2 = 0.900`, while Alice’s remains `0.500`. Bob would earn roughly `64.3 FLOCK`, while Alice would earn `35.7 FLOCK`. At `α = 0.5`, Bob’s global score becomes `0.250 × 2 = 0.500`, matching Alice’s `0.500`. Alice and Bob would each earn `50 FLOCK` from the Global FLOCK pool. But gmFLOCK does not bypass the staking requirement for Reserved FLOCK or MT Reward. Since Bob’s incentive staking factor is still `0`, his incentive score remains: `0 × 2 = 0`. So Bob can use gmFLOCK to boost his Global FLOCK share, but he still earns no Reserved FLOCK or MT Reward unless he stakes the corresponding MT. **Reserved FLOCK / MT Reward Example** | User | usage\_share | stake\_share | incentive\_staking\_factor | incentive\_score | | ----- | -----------: | -----------: | -------------------------: | ---------------: | | Alice | 0.5 | 1.0 | 1.0 | 0.500 | | Bob | 0.5 | 0.0 | 0.0 | 0.000 | Alice receives 100% of the Reserved FLOCK and MT Reward distributed for this MT. Bob receives 0 because he has no stake, even though he contributes 50% of API usage. #### Common Reasons People Earn Less Than Expected No usage on an MT = no reward share from that MT. Staking and gmFLOCK can boost an existing score, but usage is still the base demand signal. No stake on an MT = no Reserved FLOCK or MT Reward from that MT. Heavy API usage can still earn Global FLOCK, but model-specific incentive pools are staker-gated. Holding gmFLOCK does not bypass staking. gmFLOCK can multiply an existing score, but it cannot turn a zero incentive score into a positive one. Using the wrong model ID may not count toward the intended MT. From Season 2 onward, usage attribution is expected to map more explicitly through model ID. gmFLOCK close to unlocking may have lower effective weight. The gmFLOCK multiplier is based on effective gmFLOCK balance, which reflects both the amount held and the remaining lock duration. For example, a smaller gmFLOCK position with a longer remaining lock duration can have similar effective weight to a larger gmFLOCK position that is closer to unlocking. # Real Model Asset (RMA) Issuers
RMA Issuers are the participants who launch model-backed token economies through FOMO. In earlier drafts, this role is also referred to as the **Model Token Owner (MTO)**. They act like franchise operators for AI inference: they select a model, configure its deployment, launch its $MT, and help drive adoption. #### What RMA Issuers Do An RMA Issuer initiates a Real Model Offering by configuring: | Parameter | Description | | ----------------------- | ----------------------------------------------------------------------- | | Model architecture | The model to be deployed, such as Qwen, Llama, or a domain-specific SLM | | Hosting tier | The compute setup and cost structure | | Minimum inference price | The economic floor for serving the model | | Fundraise bounds | Minimum and maximum raise targets | | Launch parameters | Token sale, bonding curve, and initial liquidity setup | After configuration, the issuer launches the $MT fundraising process. If successful, the model becomes available through the FLock API Platform. #### Why RMA Issuers Launch on FOMO RMA Issuers launch on FOMO because it gives them a way to monetize model distribution directly. Instead of only charging API fees, an issuer can benefit from multiple economic channels: | Incentive | Description | | ------------------ | --------------------------------------------------------------- | | Creator fee | A portion of internal market trading fees during launch | | $MT allocation | A vested allocation of the model’s token | | Net revenue yield | A share of net inference revenue | | Emission bonus | A share of model-level $FLOCK emissions | | Token appreciation | Upside from increased model usage and $MT buyback/burn pressure | This makes the RMA Issuer more than a passive model uploader. They become the economic operator of a model franchise. #### RMA Issuer Incentive Alignment RMA Issuers are rewarded when their model is actually used. A successful issuer should therefore focus on: * Selecting models with real demand. * Setting competitive inference pricing. * Driving API usage through distribution and partnerships. * Supporting the $MT community. * Maintaining long-term model quality and reliability. The issuer’s upside depends on model traction, not just launch speculation. This is what makes FOMO closer to a real model asset market than a generic token launchpad. # Model Users
Model Users are developers, AI companies, agents, applications, and enterprises that consume inference through the FLock API Platform. They are the demand engine of FOMO. In traditional API markets, users pay for inference and receive no upside. The more they use, the more they pay. FOMO changes this by allowing users to become economically aligned with the models they rely on. #### How Rewards Are Calculated * A daily reward is paid out to participants based on their activity on supported **Model Tokens** (MTs). * You **don't have to stake to earn** — using the API alone makes you eligible — but stakers earn more than non-stakers at equal usage. * If you participate in multiple MTs, your daily reward is the sum across all of them. FLOCK rewards go to a single FLOCK balance you can claim; MT-token rewards stay in each MT's own token. #### Benefits for Model Users Model Users can benefit from FOMO in three ways. First, they can access **lower inference costs** through $MT staking discounts. By staking the $MT associated with a model, users can unlock reduced API pricing. Second, they may earn **retroactive rewards** based on their actual API usage. Since reward share is usage-weighted, users who generate meaningful demand can receive $FLOCK and $MT incentives. Third, their usage contributes to **$MT buyback and burn**, meaning heavy users help strengthen the model economy they depend on. #### Usage as the Core Reward Signal FOMO is designed to reward actual consumption. A user who spends more on a specific model contributes more to that model’s economic activity. This increases the model’s reward score and the user’s share within that model’s reward pool. The core logic is: ``` more real usage → higher model activity → more emissions to the model → larger reward opportunity for active users ``` This avoids the problem of rewarding idle capital. Staking alone is not enough. If there is no usage, there should be no meaningful reward. In rough order of impact: 1. **Spend more on API in a meaningful way** Migrate your OpenClaw or Hermes Agent to the API platform and generate more natural API spending. 2. **Stake the MT you use.** Any positive stake strictly beats not staking at equal usage. The lift starts modest while `α` is high, then grows as `α` steps down toward `0.5`. 3. **Hold gmFLOCK.** Multiplies your score on *every* MT by up to `1 + λ`. The biggest "set and forget" lever, and it stacks regardless of staking. 4. **Spread across multiple MTs you actually use.** Each MT is its own pool; activity on MT *A* never dilutes your share on MT *B*. You don't control the denominator — other people staking or spending on the same MT will shrink your share. Your job is to pick MTs where your relative position is strong. #### Common Reasons People Earn Less Than Expected * **No usage on an MT = no reward on that MT** — even if you stake heavily. Staking alone earns nothing; you have to also use the MT. * **Reward pools follow API usage, not stakers.** An MT with stakers but zero API activity that day pays out nothing. The daily FLOCK emission flows toward MTs that are actually being used. * **Per-MT incentive pools are time-limited.** They drip out over \~180 days from the MT's launch and then stop. Earlier participation captures more of that pool. * **Your reward "didn't go up" is impossible** — the protocol only ever increases your claimable total. If your dashboard shows the same number, it just means you didn't earn anything new in the last run, not that something was lost. #### Season 1 vs Season 2 Usage Mapping In **Season 1**, API usage can be automatically mapped to supported model tokens. This lowers user friction during the transition period and helps bootstrap early behavior. In **Season 2 and forward**, users will need to use the correct **model ID** for usage to count toward a specific $MT. This improves precision and prevents ambiguity between different model deployments. This distinction matters because FOMO is model-specific. A user’s activity should strengthen the $MT linked to the model they actually use. # $MT Supporters
$MT Supporters are participants who buy, hold, stake, or otherwise support a model token. They may be model users, investors, community members, distributors, or ecosystem participants who believe a specific model deployment will gain usage. #### Why $MT Supporters Matter $MT Supporters help bootstrap the model economy. They provide initial demand during the launch phase, help form liquidity, and may stake tokens to strengthen the model’s incentive base. Unlike purely speculative assets, $MT is designed to be tied to model usage. As the model generates revenue, a portion of net revenue is used to buy back and burn the relevant $MT. This creates direct linkage between inference demand and model-token scarcity. #### Ways $MT Supporters Earn $MT Supporters can earn through several channels: | Channel | Description | | ------------------------- | ------------------------------------------------------------- | | $FLOCK global emission | Distributed to active $MT economies | | Per-$MT $FLOCK incentive | Dedicated $FLOCK incentive for a specific model token | | Per-$MT token incentive | Rewards paid in the model’s own token | | Staking advantage | Higher reward score than non-stakers at equal usage | | Buyback and burn exposure | Potential appreciation from model revenue reducing $MT supply | #### Staking and Usage The system is designed so that $MT staking improves reward share, but staking alone should not dominate. A participant’s score depends on: ``` usage share × staking factor × gmFLOCK multiplier ``` This means the strongest participants are not merely the largest holders, but those who combine: ``` real API usage + aligned $MT staking + ecosystem-level gmFLOCK commitment ``` #### Whale Resistance Both the staking factor and gmFLOCK multiplier are designed with non-linear effects. The staking factor can use a square-root structure, meaning the benefit of staking increases with stake share but at a decreasing rate. gmFLOCK also uses a diminishing-return structure, where larger holdings move users closer to the upper multiplier range but do not scale infinitely. This keeps the reward system competitive. A whale can improve their position, but they still need real usage. Meanwhile, smaller users can remain competitive if they generate meaningful API demand in a specific $MT economy. # The FLock Platform The FLock Platform is the infrastructure and coordination layer behind FOMO. It provides: * Model deployment infrastructure. * API usage accounting. * Launchpad mechanics. * Revenue routing. * Buyback and burn execution. * Reward distribution. * Integration with AI Arena and the broader FLock ecosystem. In the FOMO whitepaper, the platform is described as the layer responsible for model deployment, revenue accounting, buyback logic, emission distribution, and transparent execution of tokenomic flows. #### Platform Revenue The FLock Platform captures value through several channels: | Source | Description | | ----------------------- | ----------------------------------------------------------- | | Launch fee | A one-time $FLOCK fee paid by RMA Issuers | | Protocol trading fee | A portion of internal market trades during the launch phase | | Treasury share | A portion of net inference revenue | | Platform $MT allocation | Treasury allocation from each $MT supply | | $FLOCK buyback and burn | Protocol-level value capture from inference revenue | This aligns the platform with actual model usage. FLock benefits when FOMO models generate demand, revenue, and sustainable token economies. #### Platform Role in Emissions The platform distributes daily rewards across supported $MTs according to competition-based activity. Each $MT distributes three types of rewards: 1. Global $FLOCK emission. 2. Per-$MT $FLOCK incentive. 3. Per-$MT token incentive. During the transition phase, emissions come from the emission gap period. Over time, the system can evolve toward a more mature emission schedule where model usage, staking alignment, and gmFLOCK commitment determine reward share more precisely. #### FOMO and AI Arena FOMO is the demand-side counterpart to AI Arena. AI Arena incentivizes model creation, training, and improvement. FOMO incentivizes model deployment, distribution, and usage. Together: {% code overflow="wrap" %} ``` AI Arena produces intelligence. FOMO distributes intelligence. API usage validates demand. Revenue and emissions route value back into the ecosystem. ``` {% endcode %} This closes the loop between model supply and model demand. gmFLOCK can be shared across both FOMO and AI Arena, reinforcing ecosystem-wide alignment. A participant who supports the broader FLock economy can receive benefits across multiple parts of the protocol rather than being siloed into a single model market. #### Why This Matters for FLock FOMO strengthens FLock in four ways. First, it gives the ecosystem a demand-side engine. Instead of only incentivizing model production, FLock can now incentivize actual usage. Second, it turns the API Platform into an economic layer. API usage is no longer just revenue; it becomes the signal that determines emissions, buybacks, and model-token value. Third, it creates a new route for model commercialization. Model developers, distributors, and AI companies can launch real model assets rather than relying only on centralized API pricing. Fourth, it makes $FLOCK more deeply embedded in the ecosystem. $FLOCK is used for launches, emissions, incentives, and buybacks, while FOMO activity creates ongoing demand and deflationary pressure for the macro token. # FL Alliance FL Alliance can serve as a natural continuation of [AI Arena](/flock-products/ai-arena), our decentralized AI training platform. After AI Arena has optimised the model parameters, they are further refined in FL Alliance with proprietary data. Additionally, FL Alliance can function independently as a collaborative training platform, allowing participants to define their own tasks. Following our research paper published at IEEE Transactions on Artificial Intelligence (see ), we provide a robust incentive mechanism incentivise honest behaviours and penalise malicious behaviours of FL participants. Read on to understand the tokenomics of FL Alliance. # Task Creator ## Definition FL task creator will be responsible to create a FL task. The creator will specify the basic information of a FL task, such as the number of minimum participants, the expected number of rounds, and the initial reward amount in the pool, etc. ## Requirements Similar to the AI Arena task creator, a FL task creator needs to satisfy the following requirements: * stake a sufficient amount of FLOCK * had successfully created, trained or validated an AI Arena task before * is whitelisted ## Expected Returns Thanks to the FL training, in which the participants will provide their local data to perform the training, the FL task creator will receive a further fine-tuned model compared to their AI Arena trained version. \*This feature is not released yet. # FL Nodes ## Definition FL nodes are participants in a decentralised learning system where multiple entities collaboratively train a shared machine learning model without exchanging their local data. These nodes can be any devices or servers contributing computational resources and data to the training process. ## Description FL nodes play critical roles in ensuring the integrity and efficiency of the FL Alliance working process. They are randomly allocated the roles of proposers and voters with the goal of avoiding collusion and other malicious behaviours. By distributing these roles randomly, the system ensures a fair and unbiased approach to model training and evaluation. Specifically, developers join as FL nodes to collaboratively train a global model while using their local data and computing power. They are randomly allocated the following roles: * **Proposers:** Responsible for performing local training using their own data and proposing updates to the global model. * **Voters:** Responsible for aggregating local model updates, evaluating the global model, and casting votes to either support or oppose the proposed updates. ## Slash and Reward Mechanism * **Reward:** Participants are incentivised through rewards for honest participation and accurate contributions to the model training and evaluation process. Rewards are given to those whose votes align with the majority decision and to proposers when the majority supports their updates. * **Slash:** Participants face penalties in the form of slashing their staked tokens if their votes do not align with the majority decision. This mechanism discourages malicious behavior and ensures that participants act in the best interest of the model's integrity. ## Motivation The motivation behind this FL Alliance system is to create a decentralised and secure environment for federated learning. By using random functions to allocate roles and a staking mechanism to ensure commitment, the system promotes trust and reliability among participants. The slash and reward mechanism further incentivises honest behaviour, ensuring the collaborative effort results in a high-quality global model. ## Example The steps to calculate reward for a participant are as followed: 1. Calculate the number of rounds left: $$ \begin{align\*} \text{roundsLeft} &= \text{totalNumberOfRounds} - (\text{currentRound} - 1) \end{align\*} $$ 2. Calculate the reward amount for the current round: $$ \begin{align\*} \text{roundRewardAmount} &= \frac{\text{rewardPool}}{\text{roundsLeft}} \end{align\*} $$ 3. Calculate the proportion of stakes for the participant: $$ \begin{align\*} \text{proportion} &= \frac{\text{roundStakedTokens}\[\_round]\[\text{participant}]}{\text{roundTotalStakesForGoodParticipants}} \end{align\*} $$ 4. Calculate the reward amount for the participant: $$ \begin{align\*} \text{rewardAmount} &= {\text{roundRewardAmount} \times \text{proportion}} \end{align\*} $$ Let’s say we have `4` participants participating in the FL Alliance. In each round, `2` of them are randomly assigned to the role of proposer, the other `2` are assigned as voters. Participant A and B both staked `50` FLOCK respectively, whereas participants C and D staked `100` FLOCK respectively. Let’s assume further that there are `4` rounds of training in total. Assuming all are honest participants (meaning no one will get slashed), their respective rewards are:
ParticipantsInitial StakeRewards in Round 1Rewards in Round 2Rewards in Round 3Rewards in Round 4
Participant A5091.66666667133.3333333175216.6666667
Participant B5091.66666667133.3333333175216.6666667
Participant C100183.3333333266.6666667350433.3333333
Participant D100183.3333333266.6666667350433.3333333
Total Stake Amount of All Good Participants Per Round30055080010501300
Reward Pool (remaining)10007505002500
Reward Amount Per RoundN/A250250250250
# Token Allocations The total supply of `FLOCK` is capped at 1 billion tokens. Only the day-one unlock tokens are minted initially, with additional tokens minted daily through our management smart contract. The distribution is as follows:

FLock Token Model

### Community The Community allocation is designed to incentivise contributors across all FLock products, including AI Arena, FL Alliance, AI Marketplace, and future initiatives. All eligible testnet participants will receive mainnet token airdrops as recognition for their contributions during the FLock testnet phase. Future incentives will be systematically minted over a 60-month period with a 1% monthly decay to safeguard the community’s long-term interests and ensure alignment with FLock’s vision. *AI Arena Task Manager CA:* [*0x5813dEe58523EA082Ee80162527EfEed7799AaA0*](https://basescan.org/address/0x5813dEe58523EA082Ee80162527EfEed7799AaA0) *Task Manager automatically manages daily token emissions for trainers, validators, and delegators in AI Arena* ### Ecosystem The Ecosystem allocation is designed to ensure the sustainability and innovation of FLock’s cutting-edge technology through grants, rewards and service fees that drive long-term growth. This support encompasses R\&D, task creation, protocol development and maintenance, node operator management, and FLock ecosystem initiatives. *CA:* [*0xB2EAfdb76D8a6beDB6062144Fa7a320b68940912*](https://basescan.org/address/0xB2EAfdb76D8a6beDB6062144Fa7a320b68940912) ### Investors Early supporters will have a 3-year vesting schedule (1-year cliff followed by 2 years of linear vesting). **Tokens that are locked cannot be staked until they are vested.** *Investor Token Custodian Wallet Address:* [*0x3B1Ee5Ade5b2102EA2af83d70C273A732a044311*](https://basescan.org/address/0x3B1Ee5Ade5b2102EA2af83d70C273A732a044311) ### Team & Advisors Core contributors to FLock technology, including both current and future team members, will follow a vesting schedule of a 1-year cliff and 2 years of linear vesting. **Locked tokens cannot be staked until vested.** *Team & Advisors Custodian Wallet Address:* [*0x3B1Ee5Ade5b2102EA2af83d70C273A732a044311*](https://basescan.org/address/0x3B1Ee5Ade5b2102EA2af83d70C273A732a044311) ### Summary The allocation of `FLock` tokens follows a 1:2 ratio model between team\&investors and the community (33.3% : 66.7%), prioritising community and ecosystem growth. The majority of tokens are allocated to incentivise community participation and ecosystem expansion, ensuring the success of FLock’s multi-year initiative and vision. This approach secures robust governance and encourages the broader AI and blockchain communities to actively contribute and develop the technology. Meanwhile, the pioneers of FLock technology are also incentivised to continue their contributions, fostering long-term success for FLock and its ecosystem. # Airdrop FLock airdrop allocates 50,000,000`FLOCK` (5% of total supply) to trainers, validators, delegators, model users, and community partners. Subject to terms and conditions stated [here](/resources/flock-token-airdrop-terms-and-conditions). ## Eligibility ### 1. For participants in the Model Store (models.flock.io) **Eligibility Criteria**: * **Option 1**: Users with a score of **300 or above**, who have verified at least one social account, and hold assets on either the Ethereum or Base mainnet. * **Option 2**: Users who have participated in specific events and received direct rewards through manual evaluation. Eligible users will take part in a verifiable lucky draw to determine the amount of airdrop they will receive. Users will be categorised into four tiers, each corresponding to a specific `FLOCK` reward range. ### 2. For participants in the AI Arena (train.flock.io) **Eligibility Criteria**: * Users must have earned at least **1 FML** (our testnet token). **Sybil Resistance Measures**: * The primary method of Sybil resistance relies on **submitted IP addresses**. * For an address to be considered as potentially Sybil-related: 1. It has submitted from the same IP used by other addresses **on the same day** 2. **And** situation 1 has happened **three or more time** **FAQ** I rented instance from cloud platform, and the same instance might be rented by others, will I be considered Sybil? **Answer**: No, you will only be considered as Sybil if there is another address rented exactly the same instance you rented **on the same day**, and such coincidence happend **three or more times**. Addresses identified as Sybils will have their rewards **proportionally reduced**, depending on the size of the associated cluster. **Airdrop Calculation**: * The number of tokens airdropped is based on the **earned FML** amount. * Tokens directly claimed (such as via Faucet) or received as transfers **do not count** toward the calculation (with the exception of tokens distributed through specific campaigns and special task emission). # Contract Details | Category | | | ---------------- | ------------------------------------------------------------------------------------------------------------------- | | Ticker | FLOCK | | Total Supply | 1,000,000,000 FLOCK | | Network | Base | | Contract Address | [0x5aB3D4c385B400F3aBB49e80DE2fAF6a88A7B691](https://basescan.org/token/0x5ab3d4c385b400f3abb49e80de2faf6a88a7b691) | ### Base-Solana Bridge The FLock Foundation has initiated $FLOCK from Base to Solana using Base’s official decentralised Base-Solana bridge.
Mint details * Official Mint Address: FmysnoAQ7ifx3La6C7D9cM5tcpoTxEnakbnZPhrC2pJi * Token Program Type: Token-2022 (Token Extensions) * Decimals: 9 * Mint Authority (expected): FmysnoAQ7ifx3La6C7D9cM5tcpoTxEnakbnZPhrC2pJi
{% hint style="warning" %} Any token with a different mint address is NOT official {% endhint %} The FLock Foundation and team do not provide any official bridge program to the public. Please refer to [Base's official doc](https://docs.base.org/base-chain/quickstart/base-solana-bridge) for any bridge-related actions. By using any third-party bridging services, you acknowledge that [FLock](https://flock.io) is not responsible for any losses, malfunctions, or systemic failures resulting from any third-party infrastructures. # AI-assisted Coding - FLock x Aptos LLM (outperforms ChatGPT-4o!) **FLock’s Aptos LLM outperforms ChatGPT-4o in generating Move-specific code**, setting new standards in decentralized programming tools and allowing developers to produce secure, high-quality Move code with unprecedented efficiency. By partnering with the Aptos Foundation, FLock has created a specialized Large Language Model (LLM) that leverages community-contributed Move code to enhance AI-assisted coding on the Aptos blockchain. This decentralized approach not only addresses the unique requirements of Move—such as resource-oriented asset handling—but also excels in tasks ranging from simple scripts to more complex applications like yield tokenization with AMM functionality. FLock’s model consistently demonstrates higher accuracy and alignment with Aptos-specific criteria compared to generalized LLMs. Looking ahead, FLock plans to expand its dataset with expert annotations and establish rigorous benchmarks to further refine the LLM’s capabilities. A production-ready model will be deployed on FLock.’s federated learning platform, supporting ongoing, decentralized improvements as it adapts to real-time needs and incorporates proprietary Move codebases. By integrating FLock.’s advanced LLM with the Aptos network, the collaboration enhances Move developer productivity, highlights the value of community-driven AI training, and showcases how decentralized AI can transform specialized coding tasks in the blockchain ecosystem. Read more about the partnership [here](https://www.flock.io/blog/flockio-integrates-with-aptos-to-turbocharge-ai-assisted-move-language-coding-copilot) or explore more FLock models [here](https://train.flock.io/explore). # AI Assistants - Farcaster GPT, Scroll GPT and many more to come! FLock is at the forefront of decentralized training platforms, enabling the development and deployment of AI assistants in a collaborative environment. By leveraging community contributions and innovative training techniques, FLock exemplifies how decentralized platforms can revolutionize AI development. Two notable AI assistants, Farcaster GPT and Scroll GPT, serve as real-life use cases of FLock's capabilities. ## Farcaster GPT: Harnessing Community Collaboration Farcaster GPT is an AI assistant developed through the innovative [AI Arena](/flock-products/ai-arena). This project marked a significant milestone as it was part of the first-ever hackathon for AI Arena, hosted during the Base Onchain Summer Buildathon. The development process exemplified community-driven collaboration, where participants were tasked with training a chatbot using [Farcaster documentation](https://docs.farcaster.xyz/). The winning model, developed by Yifan Xie, is available on Hugging Face: [Mistralai-Mistral-7B-Instruct-v0.3](https://huggingface.co/yifanxie/mistralai-Mistral-7B-Instruct-v0.3-1719254473). This model showcases the potential of community collaboration in achieving significant advancements in AI development. The success of Farcaster GPT highlights how FLock facilitates the creation of powerful AI models through decentralized and collaborative efforts. ## Scroll GPT: A Community-Driven RAG-based Model Scroll GPT is another exemplary AI assistant, co-created by the community, and is hosted on the FLock platform. This model is based on Retrieval-Augmented Generation (RAG), which enhances the chat experience by integrating external knowledge sources. The collaborative nature of Scroll GPT's development illustrates how FLock enables community members to contribute their expertise and knowledge. Hosted at [FLock](https://beta.flock.io/model/cls4fv9ev0019jy82egcigw4a), Scroll GPT offers a live chat interface where users can contribute their knowledge and earn points. This interactive platform fosters continuous improvement of the AI model, driven by real-time contributions from the community. FLock's collaboration with other community projects and protocols, such as Scroll, exemplifies its ability to integrate with broader ecosystems. Through partnerships and campaigns, FLock empowers participants to earn additional points, incentivising active engagement and knowledge sharing. This collaborative model demonstrates how decentralised platforms like FLock can facilitate innovation and community growth, setting a new standard for AI development. # AI Companions - Professor Grump w/ Akash Run FLock node on Akash network *NOTE: This post was originally published on the* [*Akash Blog*](https://akash.network/blog/decentralized-ai-model-training-on-akash-with-flockio/)*.* ## Introduction Developing truly open and decentralised AI is one of society’s most critical challenges. The networks, platforms, and clients we build will help guide this development, from open compute networks like [Akash](https://akash.network/docs/) to platforms like FLock that make it easy to train and fine-tune AI models. Integrating these projects simplifies the user experience, enabling greater access that puts AI development directly in the hands of people around the world. This case study outlines the integration between Akash and FLock that enables users to easily train AI models on decentralised compute. It illustrates how Akash, the first open-source Supercloud, gives AI developers access to the high-performance compute resources needed to train AI models with FLock.io, a platform for decentralised machine learning. ## Birds of a Feather: Akash & FLock As the adage goes, “birds of a feather flock together.” As the decentralized AI movement takes flight, Akash and FLock.io are flying in unison. Akash is an open network that lets users buy and sell computing resources securely and efficiently. FLock.io is an open network that lets users train, validate, and govern AI models democratically and transparently. Akash is purpose-built for public utility. Compute is available to anyone on the network through Akash’s peer-to-peer marketplace, and the network does not limit the types of tasks or workloads that can be deployed. Similarly, FLock.io is built for and by the community, and the platform does not restrict where models are trained, validated, hosted, and/or deployed. With a clear alignment on visions for the future and shared values of openness, permissionlessness, and composability, it’s clear to see why Akash and FLock.io are closely aligned. As you'll see below, FLock has integrated with Akash to create 1-click templates that make it easy to run FLock.io nodes on the Akash Supercloud. ## Running a Flock Validator on Akash Network Video Tutorial: {% embed url="" %} ### Stake Flock token and generate an API key Follow the steps 1 and 2 mentioned in our [validator guide](https://docs.flock.io/flock-product/decentralised-ai-training/validator-guide) to stake Flock token for a validation task and generate an API. ### Create an Akash account You will need a Keplr or Leap wallet to create an Akash account. Go to
Click “CONNECT WALLET” to connect a Keplr or Leap wallet.
When connected to your Keplr wallet, Akash console would show the USDC and AKT balance in your wallet. Deployment on Akash will consume your USDC or AKT. ### Get AKT token You can buy some AKT from any CEX or DEX below, then you need to transfer your AKT to your Keplr or Leap wallet.
### Deployment Choose Flock validator template from templates page (Docker image link: ) Click deploy
Input your Flock API and task ID you have staked FLock token on.
Then change the storage to a minimum of 50Gi in builder page, click create deployment.
You can also use the YML file to create deployment. Add your Flock API Key and the Task ID {% file src="/files/f0XQq0vZJ51iEO4LxDQf" %} Choose a provider who is audited, click accept bid.
Then the Flock validator will run automatically in 10 min.
*** ## Create Deployment (Optional) This section is if you wish to run your custom deployment Click the “DEPLOY” in the upper left corner, and select “Rent GPUs” to rent a GPU
The GPU on the Akash platform is provided to users through docker containers. So you need to provide the image information of the docker container to be deployed, and the hardware configuration of the container. Choose the GPU count, vCPU count, RAM size.
You can use flockvalidator/pytorch:2.0.1-py3.10-cuda11.8.0-devel-ubuntu22.04 as your docker image, use 8vCPU, 24GB Memory and 60G storage.
After the container configuration is selected, you will enter the provider selection page. You can see all providers that meet the configuration requirements, and their prices and availability are marked. Select one and proceed.
After deployment, you can enter the "SHELL" tab and use the sh command to configure the environment and run the validator. For advanced users, you can configure sshd service and login via third-party tools such as mobaxterm, xshell.
# Web3 Agents - Text2SQL Agent Web 3 Agent's Text2SQL model represents a significant leap forward in simplifying database queries by allowing users to interact with databases using natural language commands. Developed on FLock's AI Arena platform, this model showcases how decentralised training platforms can transform complex tasks into accessible solutions for a wide range of users, from business analysts to developers. ## Simplifying Database Queries with Text2SQL The Text2SQL model is designed to enable users to query databases effortlessly using simple, natural language commands, eliminating the need for complex SQL syntax. This innovation bridges the gap between users and their data, making data retrieval both intuitive and efficient. By allowing users to articulate their queries in everyday language, the Text2SQL model democratises access to data, empowering individuals without extensive technical expertise to extract valuable insights from complex datasets. Whether you are a business analyst seeking insights, a data scientist analysing trends, or a developer integrating data-driven functionalities, the Text2SQL model enhances productivity by simplifying the data retrieval process. This model exemplifies how AI can streamline workflows and improve accessibility, enabling more people to harness the power of data. ## Training and Validation with Community Collaboration The development of the Text2SQL model was conducted through FLock's AI Arena platform, which emphasises collaborative and community-driven AI development. The training data for this task was based on open-sourced Text2SQL datasets, providing a foundation for the model's capabilities. However, these datasets often contained inaccuracies, posing challenges for effective model training. To address this, the task creator undertook extensive cleaning and manual review to ensure the accuracy and reliability of the final validation set. This rigorous approach highlights the importance of data quality in AI development and underscores FLock's commitment to fostering robust and reliable AI models. By leveraging the collective expertise of the community, FLock ensures that models like Text2SQL are both powerful and practical. ## FLock's Role in Advancing AI Innovation The development of the Text2SQL model on FLock's AI Arena platform demonstrates the platform's role in advancing AI innovation. By providing a decentralised environment for training and development, FLock enables diverse communities to collaborate and contribute to cutting-edge AI projects. This approach not only accelerates the pace of innovation but also ensures that AI solutions are relevant and adaptable to real-world challenges. Through initiatives like Text2SQL, FLock continues to push the boundaries of what is possible in AI development, empowering users across various domains to interact with data in more meaningful ways. The success of the Text2SQL model illustrates FLock's potential to drive transformative change in how people access and utilise information, paving the way for a future where data is truly democratised. # Privacy-preserving Healthcare Beyond our work in the Web3 ecosystem, FLock is equally relevant in the Web2 world, and our flagship collaboration with a leading British hospital affiliated with a Top UK university is an excellent testimony to this. One of the biggest challenges of building AI models in the healthcare sector is data sharing. Since healthcare data is private, sensitive, and heterogeneous, collecting sufficient data for modelling is exhausted, costly, and sometimes impossible. \ FLock’s groundbreaking approach in leveraging blockchain-enabled FL has proven to be effective in preserving data privacy while significantly improving prediction accuracy compared to traditional methods. This approach facilitates global collaboration, allowing healthcare institutions to contribute to model training without sharing sensitive healthcare data directly. Our work has been tested in blood glucose prediction as a pilot but can be readily extended to model other chronic diseases or address broader healthcare challenges. # Litepaper You can view our Litepaper [here](https://ucwlvzgpqvoxldczjggo.supabase.co/storage/v1/object/public/flock-blog/FLock_Litepaper_27122024.pdf). # Whitepaper Read our Whitepaper! * FLock's whitepaper is available [here](https://www.flock.io/whitepaper). * FOMO's whitepaper is available [here](https://ucwlvzgpqvoxldczjggo.supabase.co/storage/v1/object/public/flock-blog/fomo_whitepaper.pdf). # Publications Find out more about our publications at: [Google Scholar](https://scholar.google.com/citations?hl=en\&user=s0eOtD8AAAAJ). * N. Dong, J. Sun, Z. Wang, S. Zhang, S. Zheng, "FLock: Defending Malicious Behaviors in Federated Learning with Blockchain" in NeurIPS 2022 Workshops on Decentralization and Trustworthy Machine Learning in Web3: Methodologies, Platforms, and Applications. Best Paper Runner-up Award. Available at: * N. Dong, Z. Wang, J. Sun, M. Kampffmeyer, W. Knottenbelt and E. Xing, "Defending Against Poisoning Attacks in Federated Learning with Blockchain," in IEEE Transactions on Artificial Intelligence, * Z. Wang, N. Dong, J. Sun, W. Knottenbelt and Y. Guo, "zkFL: Zero-Knowledge Proof-based Gradient Aggregation for Federated Learning," in IEEE Transactions on Big Data, \ ***More papers to come*** # Glossary | Keyword | Reasoning | | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Model Fintuning | Model fine-tuning adapts a pre-trained machine learning model for a related task. Instead of training from scratch, this method uses a model that has already learned useful features from another task and fine-tunes it on a new dataset or task. | | Model Inference | The model has already been trained and evaluated, and has been deployed into the actual target hardware. Data is input into the model, and the model predicts the results. | | Large Language Model/LLM | A type of artificial intelligence model aimed at understanding and generating human language. Trained on a large amount of text data, it can perform a wide range of tasks, including text summarization, translation, sentiment analysis, and so on. | | Federated learning | A new paradigm in machine learning aims to train centralized models while keeping a large amount of client-side training data from being uploaded to avoid data leaks. | | Deep Gradient Compression/DGC | Reduce the network bandwidth required for exchanging gradient information | | Gradient inversion attack | A specialized form of adversarial attack aimed at systems utilizing Federated Learning. In this type of attack, adversaries attempt to 'invert' the aggregated gradient updates sent to the centralized server. By doing so, they seek to reconstruct or infer sensitive information from the original data that contributed to these gradient updates. This poses a significant risk to data exploit and security within Federated Learning ecosystems. | | Byzantine attack |

  1. Data Poisoning Attack: This attack involves contaminating the local dataset on the client side by adding polluted images. The polluted data causes the client to upload a model with poor accuracy, which in turn affects the global model.
  2. Model Poisoning Attack: This type of attack involves altering the model during its training or transmission process, without changing the local data on the client side.
  3. Tampering with Controlled Client's Local Data: This attack involves changing the local data on a controlled client device to influence the model's training process.
| | RAG |

Retrieval-Augmented Generation (RAG) is a method that improves the responses of large language models (like GPT-3) by letting them check an external, trustworthy knowledge base before they answer. This means they can give more accurate and up-to-date answers, especially in specialized areas or using a company's own data, without having to be retrained.

This makes these models even better at jobs like answering questions, translating languages, and completing sentences, and it's a budget-friendly way to make sure they stay useful and correct in many different situations.

| # FAQ This is the FAQ page to help you going through the journey with FLock.
Why do I need to use my private key? The design of FLock leverages federated learning, essentially representing a distributed learning framework. In more understandable terms, this means each user operates their own node for running the training process. We utilise blockchain technology as an integral part of our system, using it as an incentivisation layer. The private key in this context holds significant importance. It is required by the user to initialize the client, mainly because it ensures security and user authenticity. This key validates the user's transactions, and by extension, their contributions to the learning process, thus maintaining the integrity and the decentralised nature of our system.
Will I have any private key exploitation issues? The FLock system is designed to prioritize user security; all the training operations are carried out locally on your device, ensuring your private keys are never exposed to us or anyone else. We do not have access to your private keys nor are they stored on any central server, thus maintaining the decentralized and secure nature of our system. However, it's important for you to know that the safekeeping of your private keys is under your control, so you must ensure to keep them secure and confidential to prevent any potential issues.
# Social Media Follow FLock on Social Media! Follow us on [Twitter](https://twitter.com/flock_io) on @flock\_io Follow our [Linkedin](https://www.linkedin.com/company/flock-io/) Join our [Discord](https://discord.gg/fz5EqH7rhn) Join our [Telegram](https://t.me/flock_io_community) Subscribe to our [Youtube](https://www.youtube.com/@flock-io) {% embed url="" %} Like and Subscribe for more videos {% endembed %} ## FLock: Defending Malicious Behaviours in Federated Learning with Blockchain {% embed url="" %} ## FLock ETHDenver workshop 2023 {% embed url="" %} FLock at ETHDenver 2023 {% endembed %} ## FLock.io Pitch @ SXSW 2023 {% embed url="" %} FLock pitch at SXCW 2023 {% endembed %} # Careers Welcome to join the FLock! Please check out our job vacancies here: {% embed url="" %} # Terms Of Use EFFECTIVE DATE: December 30, 2024 PLEASE READ THESE TERMS OF USE BEFORE USING THE WEBSITES. Acceptance of the Terms of Use These terms of use are entered into by and between you and FLock Technology Holdings (“FLock,” “Company,” “we,” “our” and/or “us”). The following terms and conditions, together with any documents they expressly incorporate by reference (collectively, these “Terms of Use”), govern your access to and use of any website published by FLock, including, but not limited to, any content, functionality, and services offered on or through flock.io, docs.flock.io, flock-io.medium.com, beta.flock.io, train.flock.io and other websites affiliated to FLock. (the “Websites”). Please read the Terms of Use carefully before you start to use the Websites. By using the Websites or by clicking to accept or agree to the Terms of Use when this option is made available to you, you accept and agree to be bound and abide by these Terms of Use in addition to our [Privacy Policy](/resources/privacy-policy), incorporated herein by reference (the “Privacy Policy”). If you do not agree to these Terms of Use, you must not access or use the Websites. Who May Use the Websites The Websites are only available to users in certain jurisdictions who can use the Websites as permitted under Applicable Law (as defined below). Without limitation, you must be at least 18 years of age to use the Websites. You may not attempt to access or use the Websites if you are not permitted to do so. OUR WEBSITES IS NOT OFFERED TO PERSONS OR ENTITIES WHO RESIDE IN, ARE LOCATED IN, ARE INCORPORATED IN, OR HAVE A REGISTERED OFFICE IN ANY RESTRICTED TERRITORY, AS DEFINED BELOW (ANY SUCH PERSON OR ENTITY FROM A RESTRICTED TERRITORY, A “RESTRICTED PERSON”). WE DO NOT MAKE EXCEPTIONS; THEREFORE, IF YOU ARE A RESTRICTED PERSON, THEN DO NOT ATTEMPT TO USE THE WEBSITES. USE OF A VIRTUAL PRIVATE NETWORK (“VPN”) TO CIRCUMVENT THE RESTRICTIONS SET FORTH HEREIN IS PROHIBITED. (i) In order to protect the integrity of the Websites, we reserve the right, at any time, in our sole discretion, to block access to the Websites from certain IP addresses and unique device identifiers. (ii) We reserve the right to report any activity occurring using the Websites to relevant tax authorities as required under Applicable Law. You are solely responsible for maintaining all relevant Tax records and complying with any reporting requirements you may have as related to our Websites. You are further solely responsible for independently maintaining the accuracy of any record submitted to any tax authority including any information derived from the Websites. (iii) In addition to the other suspension and termination rights in these terms, we may suspend or terminate your access to the Websites at any time in connection with any transaction as required by Applicable Law, any governmental authority, or if we in our sole and reasonable discretion determine you are violating the terms of any third-party service provider or these terms, including, without limitation, if we reasonably believe any of your representations and warranties may be untrue or inaccurate or you are violating or have violated any of the geographical restrictions that apply to the Websites, and we will not be liable to you for any losses or damages you may suffer as a result of or in connection with the Websites being inaccessible to you at any time or for any reason. Such suspension or termination shall not be constituted a breach of these Terms of Use by FLock. In accordance with its anti-money laundering, anti-terrorism, anti-fraud, and other compliance policies and practices, we may impose limitations and controls on the ability of you or any beneficiary to utilize the Websites. Such limitations may include rejecting transaction requests, freezing funds, or otherwise restricting you from using the Websites, all to the extent of our ability to do so. Use of the Websites As a condition to accessing or using the Websites, you represent and warrant to the FLock the following: (i) if you are entering into these Terms of Use as an individual, then you are of legal age in the jurisdiction in which you reside and you have the legal capacity to enter into these Terms and be bound by them and if you are entering into these Terms of Use as an entity, then you must have the legal authority to accept these Terms of Use on that entity’s behalf, in which case “you” (except as used in this paragraph) will mean that entity; (ii) you are not a resident, national, or agent of Algeria, Bangladesh, Bolivia, Belarus, Burundi, Burma (Myanmar), Cote D’Ivoire (Ivory Coast), Crimea and Sevastopol, Cuba, Democratic Republic of Congo, Ecuador, Iran, Iraq, Liberia, Libya, Mali, Morocco, Nepal, North Korea, Somalia, Sudan, Syria, Venezuela, Yemen, Zimbabwe or any other country to which the United States embargoes goods or imposes similar sanctions (collectively, “Restricted Territories”); (iii) you are not on any sanctions list or equivalent maintained by the United States government (collectively, “Sanctions Lists Persons”) and you do not intend to transact with any Restricted Person or Sanctions List Person; (iv) you do not, and will not, use VPN software or any other privacy or anonymization tools or techniques to circumvent, or attempt to circumvent, any restrictions that apply to the Websites; (v) you represent and warrant to us that you have obtained all required consents from any individual whose personal information you transfer to us in connection with your use of the Websites; and (vi) your access to the Websites is not: (a) prohibited by and does not otherwise violate or assist you to violate any domestic or foreign law, rule, statute, regulation, by-law, order, protocol, code, decree, or another directive, requirement, or guideline, published or in force that applies to or is otherwise intended to govern or regulate any person, property, transaction, activity, event or other matter, including any rule, order, judgment, directive or other requirement or guideline issued by any domestic or foreign federal, provincial or state, municipal, local or other governmental, regulatory, judicial or administrative authority having jurisdiction over FLock, you or the Websites, or as otherwise duly enacted, enforceable by law, the common law or equity (collectively, “Applicable Laws”); or (b) contribute to or facilitate any illegal activity. You acknowledge, understand, and agree to the following: (i) from time to time the Websites may be inaccessible or inoperable for any reason, including, without limitation: (a) equipment malfunctions; (b) periodic maintenance procedures or repairs that FLock or any of its suppliers or contractors may undertake from time to time; (c) causes beyond FLock’s control or that FLock could not reasonably foresee; (d) disruptions and temporary or permanent unavailability of underlying blockchain infrastructure; or (e) unavailability of third-party service providers or external partners for any reason; (ii) the Websites may evolve, which means FLock may apply changes, replace, or discontinue (temporarily or permanently) the Websites at any time in its sole discretion; (iii) FLock does not act as an agent for you or any other user of the Websites; (iv) you are solely responsible for your use of the Websites; and (v) we owe no fiduciary duties or liabilities to you or any other party, and that to the extent any such duties or liabilities may exist at law or in equity, you hereby irrevocably disclaim, waive, and eliminate those duties and liabilities. You covenant to FLock the following: (i) you will comply with all Applicable Laws in connection with using the Websites, and you will not use the Websites if the laws of your country, or any other Applicable Law, prohibit you from doing so; and (ii) in addition to complying with all restrictions, prohibitions, and other provisions of these Terms of Use, you will ensure that, at all times, all information that you provide during your use of the Websites is current, complete, and accurate and you will maintain the security and confidentiality of your private keys associated with your public wallet address, passwords, API keys, private keys associated with your Websites account and other related credentials. Each party shall be responsible for all Taxes imposed on its income or property. In addition, interactions with the protocol may also result in transaction fees or Gas Fees (as defined below) imposed by the protocol, which are also solely your responsibility. “Gas Fees” mean the fees that fund the network of computers that run the decentralized blockchain network, meaning that you will need to pay a Gas Fee for each transaction that occurs via the blockchain network. Changes to the Terms of Use We reserve the right, at our sole discretion, to change these Terms of Use at any time and the updated terms will be effective as of the time of posting, or such later date as may be specified in the updated terms. Your continued access or use of the Services after the modifications have become effective will be deemed your acceptance of the modified Terms. You are expected to check this page frequently so you are aware of any changes, as they are binding on you. Accessing the Websites and Account Security We reserve the right to withdraw or amend the Websites, and any service or material we provide on the Websites, in our sole discretion without notice. We do not guarantee that our Websites or any content on them will always be available or be interrupted. We will not be liable if for any reason all or any part of the Websites are unavailable at any time or for any period. From time to time, we may restrict access to some parts of the Websites, or entire Websites, to users. You are responsible for: l Making all arrangements necessary for you to have access to the Websites; and l Ensuring that all persons who access the Websites through your internet connection are aware of these Terms of Use and comply with them. To access the Websites or some of the resources it offers, you may be asked to provide certain registration details or other information. It is a condition of your use of the Websites that all the information you provide on the Websites is correct, current, and complete. You agree that all information you provide to use the Websites, including, but not limited to, using any interactive features on the Websites, is governed by our Privacy Policy, and you consent to all actions we may take with respect to your information that are consistent with our Privacy Policy. You should use particular caution when inputting personal information onto the Websites on a public or shared computer so that others are not able to view or record your personal information. Intellectual Property Rights The Websites and their entire contents, features, and functionality (including but not limited to all information, software, text, displays, images, video and audio, and the design, selection, and arrangement thereof), are owned by FLock, its licensors or other providers of such material and are protected by copyright, trademark, patent, trade secret, and other intellectual property or proprietary rights laws. Unless otherwise marked, (a) all material, data, and information on the Websites, such as data files, text, music, audio files or other sounds, photographs, videos, or other images, but excluding any software or computer code are licensed under the Creative Commons Attribution 4.0 International License; and (b) all software or computer code are licensed under the MIT License. Trademarks The Company name, the terms FLock, FLock GPT, Bitcoin GPT, Ethereum GPT, X1 GPT, Scroll GPT, BNB GPT, SecondLive GPT, the Company logo and all related names, logos, product and service names, designs and slogans are trademarks of FLock or its affiliates or licensors. You must not use such marks without the prior written permission of FLock. All other names, logos, product and service names, designs and slogans on this Websites are the trademarks of their respective owners. Prohibited Uses You may use the Websites only for lawful purposes and in accordance with these Terms of Use. You agree not to use the Websites: l In any way that violates any applicable federal, state, local, or international law or regulation (including, without limitation, any laws regarding the export of data or software to and from the US or other countries); l For the purpose of exploiting, harming, or attempting to exploit or harm minors in any way by exposing them to inappropriate content, asking for personally identifiable information or otherwise; l To send, knowingly receive, upload, download, use, or re-use any material which does not comply with these Terms of Use; l To transmit, or procure the sending of, any advertising or promotional material without our prior written consent, including any “junk mail”, “chain letter”, “spam”, or any other similar solicitation; l To impersonate or attempt to impersonate FLock, a FLock or a FLock’s affiliate employee, another user, or any other person or entity (including, without limitation, by using e-mail addresses or screen names associated with any of the foregoing); and l To engage in any other conduct that restricts or inhibits anyone's use or enjoyment of the Websites, or which, as determined by us, may harm FLock or users of the Websites or expose them to liability. Additionally, you agree not to: l Use the Websites in any manner that could disable, overburden, damage, or impair the Websites or interfere with any other party’s use of the Websites, including their ability to engage in real time activities through the Websites; l Use any robot, spider, or other automatic device, process or means to access the Websites for any purpose, including monitoring or copying any of the material on the Websites; l Use any manual process to monitor or copy any of the material on the Websites or for any other unauthorized purpose without our prior written consent; l Use any device, software or routine that interferes with the proper working of the Websites; l Introduce any viruses, trojan horses, worms, logic bombs, or other material which is malicious or technologically harmful; l Attempt to gain unauthorized access to, interfere with, damage, or disrupt any parts of the Websites, the server(s) on which the Websites is stored, or any server, computer or database connected to the Websites; l Attack the Websites via a denial-of-service attack or a distributed denial-of-service attack; and l Otherwise attempt to interfere with the proper working of the Websites. Reliance on Information Posted The information presented on or through the Websites is made available solely for general information purposes. We do not warrant the accuracy, completeness or usefulness of this information. Any reliance you place on such information is strictly at your own risk. We disclaim all liability and responsibility arising from any reliance placed on such materials by you or any other visitor to the Websites, or by anyone who may be informed of any of its contents. The Websites may include content provided by third parties, including materials provided by other users, bloggers and third-party licensors, syndicators, aggregators, and/or reporting services. All statements and/or opinions expressed in these materials, and all articles and responses to questions and other content, other than the content provided by FLock, are solely the opinions and the responsibility of the person or entity providing those materials. These materials do not necessarily reflect the opinion of FLock. We are not responsible, or liable to you or any third party, for the content or accuracy of any materials provided by any third parties. Changes to the Websites We may update the content on the Websites from time to time, but its content is not necessarily complete or up-to-date. Any of the material on the Websites may be out of date at any given time, and we are under no obligation to update such material. Information About You and Your Visits to the Websites All information we collect on the Websites is subject to our Privacy Policy. By using the Websites, you consent to all actions that may be taken by us with respect to your information in compliance with the [Privacy Policy](/resources/privacy-policy). Online Purchases and Other Terms and Conditions Additional terms and conditions may also apply to specific portions, services or features of the Websites. All such additional terms and conditions are hereby incorporated by this reference into these Terms of Use. In the event of terms that are directly conflicting between these Terms of Use and additional terms and conditions, the additional terms and conditions shall control. Linking to the Websites and Social Media Features You may link to our homepage, provided you do so in a way that is fair and legal and does not damage our reputation or take advantage of it, but you must not establish a link in such a way as to suggest any form of association, approval or endorsement on our part without our express written consent. Links from the Websites If the Websites contain links to other sites and resources provided by third parties, these links are provided for your convenience only. We have no control over the contents of those sites or resources, and accept no responsibility for them or for any loss or damage that may arise from your use of them. If you decide to access any of the third-party websites linked to the Websites, you do so entirely at your own risk and subject to the terms and conditions of use for such websites. We reserve the right to withdraw linking permission without notice. Geographic Restrictions The owner of the Websites is based in Cayman Islands. We make no claims that the Websites or any of its content is accessible or appropriate outside of Cayman Islands. Access to the Websites may not be legal by certain persons or in certain countries. If you access the Websites from outside Cayman Islands, you do so on your own initiative and are responsible for compliance with local laws. Disclaimer of Warranties You understand that we cannot and do not guarantee or warrant that files available for downloading from the internet or the Websites will be free of viruses or other destructive code. You are responsible for implementing sufficient procedures and checkpoints to satisfy your particular requirements for anti-virus protection and accuracy of data input and output, and for maintaining a means external to our site for any reconstruction of any lost data. WE WILL NOT BE LIABLE FOR ANY LOSS OR DAMAGE CAUSED BY A DISTRIBUTED DENIAL-OF-SERVICE ATTACK, VIRUSES, OR OTHER TECHNOLOGICALLY HARMFUL MATERIAL THAT MAY INFECT YOUR CRYPTO ASSETS, COMPUTER EQUIPMENT, COMPUTER PROGRAMS, DATA, OR OTHER PROPRIETARY MATERIAL DUE TO YOUR USE OF THE WEBSITES OR ANY SERVICES OR ITEMS OBTAINED THROUGH THE WEBSITES OR TO YOUR DOWNLOADING OF ANY MATERIAL POSTED ON IT, OR ON ANY WEBSITES LINKED TO IT. YOUR USE OF THE WEBSITES, THEIR CONTENT AND ANY SERVICES OR ITEMS OBTAINED THROUGH THE WEBSITES IS AT YOUR OWN RISK. THE WEBSITES, THEIR CONTENT AND ANY SERVICES OR ITEMS OBTAINED THROUGH THE WEBSITES ARE PROVIDED ON AN "AS IS" AND "AS AVAILABLE" BASIS, WITHOUT ANY WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED. NEITHER THE COMPANY NOR ANY PERSON ASSOCIATED WITH THE COMPANY MAKES ANY WARRANTY OR REPRESENTATION WITH RESPECT TO THE COMPLETENESS, SECURITY, RELIABILITY, QUALITY, ACCURACY, OR AVAILABILITY OF THE WEBSITES. WITHOUT LIMITING THE FOREGOING, NEITHER THE COMPANY NOR ANYONE ASSOCIATED WITH THE COMPANY REPRESENTS OR WARRANTS THAT THE WEBSITES, THEIR CONTENT OR ANY SERVICES OR ITEMS OBTAINED THROUGH THE WEBSITES WILL BE ACCURATE, RELIABLE, ERROR-FREE OR UNINTERRUPTED, THAT DEFECTS WILL BE CORRECTED, THAT THE WEBSITES OR THE SERVER(S) THAT MAKES THEM AVAILABLE ARE FREE OF VIRUSES OR OTHER HARMFUL COMPONENTS OR THAT THE WEBSITES OR ANY SERVICES OR ITEMS OBTAINED THROUGH THE WEBSITES WILL OTHERWISE MEET YOUR NEEDS OR EXPECTATIONS. THE COMPANY HEREBY DISCLAIMS ALL WARRANTIES OF ANY KIND, WHETHER EXPRESS OR IMPLIED, STATUTORY, OR OTHERWISE, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT, AND FITNESS FOR PARTICULAR PURPOSE. SOME JURISDICTIONS DO NOT ALLOW EXCLUSION OF WARRANTIES OR LIMITATIONS ON THE DURATION OF IMPLIED WARRANTIES, SO THE ABOVE DISCLAIMER MAY NOT APPLY TO YOU IN THEIR ENTIRETIES, BUT WILL APPLY TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW. Limitation on Liability IN NO EVENT WILL THE COMPANY, ITS AFFILIATES OR THEIR LICENSORS, SERVICE PROVIDERS, EMPLOYEES, AGENTS, OFFICERS, OR DIRECTORS BE LIABLE FOR DAMAGES OF ANY KIND, UNDER ANY LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH YOUR USE, OR INABILITY TO USE, THE WEBSITES, ANY WEBSITES LINKED TO THEM, ANY CONTENT ON THE WEBSITES OR SUCH OTHER WEBSITES OR ANY SERVICES OR ITEMS OBTAINED THROUGH THE WEBSITES OR SUCH OTHER WEBSITES, INCLUDING ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, CONSEQUENTIAL OR PUNITIVE DAMAGES, INCLUDING BUT NOT LIMITED TO, PERSONAL INJURY, PAIN AND SUFFERING, EMOTIONAL DISTRESS, LOSS OF REVENUE, LOSS OF PROFITS, LOSS OF BUSINESS OR ANTICIPATED SAVINGS, LOSS OF USE, LOSS OF GOODWILL, LOSS OF DATA, AND WHETHER CAUSED BY TORT (INCLUDING NEGLIGENCE), BREACH OF CONTRACT OR OTHERWISE, EVEN IF FORESEEABLE. THE FOREGOING DOES NOT AFFECT ANY LIABILITY WHICH CANNOT BE EXCLUDED OR LIMITED UNDER APPLICABLE LAW WHICH MAY INCLUDE FRAUD. Indemnification You agree to defend, indemnify, and hold harmless the Company, its affiliates, licensors, and service providers, and its and their respective officers, directors, employees, contractors, agents, licensors, suppliers, successors, and assigns from and against any claims, liabilities, damages, judgments, awards, losses, costs, expenses, or fees (including reasonable attorneys’ fees) arising out of or relating to your violation of these Terms of Use or your use of the Websites, including, but not limited to, any use of the Websites’ content, services and products other than as expressly authorized in these Terms of Use or your use of any information obtained from the Websites. Governing Law and Jurisdiction All matters relating to the Websites and these Terms of Use and any dispute or claim arising therefrom or related thereto (in each case, including non-contractual disputes or claims), shall be governed by and construed in accordance with the laws of Cayman Islands without giving effect to any choice or conflict of law provision or rule (whether of Cayman Islands or any other jurisdiction). Any legal suit, action or proceeding arising out of, or related to, these Terms of Use or the Websites shall be instituted exclusively in Hong Kong although we retain the right to bring any suit, action or proceeding against you for breach of these Terms of Use in your country of residence or any other relevant country. You waive any and all objections to the exercise of jurisdiction over you by such courts and to venue in such courts. Waiver and Severability No waiver by the Company of any term or condition set forth in these Terms of Use shall be deemed a further or continuing waiver of such term or condition or a waiver of any other term or condition, and any failure of the Company to assert a right or provision under these Terms of Use shall not constitute a waiver of such right or provision. If any provision of these Terms of Use is held by a court or other tribunal of competent jurisdiction to be invalid, illegal, or unenforceable for any reason, such provision shall be eliminated or limited to the minimum extent such that the remaining provisions of the Terms of Use will continue in full force and effect. Entire Agreement The Terms of Use, our Privacy Policy and other terms of conditions of ours constitute the sole and entire agreement between you and the Company with respect to the Websites and supersede all prior and contemporaneous understandings, agreements, representations and warranties, both written and oral, with respect to the Websites. Your Comments and Concerns The Websites are operated by FLock. All other feedback, comments, requests for technical support and other communications relating to the Websites should be directed to: ** --- [Next Page](/llms-full.txt/1)