otf.json

[
    {
        "subnet": "gamma-3",
        "SN Name and SN Number": "MyShell TTS, SN 3",
        "Subnet Owner Discord Username": "ethan_myshell and 0x0tc",
        "Subnet Objectives and Contributions:": "The primary purpose of the MyShell TTS Subnet is to develop advanced, open-source Text-to-Speech (TTS) models by leveraging decentralized collaboration and Bittensor's incentive mechanism. By harnessing MyShell's user base of over one million individuals, we are committed to pushing the cutting-edge technology developed on Bittensor to every end-user, thereby uniting the entire community.",
        "Communication Protocols:": "If you are familiar with Subnets 6 and 9, our communication protocols are similar to theirs. There is no direct peer-to-peer communication between miners and validators. Instead, miners train their models and then push the model to HuggingFace, followed by submitting the model record to the Bittensor blockchain. Validators regularly monitor the models submitted by miners and evaluate them. As a result, there are no security issues related to communication.",
        "Incentives Mechanism:": "Miners are rewarded for providing high-quality TTS models. Since speech is challenging to evaluate, we have designed a set of metrics that capture the naturalness, intelligibility, expressiveness, and consistency of the speech using our own rater model. The weights of each miner are calculated based on their evaluation performance. Please refer to our GitHub repository for a better understanding of our evaluation protocols. Currently, validators are using a large set of evaluation examples for assessment, and we plan to switch to online data generation with ChatGPT to further diversify the data source.\n\nLink to GitHub: https://github.com/myshell-ai/MyShell-TTS-Subnet?tab=readme-ov-file#evaluation-protocol",
        "Data Sources and Security:": "Currently, validators are using a large set of evaluation examples from the VCTK dataset. As participants become accustomed to the entire mechanism, we will gradually enable more data sources, including a more diverse set of speakers and content generated by Large Language Models (LLMs). At present, no lookup-type attacks have been observed, but we are committed to enhancing the security of the network. Please refer to our GitHub repository for our roadmap.",
        "Compute Requirements:": "For miners, a 30 series GPU is sufficient, although a more powerful GPU can accelerate the training process. For validators, we currently perform CPU inference as our MeloTTS model is highly efficient and capable of real-time inference even on a CPU. We recommend a CPU server with at least 8 cores for optimal performance. Miners are rewarded for training better TTS models based on MyShell's open-source MeloTTS model. We plan to release a leaderboard showcasing the best models and the generated voices. Additionally, we will integrate the best model into MyShell's platform to allow the model to benefit our user base of over a million individuals. Our roadmap is available on our GitHub.",
        "Notebook and Code:": "The holistic overview will be made available in our leaderboard. For querying the top miner uid, we can simply use the Bittensor API with metagraph.emission.",
        "Applications and Collaborations:": "Our best model will be added to the TTS model family of our platform. You can see existing TTS model options in the workshop page of our App: https://app.myshell.ai/robot-workshop",
        "Development Roadmap:": "As building a TTS model is a complex task, we will divide the development into several phases.\n\nPhase 1: Initial release of the subnet, including miner and validator functionality. This phase aim to build a comprehensive pipeline for TTS model training and evaluation. We will begin with a fixed speaker.\nPhase 2: Increase the coverage of speaker and conversation pool. We will recurrently update the speaker and language to cover more scenarios.\nPhase 3: More generally, we can have fast-clone models that can be adapted to new speakers with a small amount of data, e.g., OpenVoice. We will move to fast-clone models in this phase.\n\nIn addition, we will add the leaderboard as mentioned before.",
        "Testnet Information:": "As we are built on top of the battle-tested subnets, we didn’t participate on testnet but directly enter the mainnet.",
        "Demo Recording:": "Here is a demo of what the resulting TTS models can do: https://twitter.com/myshell_ai/status/1765403905695875453",
        "Relevant Links:": "Here are some related links:\n- Our vision about this subnet: https://twitter.com/myshell_ai/status/1772792027148894557\n- The state-of-the-art open-source model we are built on: https://github.com/myshell-ai/MeloTTS",
        "Please ensure that all responses are concise and provide the necessary information to understand the operational parameters of the subnet": null,
        "Email Address": ""
    },
    {
        "subnet": "gimel-27",
        "SN Name and SN Number": "Compute, SN27",
        "Subnet Owner Discord Username": "aizorr0",
        "Subnet Objectives and Contributions:": "SN27's primary purpose is to decentralize and democratize access to computational resources, enhancing Bittensor's ecosystem by providing a permissionless marketplace for compute. It enables users to contribute or consume computational power, such as GPUs, for various tasks, including but not limited to AI model training and data processing, thereby fostering innovation and lowering entry barriers to high-performance computing. This subnet contributes to the Bittensor network's resilience and scalability by distributing compute resources.",
        "Communication Protocols:": "- Which communication protocols are utilized by this subnet? - Prometheus, Axon, ssh, btcli API. \n   \n- What type of data is transmitted, how frequently does this occur, and what is the typical data size? -  \na. Miner machine hardware specs once every 30 minutes per vali, \nb. hashcat challenges random time between 10 and 16 minutes, using dynamic difficulty to adjust scoring based on hardware challenges - timeout 30 sec. \nc. Allocation to the machine through an ssh tunnel inside a docker container.\n   \n- Is there any security or encryption applied to the messages? If not, are there plans to implement such measures? Describe the methods used to secure communications. - Blake2 algo for challenges randomly generated per valis with different salt everytime. Symmetric encryption for specs challenges. RSA encryption for allocation.",
        "Incentives Mechanism:": "- Please detail the reward mechanism for this subnet and include links to the relevant GitHub repositories. - Validators score miners based on their performance in completing PoW challenges.The higher the difficulty of the PoW challenge and the faster it is solved, the higher the validator's rating for the miner, whereby the difficulty of the challenge is dynamically adjusted. Ongoing improvement when a machine is computing (allocated).\n\n   - How are servers within your subnet ranked? Is there a reward-based ranking system for subnets? - Validators score miners based on their performance in completing PoW challenges. \n\n   - What type of data do validators use for queries? Is there a risk of data exhaustion? If not, provide examples of how data is generated or created to ensure unique validations. - Hashcat challenge results. System specs. Allocation per validator.\n   - GitHub Link to Reward Mechanism\nhttps://github.com/neuralinternet/compute-subnet/blob/main/neurons/Validator/calculate_pow_score.py",
        "Data Sources and Security:": "- What is the origin of the data used by validators? Indicate if any data augmentation processes are in place. - Miners send responses to the validators queries. \n\n- Are there any known vulnerabilities within your subnet, such as susceptibility to lookup attacks due to limited dataset size? If so, what measures are planned to safeguard the subnet? - Spoofing of machine specs, PoW is the solution. There was a vulnerability where the hardware specifications were spoofed; this issue has been resolved by implementing a PoW based scoring mechanism. *This issue was fixed within six days of it being discovered (https://medium.com/@neuralinternet/netuid-27-post-mortem-4ed708041bc6).\n   \n- GitHub link to Data Sources: We have a private wandb database setup, and are currently working on making it publicly available; we would appreciate further guidance on this point.",
        "Compute Requirements:": " - What are the computational prerequisites for participating in your subnet? - Machine with GPU and Ubuntu 22.04 and python3.8 or higher and docker properly configured. To stay registered it is recommended to use machines with the following GPU or better; NVIDIA H100, NVIDIA A100s, NVIDIA A6000s, NVIDIA 3090s/4090s. Incentives breed competition so miners will have to stay competitive by adding more compute depending on overall network state.\n   \n- How can miners increase their rewards? Are they required to train specific models or run predetermined models? - They can increase their compute resources.\n   \n- Is there any public interface or user interaction with the subnet? If not currently available, are there plans to develop one? - We are currently about a month into development of a fully fledged front end which includes a rental interface, miner and validator dashboards, etc. \n   \n- Are there any significant updates scheduled for the subnet? Please provide details if available. - Yes, changes to the codebase like scoring mech and allocation mech.\nPresently, a hashcat approach is employed for PoW, set to be upgraded to a PoW centered on AI/ML tasks, utilizing MLPerf Benchmarks. Furthermore, the scoring mechanism is adapted to also be functional for miners in the allocated state. The allocation of resources by the validator is streamlined and integrated into the cli. Efforts are also currently being made to enable the use of containerized docker instances for resource provisioning. \n",
        "Notebook and Code:": "1) Query the top miner uid (We will be using the foundation hotkey to do this)\n\nAll the details about miners results are located in the `database.db`, populated through the database module below:\n\nhttps://github.com/neuralinternet/compute-subnet/tree/main/neurons/Validator/database\n\nThe details about the miners specifications of the miners machine are in `miner_details` table.\n\nhttps://github.com/neuralinternet/compute-subnet/blob/main/neurons/Validator/database/allocate.py\n\nHere is a sample to prettify the db details:\n\n```python3\nimport sqlite3\n\n\ndef display_miners() -> dict:\n    conn = sqlite3.connect(\"database.db\")\n    cursor = conn.cursor()\n    cursor.execute(\"SELECT * FROM miner_details\")\n    results = cursor.fetchall()\n    miner_details = {}\n    for id, hotkey, details in results:\n        print(f\"{id:<10}, {hotkey:<60}, {details}\")\n    cursor.close()\n    return miner_details\n\n\nif __name__ == \"__main__\":\n    display_miners()\n```\n\nAdapt it at your convenience or use directly the SQLite CLI.\n\nHere's how to allocate to the top miner:\n\n`gpu_type` and `gpu_size` are taken from the `miner_details` table.\n\n```sh\npm2 start neurons/register.py \\\n    --name NAME \\\n    --interpreter /usr/bin/python3 \\\n    -- \\\n    --netuid 27 \\\n    --wallet.name <wallet_name> \\\n    --wallet.hotkey <hotkey> \\\n    --axon.port <axon_port> \\\n    --gpu_type <gpu_type> \\\n    --gpu_size <gpu_size> \\\n    --logging.debug \\\n    --subtensor.network finney\n```\n\nA better interface is being released on Monday and will be available from the CLI; from there, the OTF validator can query the specs of the miners and check the UID they want to query.\n\n\n2) Demonstrate each reward/penalty mechanism/Scoring of the top miner response \n\nScores are calculated in this document: https://github.com/neuralinternet/compute-subnet/blob/main/neurons/Validator/calculate_pow_score.py\n\nThe mock script used by our developer will be pushed in a few days to the repo. I'll provide you the link once they have pushed it.\n\nIn the meantime, here is a summary: the highest difficulty solved with the best responsiveness a miner can solve PoW while not being allocated the better score they will have. This is not yet implemented but it is in development: when allocated, the miner will not receive challenges anymore and receive highest historical avg score + a bonus while being allocated.\n\n\n3) Queries the API and/or links to a frontend(if applicable)\n\nFront end development is a couple of weeks away, here are the links to our Figma designs and Miro board for the Front end development: https://www.figma.com/file/N8DJwJ4FCGnMyjoPxvgIbT/Subnet-frontend?type=design&node-id=0%3A1&mode=design&t=pvWcS4OHOhx2DPXO-1\n\nhttps://miro.com/app/board/uXjVNO-FQx0=/ \n\nCurrent register/allocation command (example): pm2 start neurons/register.py --name NAME --interpreter /usr/bin/python3 -- --netuid 27 --wallet.name <wallet_name> --wallet.hotkey <hotkey> --axon.port <axon_port> --gpu_type 'NVIDIA RTX A4000' --gpu_size 16376 --logging.debug --subtensor.network finney\n\nA cli is also under development to facilitate the usage of the `register.py` command.\n",
        "Applications and Collaborations:": "- Have any applications been developed on top of your subnet? While not mandatory, this information is beneficial. - Not yet; we expect this to change with the release of the Frontend.\n   \n- Is there any ongoing collaboration with other subnets? This is also not a requirement but is valuable information. - Yes, we are actively pursuing partnerships with as many subnets as possible as well as partnerships outside of the Bittensor ecosystem. \n\nAkash Network ($AKT) has publicly announced the partnership with subnet 27 and integration of its compute within the subnet. Arweave ($AR) has also suggested a partnership with SN27.",
        "Development Roadmap:": "10-week plan:\nFront-end development with a UI interface and complete new benchmarking techniques for the compute resources. \nCross-chain interoperability with Akash Network.\nEnsure subnet is operating at a nominal level (observing the performance of the reward mechanism, POW registration over time)",
        "Testnet Information:": " - Did your subnet participate on testnet? Describe the scope and participation of your subnet on the testnet. - Yes. The compute subnet is on subnet 15 of the testnet, which is utilized for developing new functionalities and for validating new versions before they are rolled out.",
        "Demo Recording:": "https://www.loom.com/share/9b569f414c8f49df8d8800a6963ffefc?sid=e1217f8b-1c0c-46dd-a223-92e2c4b947c4",
        "Relevant Links:": "https://www.loom.com/share/735dc2f451e4416bb65da9a4679de00f\n\nhttps://www.youtube.com/watch?v=5UJlKwAhYdE\n\nhttps://www.figma.com/file/N8DJwJ4FCGnMyjoPxvgIbT/Subnet-frontend?type=design&node-id=0%3A1&mode=design&t=pvWcS4OHOhx2DPXO-1\n\nhttps://miro.com/app/board/uXjVNO-FQx0=/\n",
        "Please ensure that all responses are concise and provide the necessary information to understand the operational parameters of the subnet": null,
        "Email Address": ""
    },
    {
        "subnet": "pi-16",
        "SN Name and SN Number": "Audio Subnet - SN 16 (Mainnet)",
        "Subnet Owner Discord Username": "uncletedd",
        "Subnet Objectives and Contributions:": "1.1 What is the primary purpose of this subnet, and how does it enhance the Bittensor network as a whole?\n\nThe main goal of the SN 16 - Audio Generation subnetwork is to establish a decentralized platform that incentivizes the creation, distribution and also monetization of AI audio content, such as Text-to-Speech (TTS), Voice Cloning (VC), Text-to-Music (TTM) and Speech-to-Speech in the following weeks.\n\nThis subnet leverages open-sourced models within a secure framework, enabling validators & developers to build web and mobile applications that interact with the subnetwork and its miners, thus democratizing audio content creation. Validators and miners work together to ensure high-quality outputs, fostering innovation and rewarding contributions in the audio domain.\n\nBy introducing audio generation services such as Text-to-Speech, Voice Cloning, and Text-to-Music, this subnetwork expands the range of available services within the Bittensor ecosystem. This diversification enhances the utility and appeal of the Bittensor platform to a broader audience, including creators, influencers, developers, and end-users interested in audio content.\n\nThe SN 16 - Audio Generation subnetwork distinguishes itself from big tech centralized counterparts, such as OpenAI and Google, by offering a unified, decentralized platform that unifies all key audio generation services: Text-to-Speech, Voice Cloning, and Text-to-Music. This ensures users have access to all audio services in one place.",
        "Communication Protocols:": "2.1 Which communication protocols are utilized by this subnet?\n\nBittensor’s Synapse Protocol: This is essential for the subnet's functioning, as it specifies the data format and communication protocols necessary for various neural network functions, including text-to-speech conversion, music generation, and voice cloning. The Synapse Protocol standardizes data transfers by utilizing the Pydantic library, which is crucial in data validation during the transactions between miners and validators. This makes it easier for different AI models in the network to communicate securely with one another.\n\nDendrite-Axon Interface: With dendrites functioning as input receptors for incoming requests and axons acting as output channels for sending responses, this component provides the foundation for the communication architecture of the network. Effective data transmission and coordination between network users are ensured by this bidirectional communication method.\n\n2.2 What type of data is transmitted, how frequently does this occur, and what is the typical data size?\n\nText-to-Speech Service:\nIn this service, data is transmitted in the form of textual prompts to the miners, who then process this data and respond with voice files. These voice files are generally 2 to 5 MB in size, varying based on the length of the prompts provided.\n\nVoice Cloning Service:\nThis service involves sending a prompt along with a reference voice to be cloned on the miner side. The response consists of one cloned voice file, approximately 2-5 MB in size, dependent on the prompt's length.\n\nText-to-Music Service:\nIn the Text-to-Music service, data is sent in the form of a music description to the miners, who respond with audio files, either in WAV or MP3 format. The size of each file typically ranges from 2 to 5 MB, dependent on the length of the music description provided and the music length asked (e.g. 15 seconds, 30 seconds, 45 seconds).\n\nPrompt Submission Frequency:\nFor each service mentioned above, validators send out approximately 15 prompts or descriptions every 5 to 8 minutes. This regular submission schedule ensures a steady flow of tasks for miners and a consistent output of processed audio files.\n\n2.3 Is there any security or encryption applied to the messages? If not, are there plans to implement such measures? Describe the methods used to secure communications.\n\nThe encryption mechanism is currently under development, as outlined in the plan below: To develop a secure, decentralized system for audio processing services, including Text-to-Speech (TTS), Voice Cloning (VC), and Text-to-Music (TTM), this system will leverage blockchain technology to ensure data integrity, confidentiality, and transparency.\n\nSystem Architecture Overview:\n- The system consists of validators and miners within a blockchain framework. \n- Validators submit audio processing requests, and miners process these requests using specialized AI models. \n- Cryptographic measures are incorporated for enhanced security and data integrity.\n\nCryptographic Security Design:\n- Implement Public Key Infrastructure (PKI) for validators and miners to ensure secure communication. \n- Utilize digital signatures to authenticate and maintain the integrity of requests and responses. \n- Encrypt sensitive data in transit using symmetric encryption techniques to protect it.\n\nService Protocols Development:\n- Define protocol classes for each service (Speech, Voice Cloning, Music generation), specifying their structure and encryption requirements.\n- Ensure that protocols include fields for encrypted data and metadata necessary for processing and validation.\n\nValidators and Miners Interaction Workflow:\n- Validators initiate requests filled with the required data and encrypt them with a symmetric key. \n- Requests are signed with the validator’s private key to certify authenticity. \n- Miners decrypt the requests, verify the signatures to ensure authenticity, process the requests, and then send back the results, encrypted and signed for security.\n\n2.4 GitHub Link Relevant to Communication Protocols\n\nhttps://github.com/opentensor/bittensor/blob/0759f6a584a05e0d1dcbbf2baf54ae80b36e26cb/bittensor/synapse HYPERLINK",
        "Incentives Mechanism:": "3.1 Please detail the reward mechanism for this subnet and include links to the relevant GitHub repositories.\n\nA. Text-to-Speech (TTS) scoring metric:\n\nTTS scoring metric is based on weighted average of two metrics:\n\n- NISQA: Speech Quality and Naturalness Assessment\n*Research paper: https://arxiv.org/abs/2104.09494\n*GitHub: https://github.com/gabrielmittag/NISQA?tab=readme-ov-file\n\n- Word Error Rate scoring metric\n*Research Paper: wav2vec 2.0: A Framework for Self- Supervised Learning of Speech Representations by Alexei Baevski, Henry Zhou, Abdelrahman Mohamed, and MichaelAuli. \n\nTTS Penalty Mechanism:\nTTS penalty mainly depends on the Word Error rate, After careful testing and observation the threshold for word error rate was set to 0.7, if WER is greater or equal to 0.7, that means a lot of information has been lost while speaking the text to speech model and miner is not performing good at this point. Then a zero TTS aggregate score is assigned to the miner for this TTS response\n\nB. Voice Cloning (VC) scoring metric:\n\nVoice cloning scoring Metric is further weighted average of TTS scoring metric and Mel spectrogram analysis of source and target voices.\n\nMel Spectrogram metric\n\n- Mel spectrogram analysis is a core technique in signal processing, particularly in speech and audio analysis, where it's applied to both source and target voices. Afterward, a quality score is calculated as the Cosine Similarity Distance.\n\n- Cosine similarity is a measure used to determine how similar two entities (documents, vectors, etc.) are irrespective of their size. In the context of audio, it can be used to measure how similar two sound spectrograms are by treating them as vectors in a multi-dimensional space.\n\nVC Penalty Mechanism:\nVoice cloning penalty has two parts:\n\n- TTS penalty\nThis part is already explained in TTS penalty section, if the score from the WER metric is ZERO , Voice clone score will be awarded a zero score\n\n- Cosine Similarity penalty of mel spectrogram of Source and target voice\nIf two voices differ then Cosine similarity will be negative or zero, here negative -0.1 score will be awarded to the miner for not sending true cloned voice\n\nC. Text to Music (TTM) scoring metric:\n\nCLAPTextConsistencyMetric:\nThe `CLAPTextConsistencyMetric` is a metric used for evaluating the similarity between audio and text, representations by CLAP (Contrastive Learning of Audio Representations for Playback) model. This metric is usually used to evaluate the degree to which text embeddings and the learned audio embeddings from the CLAP model match.\n\n- Purpose:\nThe purpose of the metric is to assess how well both written descriptions and sound representations match up. It assesses how effectively the content presented in the given text has been captured by the model's learned embeddings.\n\n- Usage:\nIt is used as a quantitative metric to evaluate the gained audio embeddings' quality. It offers information on how effectively the model aligns the two modalities by comparing the text and audio representations.\n\n- Input Parameters:\nThe metric accepts the following inputs: the lengths of the audio sequences, the sampling rate of the audio, the text that includes the descriptions, and the audio embeddings (audio).\n\n- Output:\nThe result is a consistency score that shows how well the text and audio match. A higher similarity score suggests perfection.\n\nInterpretation of Results:\n\n- Consistency Score:\nThe consistency score is a numerical value that represents how well the audio and text match. \n\n- Range of Scores:\nThe range of consistency scores is -1 to 1.\n\n- Good vs. Bad:\nThe alignment of the text and audio representations is usually better when the consistency score is higher. A number that is close to 1.0 denotes great consistency, whereas a lower value has no similarity.\n\nMathematical Expression\n\nThe mathematical expression for a consistency metric involves measuring the cosine similarity between the normalized embeddings:\n\nConsistency Score = A . T / ||A|| .  ||T||\n\nHere:\n\n- A⋅T represents the dot product of the audio and text embeddings.\n\n- ∥A∥ and ∥T∥ are the L2 norms (Euclidean norms) of the audio and text embeddings, respectively.\n\nThis formula yields a value between -1 and 1, where 1 indicates perfect consistency, -1 indicates perfect inconsistency, and 0 indicates no consistency.\n\nLinks:\nhttps://github.com/LAION-AI/CLAP\nhttps://github.com/facebookresearch/audiocraft.git\nhttps://facebookresearch.github.io/audiocraft/api_docs/audiocraft/metrics/clap_consistency.html\n\nTTM Penalty Mechanism:\nBased on the consistency score of the generated music by the miner. We have set a threshold of 0.2 consistency score. If score is equal or below 0.2, then 0 aggregate score is rewarded for TTM response.\n\n\n3.2 How are servers within your subnet incentivized? Is there a ranking system for incentives on your subnets?\n\nThe ranking mechanism has not been implemented yet. Our subnet will design it soon. It will be based on the performance of the miners according to the scoring metric and updated after a particular interval in terms of number of blocks on the Finney chain.\n\n3.3 What type of data do validators use for queries? Is there a risk of data exhaustion? If not, provide examples of how data is generated or created to ensure unique validations.\n\nTo combat potential data exhaustion and ensure uniqueness, our subnet has integrated with the Corcel API, part of Bittensor Subnetwork 18. This integration allows validators to generate synthetic, unique prompts, significantly reducing redundancy risks and improving network security, thus our subnet has taken a step towards strengthening the Bittensor ecosystem.\n\nTo ensure there is no downtime in Cortext API, Validators utilize a diverse dataset, selecting prompts randomly from a pool of 678K entries for TTS, VC, and 500K prompts TTM services. This mechanism minimizes the risk of data exhaustion; however, with multiple validators, there could be some overlap. Our team is working to increase this backup dataset.\n\n3.4 GitHub Link to Incentives Mechanism\nhttps://github.com/UncleTensor/AudioSubnet/tree/main/lib",
        "Data Sources and Security:": "4.1 What is the origin of the data used by validators? Indicate if any data augmentation processes are in place.\n\nIn SN 16, we do not use data augmentation. Instead, we have integrated with SN 18 through Corcel API to utilize synthetic, human-like data for all three services: TTS, VC, and TTM.\n\n4.2 Are there any known vulnerabilities within your subnet, such as susceptibility to lookup attacks due to limited dataset size? If so, what measures are planned to safeguard the subnet?\n\nSince the dataset is unlimited and unique for each validator's query, the system is not susceptible to attacks stemming from limited data size. Even if SN 18 – Corcel API has some downtime, the backup dataset will kick in for that period.\n\n4.3 GitHub link to Data Sources\n\nData used from the SN 18 - Corcel API for TTS, VC and TTM.\nhttps://docs.corcel.io/reference/cortext-text\n\nData used from HuggingFace for TTS, VC and TTM:\n- TTS and VC prompts (currently 678K) https://huggingface.co/datasets/etechgrid/Prompts_for_Voice_cloning_and_TTS\n\n- VC Voice embeddings (163 unique speakers) https://huggingface.co/datasets/etechgrid/28.5k_wavfiles_dataset\n\n- TTM music generation prompts (currently 500K) https://huggingface.co/datasets/etechgrid/prompts_for_TTM",
        "Compute Requirements:": "5.1 What are the computational prerequisites for participating in your subnet?\n\nThe benchmarking results for NVIDIA's RTX 4090, A6000, H100, and A100 GPUs in audio tasks underscore their efficiencies in Music Generation, Text-to-Speech (TTS), and Voice Cloning (VC).\n\nThe H100 and A100 models stand out in music and audio evaluations, completing tasks significantly more quickly than their counterparts. Additionally, the benchmarks identify the A100 and H100 as the top performers in TTS tasks. \n\nWhile all GPUs show varied but effective capabilities in Voice Cloning. These findings highlight the strengths of each GPU in handling different audio tasks within the Bittensor ecosystem, offering guidance to users on selecting the most suitable models for their specific needs. \n\nFor complete performance metrics, please refer to the benchmark link: https://github.com/UncleTensor/AudioSubnet/blob/main/docs/benchmark.md\n\n5.2 How can miners increase their rewards? Are they required to train specific models or run predetermined models?\n\nOff-the-Shelf Pretrained Models:\nMiners can download pretrained models from the Hugging Face Hub for all services—Text-to-Speech (TTS), Voice Cloning (VC), and Text-to-Music (TTM)—which offer good performance. This approach allows miners to quickly deploy models that are already trained and ready for immediate use.\n\n\nFinetune Models Setup:\nOur subnet includes fine-tunable model directory arguments, allowing miners to provide their own finetuned custom models to enhance the performance of the subnet. This option gives miners the flexibility to improve upon the base performance of off-the-shelf models by training them further on specific datasets or tasks, potentially leading to higher rewards for superior results.\n\nMiners are not strictly required to train specific models; they have the option to run predetermined models for immediate deployment or to finetune models for potentially better performance and higher rewards.\n\n5.3 Is there any public interface or user interaction with the subnet? If not currently available, are there plans to develop one?\n\nWe're currently developing a user-friendly web application (http://bittaudio.ai) that integrates all our services: Text-to-Speech (TTS), Voice Cloning (VC), and Text-to-Music (TTM) into a single, user-friendly platform. This application will be available for users to access free of charge, showcasing the potential of our audio generation capabilities.\nBy combining these services, we aim to provide a versatile and engaging experience that demonstrates the innovative potential of our Audio subnetwork.\n\nIf you need to have a look at the Miner’s outputs you could easily do that on Wandb Workspace here:\nhttps://wandb.ai/subnet16team/AudioSubnet_Valid\n\n5.4 Are there any significant updates scheduled for the subnet? Please provide details if available.\n\nYes, we have several important updates planned for our subnet that will be implemented in the upcoming period:\n- Integration of synthetic data using the Corcel API.\n- Launch of the Subnet 16 API for Text-to-Speech, Voice Cloning, and Text-to-Music services.\n- refine the Miner code to further enhance response times across TTS, VC, and TTM requests. This optimization is crucial for maintaining our competitive edge and ensuring that our services not only meet but exceed the expectations of our users in terms of speed and reliability.",
        "Notebook and Code:": "6.1 Add a notebook or provide the code that does the following:\n\nThe API can be used by OpenTensor Foundation Validator with their hotkey to query the top miners. Please use the credentials, the repo and documentation provided via email and also watch the YouTube video to see how to use the API.\n\n2) Demonstrate each reward/penalty mechanism/Scoring of the top miner response\n\nRefer to document reward mechanism and relevant penalty mechanism for each service in section 3.1\n\n3) Queries the API and/or links to a frontend(if applicable)\nDetails sent via email to Opentensor Foundation. \nAlso, you can see the API in action in the YouTube video demonstration: https://www.youtube.com/watch?v=UaMXiyDkPbQ",
        "Applications and Collaborations:": "7.1 Have any applications been developed on top of your subnet? While not mandatory, this information is beneficial.\n\nSince the API for our Audio subnetwork is currently in the development and testing phase, there are no applications built on top of it at this moment. However, the testing has yielded promising results, indicating a strong potential for future development. \n\nOnce the API is fully operational, we anticipate a diverse range of applications to emerge, leveraging our unique audio generation capabilities for various uses. We also know that TaoStats and Firsttensor validators are interested to use the audio services on our subnet.\n\nOur team is committed to providing a robust and versatile API to support innovative applications in the audio domain and also allow Validators to earn money by “lending” their bandwidth.\n\n7.2 Is there any ongoing collaboration with other subnets? This is also not a requirement but is valuable information.\n\nYes, we've teamed up with MogMachine, tapping into the Bittensor Subnetwork 18 with the help of the Corcel API. This partnership is all about using SN 18's API to generate endless and unique TTS/VC/TTM synthetic prompts. So, every time a Validator reaches out with a request, they're sending something unique to the Miners, keeping things fresh and interesting. The changes have been pushed on 25/03/2024 to main branch and at the moment all the Validators are using text prompts coming from SN 18 through Corcel API. ",
        "Development Roadmap:": "- API Integration. This rollout will support TTS, VC, and TTM, allowing Validators to develop customized web and mobile applications leveraging Subnet 16 services\n\n- BittAudio (https://bittaudio.ai) platform development. A web application that integrates all our services: Text-to-Speech (TTS), Voice Cloning (VC), and Text-to-Music (TTM) into a single, user-friendly platform.\n\n- We're going to release a bounty program (paid in TAO) in order to find & fix bugs inside our subnet or to improve and optimize our code and our evaluation mechanism.\n\n- Introduction of the ranking system for SN 16 miners.\n\n- Introduction of new features to the TTS service, including voice gender selection and voice tone adjustments and TTM service for music length.\n\n- Introduction of a new service into our subnet: Speech-to-Speech\n\n- Addition of new open-source models for TTS and VC, such as MetaVoice. https://huggingface.co/metavoiceio/metavoice-1B-v0.1 https://github.com/metavoiceio/metavoice-src?tab=Apache-2.0-1-ov-file https://ttsdemo.themetavoice.xyz\n\n- Start collaborating with Subnet 3 MyShell-TTS-Subnet to utilize and integrate their open-source models (OpenVoice and MeloTTS) for Text to Speech. In this way miners can go to SN 3 to train their TTS models, and then come to SN 16 to use them to generate TTS outputs. \nhttps://github.com/myshell-ai/MyShell-TTS-Subnet/tree/main \nhttps://github.com/myshell-ai/OpenVoice \nhttps://github.com/myshell-ai/MeloTTS",
        "Testnet Information:": "9.1 Did your subnet participate on testnet? Describe the scope and participation of your subnet on the testnet.\n\nOur subnet, Subnetwork 16 - AudioSubnet, actively participated in the testnet phase. During the testnet period, we focused on several key objectives:\n\n- Testing the functionality and performance of our communication protocols, including the Synapse Protocol and the Dendrite-Axon Interface, to ensure seamless interaction between validators and miners.\n\n- Evaluating the effectiveness of our reward system based on scoring metrics for Text-to-Speech (TTS), Voice Cloning (VC), and Text-to-Music (TTM) services.\n\n- Assessing the validation measures implemented within our subnet, such as reward mechanisms and data integrity protocols, to safeguard communications and data exchanges and rewards.\n\n- Collaborating with other subnets, such as Subnet 18 , to explore integration opportunities and enhance the overall functionality of the Bittensor ecosystem.\n\nOur participation in the testnet provided valuable insights into the performance and reliability of our subnet's infrastructure and services, allowing us to identify areas for improvement and refinement before transitioning to the live environment.\n\n9.2 Provide information on how updates from the testnet were managed and transitioned into the live environment.\nUpdates and improvements identified during the testnet phase were managed through a structured development and deployment process to ensure a smooth transition into the live environment. This process involved the following steps:\n\n- Identification of issues and areas for improvement: Feedback from validators, miners, and other stakeholders involved in the testnet was collected and analyzed to identify any bugs, vulnerabilities, or performance bottlenecks.\n\n- Development of solutions and enhancements: our development team implemented necessary fixes, optimizations, and feature enhancements to address identified issues and improve overall performance.\n\n- Testing and validation: Once the updates were implemented, thorough testing and validation procedures were conducted to ensure that the changes were effective and did not introduce any new issues or regressions.\n\n- Deployment to the live environment: After successful testing, the updated code and configurations were deployed to the live environment, allowing validators and miners to benefit from the improvements and enhancements made during the testnet phase.\n\n- Continuous monitoring and iteration: Following deployment, ongoing monitoring and iteration processes were established to track the performance of the subnet in the live environment and address any further issues or optimizations as needed.",
        "Demo Recording:": "https://www.youtube.com/watch?v=UaMXiyDkPbQ",
        "Relevant Links:": "11.1 Link to frontend (If developed)\nhttps://bittaudio.ai – work in progress atm..\n\n11.2 Any additional links relevant to your subnet i.e. Documentation, marketing materials, etc.\n\nA. Our Subnet services have garnered significant attention on social media, with nearly 200,000 views on Twitter. This exposure has significantly expanded our reach, introducing a broader audience to TAO and Bittensor.\nThis could be checked on X (Twitter) - https://twitter.com/AudioSubnet\n\nB. We're excited to announce a collaboration with the renowned influencer and music producer AlexParker, who will be bringing the innovative sounds of Bittensor Subnet 16 to life by mixing music generated on our platform at clubs and festivals around the world showcasing the power of AI generated music & Bittensor. \n\nYou can explore his work on YouTube at https://www.youtube.com/@AlexParker808/videos\n\nC. We've successfully resolved several bugs identified by our community members. Special thanks to Fish and Isabella for their insightful comments. We deeply appreciate the support and the valuable ideas and potential issues you've shared with us.\n\nIssue 1 -> Fixed.\nDiscord discussion: https://discord.com/channels/799672011265015819/1166816341697761300/1214127828711510057\nDetails: https://github.com/UncleTensor/AudioSubnet/blob/main/lib/protocol.py\n\nIssue 2 -> Fixed.\nWandb is initialized in TTS service because it starts the logs and all system information right in TTS service. As we are also updating and maintaining and updating the weights globally through TTS, likewise Wandb logs are also initialized globally from TTS and a new Wandb run starts every 4 hours for consolidated log files.\n\nRole parameter has been removed in the upcoming version\n\nDiscord discussion: https://discord.com/channels/799672011265015819/1166816341697761300/1214132004933869569\nDetails:\nhttps://github.com/UncleTensor/AudioSubnet/blob/main/classes/ttm.py\nhttps://github.com/UncleTensor/AudioSubnet/blob/main/classes/tts.py\nhttps://github.com/UncleTensor/AudioSubnet/blob/main/classes/vc.py\n\nIssue 3 -> Fixed.\nDescription: Miner occasionally cannot install packages smoothly on some platforms for example AWS EC2 instance.\n\nWe will include the virtual env preparation code in our repo to facilitate miners and validators installation process.\n\n> mkdir -p ~/miniconda3 && wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh -O ~/miniconda3/miniconda.sh && bash ~/miniconda3/miniconda.sh -b -u -p ~/miniconda3 && rm -rf ~/miniconda3/miniconda.sh && ~/miniconda3/bin/conda init bash && ~/miniconda3/bin/conda init zsh\n> bash\n> conda create -n myenv python=3.10 -y && conda activate myenv\n\n\nIssue 4 -> Fixed.\nThis has been corrected and models have been specified in the description. ‘Optional’ have been removed except for model names.\n\nIssue 5 -> Fixed.\nDescription: Wandb Workspace not working.\nThe issue has been addressed, and the Wandb Workspace is now easily accessible to everyone.\nhttps://wandb.ai/subnet16team/AudioSubnet_Valid\nhttps://wandb.ai/subnet16team/AudioSubnet_Miner",
        "Please ensure that all responses are concise and provide the necessary information to understand the operational parameters of the subnet": "Hi OpenTensor team,\n\nWe are reaching out to inform you that we have carefully prepared and completed the responses to the guidelines for requesting weight from the OTF Validator, as outlined.\nhttps://docs.google.com/document/d/1B0m0wzCATC58FWJxn0Xd6ksZAIJrBe9hNwUf9a50CP4\n\nUnderstanding the importance of these guidelines in streamlining the weights process for SN owners, we have addressed each question, ensuring that the responses are comprehensive, to provide a clear understanding of our subnet's operational parameters.\nWe have included all answers within the contents of this email, following the structure provided in the guidelines document.\n\nHere, you will find detailed insights into our subnet's objectives, communication protocols, incentive mechanisms, data sources, security measures, compute requirements, and more, as requested.\nWe appreciate the opportunity to submit our application for weight allocation and look forward to your feedback and the possibility of updating our subnet's weights accordingly.\n\n*For point 6, we have sent you via email (audiosubnet@gmail.com) the credentials, the API github repo + the documentation needed to query the top miners on SN 16.\n\nThank you for considering our submission. Please do not hesitate to contact us if you require any further information or clarification.",
        "Email Address": ""
    },
    {
        "subnet": "chi-22",
        "SN Name and SN Number": "Datura 22",
        "Subnet Owner Discord Username": "p383_54249",
        "Subnet Objectives and Contributions:": "The primary purpose of this subnet is to aggregate, analyze, and validate diverse data sources to provide high-quality, real-time summaries and insights. It enhances the Bittensor network by offering sophisticated data processing capabilities and fostering collaboration among subnets, thereby improving the network's efficiency, quality of data, and overall value to users.",
        "Communication Protocols:": "This subnet primarily uses HTTP/HTTPS for communication between miners, validators, and the front-end interface. The streaming of real-time data to the UI, the interaction between various components of the subnet (such as querying and receiving data from miners, and sending data for validation), and API calls for data retrieval and submission all leverage these widely adopted protocols to ensure compatibility and ease of integration across different platforms and services.",
        "Incentives Mechanism:": " Currently, we have three rewarding methods:\n- Summary relevance\n- Twitter Content Relevance\n- Web Links Content Relevance\n\nSee here for the method compute_rewards_and_penalties: https://github.com/surcyf123/smart-scrape/blob/a4f59a81102d22a88e9fa056b651727661fa98fa/neurons/validators/scraper_validator.py#L161 \n\nHere is all reward related class: https://github.com/surcyf123/smart-scrape/tree/main/neurons/validators/reward",
        "Data Sources and Security:": "Our subnet is scraping data, analyse and give sinnaly summary response based on user's prompt. Right now we have iplemented several datasources and validate them. we have plan to add more datasources such as:\n1. Reddit\n2. Hackernews\n3. Bing\n4. Bittensor documentation\n5. Add user's datasources\n6. Improe UI, and provide History of data",
        "Compute Requirements:": "https://github.com/surcyf123/smart-scrape/blob/main/min_compute.yml",
        "Notebook and Code:": "Add a notebook link, or provide the code that accomplishes the following:\n1.1) Query the top miner UID (We will use our hotkey for this).\n1.2) Demonstrate each reward/penalty mechanism/scoring for the top miner's response.\n1.3) Query the API and/or provide links to a frontend, if applicable. \n\n1. To query a high-incentive miner, you have two options:\n\n1.1 Call test.py at https://github.com/surcyf123/smart-scrape/blob/main/test.py\n\npython3 test.py [miner_uid]\n\n1.2 You can directly call our API at https://github.com/surcyf123/smart-scrape/blob/a4f59a81102d22a88e9fa056b651727661fa98fa/neurons/validators/api.py#L83\n\nIf you wish to test any specific miner, you can send UIDs, or run the test UI from here https://github.com/surcyf123/smart-scrape/tree/main/ui, which you can connect to from there.\n\n1.3. Currently, we have three rewarding methods:\n- Summary relevance\n- Twitter Content Relevance\n- Web Links Content Relevance\n\nSee here for the method compute_rewards_and_penalties: https://github.com/surcyf123/smart-scrape/blob/a4f59a81102d22a88e9fa056b651727661fa98fa/neurons/validators/scraper_validator.py#L161",
        "Applications and Collaborations:": "you can directly see our platform https://datura.ai/",
        "Development Roadmap:": "we always make improvement and changes on our subnet, such as scoring system, streaming process, query generator, and adding more data in next coming weeks we have plan to add:\n1. Bing search\n2. Reddit\n3. Bittensor Discord Search\n4. Connect to subnet 18 for improve validate process of summary content",
        "Testnet Information:": "Yes, we have run our testnet (Subnet 41) similarly to our main subnet and used it for testing purposes, including new features and improvements.\n\nBefore making any changes in the live environment, we conduct tests on our testnet (Subnet 41). We release updates through our GitHub repository. Before deploying new changes to the subnet, \nwe announce them in our community channel on Discord and provide a detailed explanation of the upcoming changes in the next release, preparing both miner and validator owners for these updates. At the appointed time, we merge the updates into the main branch. \nSome validator owners run an auto-update script we developed, allowing the validator to update automatically, whereas miner owners must update manually.\n",
        "Demo Recording:": "https://share.cleanshot.com/886Thw6F",
        "Relevant Links:": null,
        "Please ensure that all responses are concise and provide the necessary information to understand the operational parameters of the subnet": "-",
        "Email Address": ""
    },
    {
        "subnet": "zayin-31",
        "SN Name and SN Number": "Healthcare, Subnet - 31",
        "Subnet Owner Discord Username": "cogent_demon",
        "Subnet Objectives and Contributions:": "Our subnet is truly unique, serving as the vital link between Bittensor and healthcare. Dedicated to advancing healthcare AI, our ultimate goal is to establish a comprehensive, globally accessible healthcare system powered by AI. This system will offer predictive healthcare analytics, including disease diagnosis from medical images and patient data, predicting protein 3D structures, and oncology and radiography analysis.\n\nCurrently, we focus on disease prediction from medical images like chest x-rays. However, our system's scope will expand to analyze patterns in a patient's medical history and current health data to predict potential health risks.\nOur subnet's contribution to the Bittensor ecosystem is substantial. By building a robust healthcare and Bittensor integration, we aim to pique people's interest in Bittensor and encourage their active participation.\nAn API is in the pipeline, and we're also developing web and mobile apps. Ultimately, our mobile app will serve as the most reliable conduit between healthcare and Bittensor.",
        "Communication Protocols:": "Under our subnet, there is no direct communication between miners and validators. Miners train their models and upload them to Hugging Face, then push the repository name and commit hash to the chain. Validators locally evaluate the miners' models and adjust weights based on model performance.",
        "Incentives Mechanism:": "Validators utilize their datasets for evaluation, and miners with identical models are differentiated based on the model commit time—the earlier, the better. We've allocated approximately 37% of emissions to the top-performing miner, incentivizing miners to optimize their models. The sole pathway for miners to earn rewards is by training their models to be the best.\nhttps://github.com/bthealthcare/healthcare-subnet/blob/main/healthcare/validator/reward.py#L101",
        "Data Sources and Security:": "The dataset for validators varies from one another, and each validator can access their dataset, which is shared on Hugging Face. We continuously expand this dataset, ensuring there is no overlap between validator datasets. With support from data scientists and collaborative medical companies, our dataset has significantly expanded. Moving forward, we plan to implement a reward mechanism in our mobile app to facilitate collaboration with more companies providing datasets. To address patient privacy concerns, we plan to implement map-reduce to ensure secure data processing. Medical companies (miners) will train the same models simultaneously, and validators will combine those models.",
        "Compute Requirements:": "Validators and miners should possess high computing power as they evaluate and train AI models. (https://github.com/bthealthcare/healthcare-subnet/blob/main/min_compute.yml) We provide the default codebase and dataset for training, and to receive better rewards, they are encouraged to customize their models and datasets, leading to higher model accuracy. We have developed a demo site with a simple frontend available at (https://bthealthcare.io). With the API completed, our team will now focus on completing the app, dedicated to Bittensor, Healthcare, and AI.",
        "Notebook and Code:": "1) metagraph = subtensor.metagraph(31) # The metagraph of subnet 31\nincentive = metagraph.I # A list of Tensor, the incentive values\ntop_index = torch.argsort(incentive, descending=True)[0].item()\n2) https://github.com/bthealthcare/healthcare-subnet/blob/main/healthcare/validator/reward.py#L101\n3) url = \"https://bthealthcare.io/process-image\"\nfiles = {'image': open('0.png', 'rb')}\nresponse = requests.post(url, files=files)",
        "Applications and Collaborations:": "Currently the demo with simple frontend is available, and in the near future the mobile app will be published. https://bthealthcare.io\nAfter completing our mobile app, to obtain the best model, we will collaborate with the map-reduce subnet to address patient privacy concerns.",
        "Development Roadmap:": "1) A mobile app that diagnosis disease from medical images and patient data, predicting protein 3D structures, and oncology and radiography analysis will be published.\n2) Currently, we focus on disease prediction from medical images like chest x-rays. However, our system's scope will expand to analyze patterns in a patient's medical history and current health data to predict potential health risks.",
        "Testnet Information:": "The UID of our testnet is 53. Whenever we make a new update, we push it to the develop branch and test it on the testnet. After confirming that the update works properly, we merge the code to the main branch and publish it.",
        "Demo Recording:": "https://www.loom.com/share/51f8509b736c4afcbc4e46a5c8fb60c8",
        "Relevant Links:": "https://github.com/bthealthcare/healthcare-subnet/blob/main/docs/whitepaper.md",
        "Please ensure that all responses are concise and provide the necessary information to understand the operational parameters of the subnet": null,
        "Email Address": ""
    },
    {
        "subnet": "xi-14",
        "SN Name and SN Number": "LLM Defender, SN14",
        "Subnet Owner Discord Username": "ceterum_ and cradow",
        "Subnet Objectives and Contributions:": "The objective of Subnet 14 is to provide an extra layer of security for LLM-based applications following the OWASP TOP 10 for LLMs (https://owasp.org/www-project-top-ten/). At the moment, we are focused on prompt injections and sensitive information disclosure but plan to add coverage for other types of attacks with future releases. \n\nWe are building towards an API that can be integrated with other subnets in the Bittensor network that use LLMs in their infrastructure with release v1.0.0. With the release of v1.1.0 will come a bulk analyzer that will be able to process 1000+ prompts per round. This could be used to pre-process datasets used for training or other purposes to ensure that sensitive information, potential prompt injections, and other generally malicious content are filtered out. Looking through the lens of digital commodities, the capabilities provided by the subnet could enhance the security of all subnets dealing with user-issued prompts by preventing prompt injection and sensitive data leakage in the responses provided by subnets that use LLMs to produce responses to prompts. The subnet’s full potential will be unleashed through the product we are building. \n\nIn the spirit of transparency, we are not aiming to monetize the product for the Bittensor community. We are instead planning to publish the code in GitHub such that anyone with access to an authorized validator (i.e., a validator with >20k staked TAO) can spin up their own private API. We’ll also be running an API for people without an authorized validator. However, to prevent DDoS and other unwanted behavior, people will have to sign up for the product such that API keys can be distributed with rate limits applied for those keys depending on the individual use case.\n\nMore information about who we are can be found in our public documentation (https://docs.synapsec.ai/)",
        "Communication Protocols:": "The communication protocol has been documented in the Subnet documentation at https://docs.synapsec.ai/Subnet/architecture/\n\nThe LLMDefenderProtocol is currently utilizing plaintext protocol, but we are aiming to add TLS encryption for the communication in release v0.7.0 (see preliminary roadmap here). \n\nValidators send a synapse to 64 miners at once roughly every ~30 seconds (1.5 * blocktime sleep + 12s timeout) such that it takes 4 rounds, or roughly 2 minutes to go through every miner within the subnet. The synapse contains only the signature and the synapse_uuid based on which the miner fetches the actual prompt from the fetch API. The synapse is roughly ~500 bytes and the prompt that is being fetched can be anything between a couple of bytes or multiple kilobytes, depending on the prompt that is to be analyzed. On average the prompt size is roughly 1500 bytes. The synapse response from the miner is roughly twice the size of the original synapse, so ~1000 bytes. To summarize, a single validator causes approximately ~25 bytes/s load towards a single miner, so for all of the miners it is approximately 5750 bytes/s (~230 miners * 25 bytes/s), which translates to 46 kbit/s of bandwidth consumption per validator.\n\nValidators are by default updating weights every 100 blocks and weight setting on miners has been disabled, so the load towards the Bittensor network is quite low. Validators are syncing metagraph every 5 steps (so once every ~2,5 minutes) and miners every 600 steps (~10 minutes).\n\nThe GitHub link for the main miner loop is https://github.com/synapsec-ai/llm-defender-subnet/blob/main/llm_defender/neurons/miner.py\n\nThe GitHub link for the main validator loop is https://github.com/synapsec-ai/llm-defender-subnet/blob/main/llm_defender/neurons/validator.py\n\nAt the moment, it looks like this:\n\n- Validators query a prompt from our API alongside its target value. The API is configured to query the metagraph and detect hotkeys of SN14 validators, and only accept requests signed by them. The API is also rate-limited to prevent validators from gaining an unfair advantage should they choose to spin up a miner. \n\n- The validators will initiate prompt generation with the prompt API, causing it to send a prompt to the prompt fetcher API and feed the validator the prompt metadata. \n\n- The validator will then send the synapse to a miner who will fetch the contents from the fetcher API, run the analysis, and send the results back to the validator.\n\n- Validators feed the prompts to miners who execute their analyzers and generate a confidence score for the prompt being safe (0.0) to malicious (1.0), which will be included alongside data for each engine’s operations in a reply to the validator.\n\n- The validator calculates the penalty for answer accuracy.\n\n- Validators store results in an API that we will be using for two use-cases: (1) Provide a dashboard about the subnet performance and (2) Provide miners an access to their own validation results (sensitive data removed)",
        "Incentives Mechanism:": "Penalties applied to miner responses are described in our public documentation at https://docs.synapsec.ai/Reward%20Mechanism/penalties/\n\nThe penalty mechanisms for our subnet are analyzer-specific, GitHub links are below:\n\n- https://github.com/synapsec-ai/llm-defender-subnet/blob/main/llm_defender/core/validators/analyzers/prompt_injection/reward/penalty.py\n\n- https://github.com/synapsec-ai/llm-defender-subnet/main/llm_defender/core/validators/analyzers/sensitive_data/reward/penalty.py\n\nOur scoring mechanism is described in our public documentation at https://docs.synapsec.ai/Reward%20Mechanism/scoring/\n\nThe scoring mechanisms for our function are also analyzer-specific. GitHub links are below:\n\n- https://github.com/synapsec-ai/llm-defender-subnet/blob/main/llm_defender/core/validators/analyzers/prompt_injection/reward/scoring.py\n\n- https://github.com/synapsec-ai/llm-defender-subnet/blob/main/llm_defender/core/validators/analyzers/sensitive_data/reward/scoring.py\n\nPlease reference Section 4 for information about the types of data validators use for queries, and for data exhaustion risks.",
        "Data Sources and Security:": "The data used by the Subnet is synthetically generated by using OpenAI gpt-4-turbo-preview and is sent to the network via the Prompt API (more information at: https://docs.synapsec.ai/Subnet/internal_api/). Approximately 25% of the prompts we sent out to the network are completely unique and they are given the most weight (1.0) in the scoring. The data that is sent out to the network is semi-automatically rotated into the datasets to be used again but with less weight (0.1). A higher weight means correctly (or incorrectly) classifying the prompt has a bigger impact on the miner score. See Section 3 for a more detailed explanation of the incentive mechanism.\n\nOnce there are a sufficient amount of rotated prompts in the Prompt API, the oldest prompts are removed from the rotation and published as datasets in Huggingface (https://huggingface.co/synapsecai). The published datasets are to be used in the permanent testnet setup (see section 9), as well as provide the miners a way to more easily start fine-tuning their models.\n\nThe burn rate of unique prompts is approximately ~2000 prompts per day. We are currently experimenting with various mechanisms to reliably create the prompts and once we have collected enough data about the generation, we’ll be looking into the possibility of using subnet 18 as a source for the synthetic data. There are approximately 30,000 prompts in the local dataset used by the Prompt API.\n\nWithin the Prompt API, there are rate limits for both the source IP address (100 requests every 10 minutes) as well as a daily quota for the validator hotkey based on the optimal execution speed of an unmodified validator. These measures combined with the unique prompts make the harvesting of the prompts inefficient, as the prompts in the dataset are weighted less and the unique prompts are not replayed with the original weight.\n\nOnly validators with more than 20,000 staked TAO have access to the Prompt API. All requests must be signed by the validator hotkey and if the signature does not match, the request will be denied.",
        "Compute Requirements:": "Information on computational prerequisites can be found in our public documentation at https://docs.synapsec.ai/\n\nInformation on miner rewards and fine-tuning can be found in our public documentation at https://docs.synapsec.ai/Mining/fine-tuning-guide/\n\nWe are planning to release a dashboard for metrics with (https://docs.synapsec.ai/Subnet/roadmap/#v060-beta)\n\nInformation on our roadmap can be found in our public documentation at https://docs.synapsec.ai/Subnet/roadmap/",
        "Notebook and Code:": "A Jupyter notebook can be found from the GitHub repository that can be used to query the top miner (https://github.com/synapsec-ai/llm-defender-subnet/blob/release/0.5.0/scripts/helpers/query_notebook.ipynb). Apart from the standard python modules installing with the subnet, the only extra module that needs to be installed is the datasets module.\n\nTo execute the notebook, the validator hotkey and network must be defined in cell 2. By default, it uses a dataset that has already been sent out to the miners, so the top miners are likely able to correctly classify prompts.",
        "Applications and Collaborations:": "We have been in discussions with three subnet owners and several stakeholders outside of Bittensor to initiate integration with the subnet API. This process will commence once the API has achieved a sufficient level of maturity. With the release of v1.1.0, we will also have a bulk analyzer that could be used to cleanse datasets used in other subnets of possible prompt injections, sensitive information disclosures, or otherwise harmful content.",
        "Development Roadmap:": "The development roadmap is in our public documentation at https://docs.synapsec.ai/Subnet/roadmap/\n\nThe roadmap is subject to change depending on the needs of the community, but the rough outline depicted in the roadmap section of our documentation is the guiding factor when it comes to the development of the subnet. We are aiming to push out one minor release every 2-3 weeks, so we are approximately 10-15 weeks away from the release of v1.0.0 (so it would be out at the end of Q2/2024 or early Q3/2024).",
        "Testnet Information:": "We have reserved a testnet slot (netuid 38) but have been mostly using it as a testing network with the development team. However, as we are closing in on release v1.0.0 and the public release of our Subnet API (i.e., the product we are building), we’ll be revisiting the way we utilize the testnet. \n\nThe following information is a rough outline of how we are planning to use it, but nothing has been set in stone yet:\n\n- Setup a validator that is always running the latest version from the development branch (the latest development branch matches the mainnet version if we are not working on integration testing of a new release)\n\n- We will be publishing the logs collected by the testnet validator to a centralized repository for everyone to see (to allow miners to see the validation logs and use the testnet to test their fine-tuned models)\n\n- The testnet will be using a separate Prompt API with a separate dataset - there will be a pipeline that automatically adds the prompts issued in the mainnet within the datasets used in the testnet (in the future, the prompts sent to the mainnet will always be sent out exactly once - i.e., the prompts are not reused in mainnet)\n\n- Our integration testing phase will last at least 1 week for regular changes and 2 weeks for changes with breaking changes. This is to allow miners to test the changes, update their models, and ensure that the Subnet API remains operational even when we push out new updates with breaking changes",
        "Demo Recording:": "We are aiming to produce a demo of the Subnet API but we are not yet in a stage in which one could be recorded. Once we are close to the release of public alpha, we’ll be resubmitting this form with an updated link to a demo recording.\n\nThe Subnet API summary can be found at https://docs.synapsec.ai/Subnet/subnet_api/\n\nAdditionally, the notebook we have sent out as a reply to point number (6) provides a rough understanding of how the API would look and function on a practical level. Please note that a lot of the development work that is needed to increase the performance of the API has not been done yet, so the end results will be much faster than the prototype given in the notebook.",
        "Relevant Links:": "X/Twitter (https://twitter.com/SYNAPSEC_AI)\n\nWebsite (https://www.synapsec.ai/)\n\nDocumentation (https://docs.synapsec.ai/)\n\nGitHub (https://github.com/synapsec-ai/llm-defender-subnet)\n\nSubstack (https://substack.com/@synapsec)",
        "Please ensure that all responses are concise and provide the necessary information to understand the operational parameters of the subnet": null,
        "Email Address": ""
    },
    {
        "subnet": "chet-32",
        "SN Name and SN Number": "Subnet 32",
        "Subnet Owner Discord Username": "lagunast.eth",
        "Subnet Objectives and Contributions:": "The primary purpose of this subnet is to create a decentralized environment aimed at identifying content generated by large language models (LLMs).\n\nWith the recent surge in LLMs appeared many cases where we do actually want to recognize whether this text was generated by AI or written by human. Let's explore some scenarios to highlight the potential and significance of LLM detection.\n\n- For ML-engineers. Whether you’re sourcing training data, developing a foundational LLM, or fine tuning on your own data, you need to ensure generative text does not make it into your training set. We can help.\n\n- For teachers. While tools like ChatGPT offer numerous benefits for the educational sector, they also present opportunities for students to cheat on assignments and exams. Therefore, it is crucial to differentiate between responses authored by genuine students and those generated by LLMs.\n\n- For bloggers. Recently many bloggers faced a lot of ai-generated comments in their social networks. These comments are not really meaningful but attract the attention of their audience and promote unrelated products. With our subnet, you can easily identify which comments are ai-generated and automatically ban them.\n\nAnd many more, like:\n\n- For writers. By utilizing an LLM detection system, writers can assess their text segment by segment to identify sections that appear machine-generated. This enables them to refine these areas to enhance the overall human-like quality of their writing.\n\n- For recruiting. Have you also noticed receiving far more applications with lower candidate quality? AI has enabled people to spam hiring teams with artificially written cover letters and assessments. We help you find the candidates who care about your mission and your quality standards.\n\n- For cyber security. Scammers can leverage LLMs to quickly and easily create realistic and personalized phishing emails. We can help you determine the provenance of any document or email you’re reviewing.\n\nAs you can see there are a lot of areas where AI detection can be very helpful. We believe that creating llm-detection subnet not only provides a useful tool at a good price for people to use, but also encourages competition to make better and smarter ways to spot AI-generated content.\n",
        "Communication Protocols:": "We haven't changed how data is sent. It's the same way as in the template subnet. \n\nWe send text as challenge fields and receive float numbers as challenge responses. On average, it takes about 50 seconds to create a challenge for each validator. Every 50 seconds, each validator sends these challenges to 30 miners (by default). The average data size is about 60.38KB.\n\nWe haven't added any extra encryption. As of now, we don't plan to do so.\n\n",
        "Incentives Mechanism:": "To evaluate miners’ quality, validators query them with 50 texts every step. Each text can be either human-written or ai-generated. Miner makes predictions and returns the probabilities of the texts to be ai-generated. Validator counts a reward based on its prediction.\n\nMetrics\n\nBased on Detecting LLM-Generated Text in Computing Education article we decided to divide our reward on 3 parts:\n\nF1 score\nWe decided to use it instead of classic accuracy, because it better represents the quality of the model especially on binary-classification tasks.\n\nFalse Positive score\nFP_score = 1 - FP / len(samples).\nIt is usually more important not to mistakenly classify human-written text as AI-generated than the other way around. It is preferable to tolerate a few more instances of student cheating or read some AI-generated emails than to wrongly penalize a real student or miss an important letter.\n\nAP score\nAP summarizes a precision-recall curve by calculating the weighted mean of precisions achieved at each threshold. This allows us to evaluate the quality of the model's ranking.\n\nFinal reward\nThe final reward is the average of these three values. We also are going to add non-linear normalization to the miner weights and take into account answer time in the future.\n\nGithub: reward.py\n",
        "Data Sources and Security:": "For validating we use two types of data, which is balanced in proportion 1:1.\n\nHuman-written texts\nTo gather human-written validation data we use C4 dataset.\n\nC4 dataset is a collection of about 750GB of English-language text (it’s about 18B samples) sourced from the public Common Crawl web scrape. It includes heuristics to extract only natural language (as opposed to boilerplate and other gibberish) in addition to extensive deduplication.\n\nAI-generated texts\nFor AI-generated text collection, we need to obtain prompts and then generate texts based on these prompts. We combined two approaches for collecting prompts:\nOpen Dataset (30% of prompts). Some prompts are taken from the English section of the hc3 dataset.\n\nPrompt generation (70% of prompts). For prompt generation we implemented the same approach that is used in prompting subnet. Here we use different contexts (Wikipedia API, StackOverflow and mathgenerator), different tasks (Question answering, Summarization, Code debugging, Mathematics and more) and different agents to generate variable prompts on a wide range of topics.\n\nWhen prompts are obtained, we use the Ollama GitHub repository to run Large Language Models and generate completions for these prompts. As LLMs we use five SOTA models: vicuna, mistral, gemma:7b, neural-chat and zephyr:7b-beta.\n\nData augmentation to prevent cheating\nTo prevent remembering C4 dataset, which contains human-written texts, we add some augmentation to both ai-generated and human-written texts. First of all we select a random sequence of consecutive sentences from a given text. Then we add in a random place misspelling or remove a random adjective.\n\nThese augmentations don't allow miners to precalculate hashes on C4 dataset and then use them to determine whether this text is present in the human set of data or not.\n\nGithub: data_generator.py\n",
        "Compute Requirements:": "Current baseline solution for miners can be successfully run on RTX 4090 video-cards. Validators also need to have at least RTX 4090 to generate samples fast enough.\n\nWe’ve implemented a solid baseline solution (one of SOTA for the LLM-detection problem), so if miners want to gain more rewards they have to do their own research and experiments.\n\nWe've developed an MVP version of our website, available at https://its-ai.streamlit.app/, so that everyone can assess the quality of our miners at any time.\n\nYou can find all our planned updates in the Roadmap section.\n",
        "Notebook and Code:": "A notebook: https://drive.google.com/file/d/10tfmmfWD3FY3AjWcHDZ2t5IPDiyefn7K/view?usp=sharing\n\nOne query from validators contains 50 texts each on which is human-written or ai-generated, you can find sample query in this csv file: \n\nhttps://drive.google.com/file/d/1OGpM8bNSJXMPwV2iShazR5sgjnLv0vV5/view?usp=sharing",
        "Applications and Collaborations:": "Due to the recent launch of our subnet, we haven’t yet built many applications. However, we've developed an MVP version of our website, available at https://its-ai.streamlit.app/, so that everyone can assess the quality of our miners at any time. We’re going to develop additional applications on top of the subnet - you can read more about them in the Roadmap section.",
        "Development Roadmap:": "In addition to making a fair validation mechanism and a solid baseline solution, which we’ve already implemented, one of the important tasks for us as subnet owners is to apply the subnet for real usage. Given the relevance of the problem, there is clearly a request for such solutions. That’s what we’re going to do:\n\nWeb service\nWe’ve already developed an MVP version of a website for our subnet, where you can write some texts and then get miners' predictions with probability of this text to be ai-generated. But we’re going to develop a full version of web service, which will provide users even outside bittensor community availability to detect ai-generated texts.\n\nTwitter extension\nToday, X/Twitter is among the top 6 social networking apps in the United States. And boasts over 500 million users worldwide. With the rapid growth of Large Language Models like ChatGpt and more and more content on the internet are generated by them. \nWe’re going to build an extension for twitter, which will mark tweets and comments that you’re reading with ai-generated/human-written tags based on miners predictions from the subnet, so that people can know what content is qualitative and which texts are just auto-generated. \n\nBrowser extension\nWe also found it very useful to have an ability to instantly check whether some peace of text that you’re reading is ai-generated or human-written, so one of the application that we want to develop is a browser extension, with which users can just highlight some text and see a probability of this text to be ai-generated.\n\nAPI\nAs mentioned above we’re going to develop several applications based on our subnet, but there are of course many more use cases for llm-detection in particular situations/businesses. So, we are also going to provide an API service that can be used by developers for their own integrations or for making predictions on a big amount of text (for example by AI engineers to clean up their datasets).\n\nCommerce\nAll of the mentioned above services will have their own subscription plans to commercialize SN32. They will be based on api, which will be run by validators to provide access for miners and on which validators will be able to earn additional money. \n\n\nBy commercializing our product, we will become less reliant on emissions and start gaining real usage. Also, by the time when dynamic tao is introduced and validators' emission becomes zero, our token will already have great utility, and validators will be earning from the mentioned services.\n",
        "Testnet Information:": "Yes, we participated in the testnet under subnet 87, where we deployed multiple validators and miners to test the subnet before transitioning to the mainnet. We are currently hosting several validators, so that miners can test their solutions on the testnet before they move to the mainnet.\n",
        "Demo Recording:": "Demo: https://www.loom.com/share/305ac095ed514d7597322d26272a8bab",
        "Relevant Links:": "Linktr.ee: https://linktr.ee/itsaisubnet\nWeb Frontend App: https://its-ai.streamlit.app/\nTwitter: https://twitter.com/ai_detection\nGithub: https://github.com/It-s-AI/llm-detection\n",
        "Please ensure that all responses are concise and provide the necessary information to understand the operational parameters of the subnet": null,
        "Email Address": ""
    },
    {
        "subnet": "omicron-15",
        "SN Name and SN Number": "Sn15 Chain Insights (mainnet)",
        "Subnet Owner Discord Username": "aphex5",
        "Subnet Objectives and Contributions:": "Blockchain technology is a powerful tool for increasing transparency, but it can be difficult to comprehend. Thankfully, our service, Blockchain Insight, makes it straightforward to ask questions in simple language and receive clear answers. You can ask us about various blockchains, not just Bitcoin, and we provide information on features such as transaction history and balance. We also offer a visual representation of the flow of money for your convenience.\n\nOur goal is to provide a better solution than The Graph Protocol by transforming blockchain data into specific models and enhancing them with AI capabilities. To achieve this, we aim to index blockchain data into specific datasets, train LLM models based on this indexed data, and enhance miner's data with individual external data sources. Ultimately, our service will be able to serve user prompts and interpret results more effectively.\n",
        "Communication Protocols:": "- Which communication protocols are utilized by this subnet? \nThe communication protocols have been divided into the following layers for better understanding:\n1. Blockchain layer: This layer communicates with the blockchain using Bitcoin/Ethereum (JSON RPC).\n2. Data layer: This layer uses Memgraph/PgSql databases for storing the indexed blockchain data for funds flow and account models. The communication protocol used in this layer is bolt/tcpip.\n3. Application layer: This layer uses HTTPS/HTTP, which is the communication protocol used for chat-app, API, validator, and miner communication.  \n- What type of data is transmitted, how frequently does this occur, and what is the typical data size? \nWhen it comes to blockchain transactions, data is transmitted in various types depending on the block's time and type. The transmission frequency and typical data size can also vary. Every time a block is validated by the blockchain node, the miner indexes it and transforms it into a specific data model, such as a funds flow model or an account model.\nIf a user wants to query the subnet, the request goes from the chat API, through the validator, and to the selected miner. The miner uses LLM to translate the user's text, execute a query on the databases, interpret results with LLM's help, and return text containing a description and JSON data containing graph/account model data.   - Is there any security or encryption applied to the messages? \n- Is there any security or encryption applied to the messages? \nWe use HTTPS encryption to send query prompts to the chat app. The prompt is then sent to the validator and miner through the HTTP protocol. We do not send sensitive data to the miners, only prompts related to blockchain data. \nSince we deal with blockchain data, no security is required for the data itself. Blockchain data is meant to be open, and this is the blockchain way of thinking. The API communicates through HTTPS, and that's enough to protect the data.\n - GitHub Link Relevant to Communication Protocols\n- Bitcoin RPC protocol documentation https://developer.bitcoin.org/reference/rpc/\n- The BOLT protocol https://en.wikipedia.org/wiki/Bolt_(network_protocol)\n",
        "Incentives Mechanism:": "Scoring function mechanism:\nhttps://github.com/blockchain-insights/blockchain-data-subnet/blob/main/docs/scoring_function_explanation.md\n\nSubnet-15 is a unique subnet in which miners cannot provide vague responses. They can only provide genuine blockchain data or falsehoods. This has resulted in an uneven distribution of miner scores. To address this issue, we have limited the number of miners that a coldkey can operate. Currently, we are also restricting the number of hotkeys a miner can possess and their usage of memgraph instances and IPs. As we expand our blockchain operations, we plan to further decrease the number of instances allowed per miner to ensure a more balanced distribution. Miners are selected using a round-robin approach, which ensures that validators query miners equally.\n\nAs part of our continued efforts to improve our scoring mechanism, we will be introducing new metrics to ensure that miners with lower latency and higher uptime are ranked higher. These metrics will be used by validators through our chat app, which will prompt users to query miners and ensure their availability. We will also be implementing high availability solutions such as memgraph and psql replication to further improve uptime.\n\nThe current limit for mining instances is set to 9 per miner. As more supported blockchains are introduced, this limit will be reduced by 2 for each newly added blockchain until we reach a limit of 1 miner per colkey, IP address, and memgraph instance. This change will provide an opportunity for more miners to join the subnet and avoid the issue of a single miner or few miners dominating the mining process, which some other subnets have faced.\n",
        "Data Sources and Security:": "- What is the origin of the data used by validators? Indicate if any data augmentation processes are in place. \nValidators use data from blockchain full nodes to generate challenges for the miners that are difficult to compute but easy to verify. \nAre there any known vulnerabilities within your subnet, such as susceptibility to lookup attacks due to limited dataset size? If so, what measures are planned to safeguard the subnet?\nIn the last month, we upgraded our data model to version 2 and implemented a stronger verification mechanism. This includes the introduction of easy-to-validate yet hard-to-compute challenges, as well as computing verification checksums into nodes in the graph model. With these changes, we can now ensure that miners are serving proper data using graph databases.\n\nWe remain constantly vigilant by keeping track of validator logs, miners and validators metadata. Additionally, we have brought together a team of experienced miners to help identify any potential bugs or areas for improvement. Working together, we are always on the lookout for vulnerabilities that could be exploited.\n",
        "Compute Requirements:": "Miner requirement:\n~ 7.8 TB disk storage, modern cpu with min 32 cores, +2TB RAM\nValidator requirements:\n~1.9TB disk storage, modern cpu with 8 cores, 128 GB RAM\nAdditional requirements:\nOnce we have integrated NVIDIA's cuGraph support, we will require A100 cards on the miner's side. These cards will significantly enhance graph search capabilities.\nMoreover, miners will have the option to use their own self-hosted LLM solutions instead of relying on API keys.  That will also require running fine-tuned LLM models on external hardware.\n - How can miners increase their rewards? Are they required to train specific models or run predetermined models?\nIt is proposed to index multiple blockchains and keep them updated, including their memgraph instance. In the future, miners can increase their rewards by fine-tuning LLMs to answer user queries such as multilingual and interpretation of responses to queries. In addition, miners should scrape social data to obtain user profiles and their cryptocurrency addresses.\n- Is there any public interface or user interaction with the subnet? If not currently available, are there plans to develop one?\nWe’re currently implementing an MVP to interact and dialog with bitcoin blockchain. Furthermore we’re currently integrating our subnet with the Corcel website and we will use sn18 api keys as an option to understand LLM queries.\n\n - Are there any significant updates scheduled for the subnet? Please provide details if available.\nFor the upcoming month, we plan to focus on the MVP of our chat application and integration with Corcel. We will also be introducing a secondary account type model for the Bitcoin blockchain, Ethereum integration, and Tron integration. We aim to improve miner scoring and open up miners for building integration with scraping subnets to get social media accounts related to cryptocurrencies.\n",
        "Notebook and Code:": " Code can be found here: https://github.com/blockchain-insights/blockchain-data-subnet/blob/b2500d4c5cf1069b7c7c91018a39d026ab9b3c7c/neurons/validators/utils/uids.py#L31C5-L31C23\n\nAnd usage by our api here:\nhttps://github.com/blockchain-insights/blockchain-data-subnet/blob/release/2.2/insights/api/insight_api.py\n\nGeneral overview is available at taostats\n",
        "Applications and Collaborations:": "We are in the process of building our own chat app and integrating with Corcel. Additionally, we have established communication with a cryptocurrency exchange regarding AML procedures under NDA.\n",
        "Development Roadmap:": "Please find below a list of development streams currently in progress:\n\nApplication:\n- ChatApp UI development to be completed in April/May timeframe.\n- Corcel Integration also being developed in April/May.\n\nBlockchain integrations:\n- Adding account abstraction for bitcoin model is scheduled to be completed in April.\n- Adding EVM blockchain support is planned for Q2/Q3.\n\n\n\nSubnet:\nImproving miners to make them more competitive is in progress and expected to be completed in Q2.\nFine tuning/prompt engineering models on the miner side is also planned for Q2.\n Miner's data feeding is being worked on in Q2.\n\nMaintenance and monitoring:\n- Metrics dashboard development is scheduled for Q2.\n- Monitoring solution development is also planned for Q2.\n",
        "Testnet Information:": "We utilize our private network for conducting tests, as the testnet is often slow or has maintenance issues. We transition to the mainnet by allowing a grace period for miners and validators. We perform canary testing with a small number of miners and validators, and closely monitor the logs of both. We also implement versioning on the substrate level.\n",
        "Demo Recording:": "Our chat app, currently under development:\n\nhttps://www.loom.com/share/4ef89f1952a542a88968cd24578e1f43?sid=49f08f16-52a9-44e4-90d5-74bdd533a30d\n",
        "Relevant Links:": null,
        "Please ensure that all responses are concise and provide the necessary information to understand the operational parameters of the subnet": null,
        "Email Address": ""
    },
    {
        "subnet": "kappa-10",
        "SN Name and SN Number": "Subnet 10 (Taomap)",
        "Subnet Owner Discord Username": "chaindude",
        "Subnet Objectives and Contributions:": "The Map Reduce Subnet (Taomap) is crucial for distributed machine learning tasks that involve numerous computing nodes. It facilitates the efficient sharing of model weights and gradients during the training process. We are currently exploring a partnership with the Hivetrain Subnet (Sn15) - distributed machine learning subnet to leverage this capability.",
        "Communication Protocols:": "1. Session Information: Owners (SN10 and SN25) creates session and share it to all the miners across the subnets.\n2. Map: Sn10 miners receive data chunks from miners on SN25, process the data (gradient averaging)\n3. Reduce: Sn10 miners send the processed data to miners on SN25 and then SN25 miners can get aggregated gradient to update the model.\n4. Benchmark: Protocol for benchmarking the miners. Rewards are based on the miner's network bandwidth, A miner's network bandwidth is measured by sending a specific size of tensor to all of the validators.\n\nhttps://github.com/Taomap/taomap-subnet/blob/cross-subnet-integration/taomap/protocol.py#L94",
        "Incentives Mechanism:": "Miners earn rewards based on evaluations by validators. Here's how it works in simpler terms:\n\n- All validators check a miner's work at the same time.\n- They do this by receiving a specific amount of data (tensor) from the miner and then adding up the speeds at which they receive it.\n- If a miner sends wrong shape of data or doesn't respond quickly enough during real tasks, they face a penalty.\n- Validators use bt.Tensor which could be deserialized to torch.Tensor.\n\nhttps://github.com/Taomap/taomap-subnet/blob/cross-subnet-integration/neurons/validator.py#L447",
        "Data Sources and Security:": "Our subnet doesn't use any data source.",
        "Compute Requirements:": "- Miners primarily need a strong network connection. The better the connection, the closer miners can get to being in the top 25, which means more rewards\n-  https://taomap.ai\n- We are collaborating with SN25 to achieve Bittensor's core goal: distributed machine learning.",
        "Notebook and Code:": "                synapse = taomap.protocol.Benchmark_Speed(shape=list((1024, 1024, 1024)))\n                benchmark_at = time.time()\n                responses = self.dendrite.query([uid], synapse, timeout = 60, deserialize = True)\n                arrived_at, size = responses[i]\n                total_elapsed = arrived_at - benchmark_at\n                speed = 1 / total_elapsed",
        "Applications and Collaborations:": "- We are currently collaborating with SN25. They essentially need a way to aggregate the gradients generated by miners, and we have found a solution that can be used to achieve that goal.",
        "Development Roadmap:": "- Gradient aggregation/cross-subnet (data parallelism) verification is scheduled to be completed in April\n- Introduced new methods to strengthen data security and network stability in May\n- Model parallelization support for subnet25 miners in Q2",
        "Testnet Information:": "Testnet UID is 32.\n\nCurrently, about 100 miners are participating in the testnet, where we first test our development branch and then deploy it to the mainnet.",
        "Demo Recording:": " Our cross-subnet dashboard is under development. It visualizes the process of map-reducing.\nhttps://www.loom.com/share/5137129d3e7d4928b4654e02de46778f?sid=04efc937-b9c9-41a1-9497-78ef5508bfff",
        "Relevant Links:": null,
        "Please ensure that all responses are concise and provide the necessary information to understand the operational parameters of the subnet": null,
        "Email Address": ""
    },
    {
        "subnet": "epsilon-5",
        "SN Name and SN Number": "SN5",
        "Subnet Owner Discord Username": "yz_h",
        "Subnet Objectives and Contributions:": "OpenKaito aims to become a decentralized indexing layer, where large-scale data acquisition, content understanding and indexing are done through miners. OpenKaito allows validators to efficiently retrieve high quality data through a diverse set of search semantics (keyword, facet/filters, sort by, vector KNN, etc.), which provides access to real-time structured data for AI applications on the Bittensor ecosystem (RAG, search engine, news feeds, etc.)\n\nOpenKaito has recently onboarded indexing of data from Subnet 13 and is in collaboration with Corcel to build an information hub of Bittensor data.",
        "Communication Protocols:": "OpenKaito adopts a customized search protocol that allows users to utilize sophisticated search semantics for querying data. An example query sent from the validator will look like {“query_string”: “Bitcoin AND ETF”, “author”: [author1, author2, …], “sort_by”: “relevance”, “size”: “5”}, and miners return search results (links, metadata, and full original content) in a JSON list. Currently, the content is focused on X.com (Twitter). The response size is determined by the “size” field, while the current validation request uses a size of 5.\nThe messages are not encrypted because all of the data transmitted are public and non-sensitive. However, we plan to onboard SSL-based authentication when we begin to support personalized ranking.\n\n\nPlease find the full search API documentation in https://github.com/OpenKaito/openkaito/blob/main/docs/query_and_response_api.md and the protocol in https://github.com/OpenKaito/openkaito/blob/main/openkaito/protocol.py \n",
        "Incentives Mechanism:": "OpenKaito encourages miners to become efficient and produce high-quality indices through an incentivized search index design. Unlike a regular partitioned search index where data are distributed evenly across each instance and each instance runs the same code, in OpenKaito’s incentivized design, each instance (miner) optimizes its own acquisition, content understanding, and indexing to ensure that the index with the highest quality data is ranked on top.\n\nThe current validation algorithm operates as follows:\n\n1/ Validators randomly sample search keywords, author constraints, and time constraints to construct a search query (e.g., “keyword” = “account abstraction”, “author” = “VitalikButerin”, “date” < “2024-01-01”) and specify a timeout (e.g., timeout = 2s).\n\n2/ Miners receive the request and respond with a ranked list of documents that satisfy these constraints. Notably, for low timeout tasks (currently at 10%, with plans to increase to 100%), miners are required to preload all the data, run a tokenizer, understand the content, and index it to meet the latency requirement.\n\n3/ Validators perform spot checks using crawlers to verify the content and metadata of the responses. Validators then assess the relevance of the results using a Large Language Model (LLM) to rate the relevance between the content and the query.\n\nSince miners are required to prepare for high quality and relevant content in their local index among internet-scale data (e.g. in the case of “Optimism”, finding all related discussions of the project “Optimism” instead of the English word “optimize” from the internet), it is intractable to run the same LLM that validator performs for spot check, as it would be computationally intractable and slow.\n\nCurrently the keywords and users are sampled from a fixed set of results managed through GibHub PR. Aside from the regular updates to the lists, the combinatorial nature of the requests and the time dimension (either from a randomly sampled time interval or judged by recency) make it impossible to exhaust.\n\n\nLink to evaluation code: https://github.com/OpenKaito/openkaito/blob/main/openkaito/evaluation/evaluator.py ",
        "Data Sources and Security:": "The keyword list is sampled from top crypto queries and the user list is sampled from friend.tech https://dune.com/cryptokoryo/friendtech ranking. As mentioned in the previous section, the time dimension and combinatorial nature of search requests (e.g. keyword + author + random time filter) makes it robust against lookup attacks.\n",
        "Compute Requirements:": "OpenKaito recommends that miners use 4-core CPU machines with at least 16GB of RAM. Although we encourage miners to develop their own index database, we recommend at least 100GB of storage if using the provided ElasticSearch docker to avoid running out of disk space.\n\nMiners are recommended to increase their reward through optimizing the following areas:\n\n1/ Data acquisition:\n\nMiners can increase reward by developing their own data acquisition strategy instead of relying on the provided on-demand crawler which runs at request time, since the on-demand crawler may not meet the latency requirements for newly added tasks.\n\n2/ Content understanding:\n\nSince content relevance is judged by LLM instead of keyword matches, miners are recommended to develop their own content filtering and ranking algorithms before adding new content to an index. For example, the provided Twitter crawler performs lemmatization during searches, which means searching for “optimism” will lead to keyword matches on “optimistic”, etc., leading to irrelevant results. A simple fix would be running an exact keyword match heuristic on this type of queries.\n\nA more sophisticated content understanding optimization would involve inferring from external context. For example, for the query “ETH Denver discussions”, some discussions may be about a specific talk but did not have “ETH Denver” in its body. Miners can optimize this type of query by building context (e.g., collecting titles of all ETH Denver talks first).\n",
        "Notebook and Code:": "The query miners and evaluation demo is in notebook: https://github.com/OpenKaito/openkaito/blob/main/scripts/query_miners.ipynb ",
        "Applications and Collaborations:": "We have integrated the indexing support for Subnet 13 - any miner from Data Universe can easily have their data indexed as an additional data source of OpenKaito to make them searchable.\n\nWe are in collaboration with Corcel to develop an information hub for any TAO related discussion, where OpenKaito will serve as the indexing layer (e.g. An LLM will first query OpenKaito to retrieve real-time data before generating an answer).",
        "Development Roadmap:": "[Done] 3/4/2024 - Subnet Launch  (plain search task + request time crawler for data bootstrapping)\n\n[Done] 3/15/2024 - Structured search request (concluded data bootstrapping phase, started testing author search, filters, etc.)\n\n[Done] 3/25/2024 - Subnet 13 integration\n\nApril 2024 - TAO information hub with Corcel\n\nApril 2024 - Additional data integration\n\nMay 2024 - VectorDB, Multimodal tasks (image and audio data indexing)\n\nJune 2024 - Generic information hub\n",
        "Testnet Information:": "We use Testnet 88 mostly for debugging miner and validator setups. \nUpdates to validators will be deployed to testnet first before releasing to the mainnet.",
        "Demo Recording:": "OpenKaito is positioned as an infrastructure layer project serving other applications and we did not develop our own application at this moment. However, we are in collaboration with Corcel to develop an information hub for any TAO related data, where OpenKaito will serve as the index layer to provide real-time data access.",
        "Relevant Links:": null,
        "Please ensure that all responses are concise and provide the necessary information to understand the operational parameters of the subnet": null,
        "Email Address": ""
    },
    {
        "subnet": "",
        "SN Name and SN Number": "Sturdy Subnet on TestNet, netuid 104",
        "Subnet Owner Discord Username": "pgpsam and shr1ftyy",
        "Subnet Objectives and Contributions:": "The subnet’s purpose is to serve as a decentralized yield aggregator. Yield aggregators are DeFi applications that users can deposit to optimize their yields by depositing to various strategies. Yield aggregator applications will query the subnet with information about an aggregator; miners will write custom algorithms to compute the optimal allocation of assets among the aggregator’s strategies; validators will rank these allocations, and then pass the best one back to the aggregator application.\n\nThis subnet will demonstrate that the Bittensor network is reliable and resilient enough to be used for high-value production applications. From Day 1, the subnet will be responsible for allocating $40m+ in real assets and generating revenue for validators. ",
        "Communication Protocols:": "The Bittensor API, its synapse protocol, and axon-dendrite interface are used for miner and validator axon intercommunication. Validators can run a HTTP server to allow third-party applications to integrate with our subnet. \n\nValidators ping miners with synthetic “challenges” to ensure they are running and return results every block. These requests contain synthetically generated data such as different pools with their own parameters, and are typically within the range of 450-550 bytes. Validators also have the option to spin up a HTTP server to become an “organic” validator, which allows third-party applications to submit their own requests to the subnet.The amount of data is typically between 500-1024 bytes. By default, third-party applications require an API key generated by organic validators to access such services. \n\nLinks to relevant communication protocols:\nBittensor, Synapse: https://github.com/opentensor/bittensor/blob/0759f6a584a05e0d1dcbbf2baf54ae80b36e26cb/bittensor/synapse.py\nUvicorn - HTTP (used for “organic” validator API server): https://github.com/encode/uvicorn ",
        "Incentives Mechanism:": "Miners are scored based on their allocations’ yields and their response latency, with an 80% weight placed on yield alone, and the other 20% being dependent on miner latency. The reward curve is defined by a sigmoid curve with response time being the function. For an extensive overview of our reward mechanism please see: https://github.com/Sturdy-Subnet/sturdy-subnet/tree/main?tab=readme-ov-file#subnet-overview.\n\nAs mentioned in the response to Question 2 - validators supplement organic requests with synthetic “challenges.” The data within these synthetic requests is randomly generated by validators. The method for generating this data is explained in greater detail here: https://github.com/Sturdy-Subnet/sturdy-subnet/tree/main?tab=readme-ov-file#subnet-overview .\n\nGithub Link to Incentives Mechanism:\nhttps://github.com/Sturdy-Subnet/sturdy-subnet/blob/main/sturdy/validator/reward.py ",
        "Data Sources and Security:": "As mentioned in the previous response – validators ping miners with synthetic “challenges.” The data within these synthetic requests is randomly generated by validators. How exactly this data is generated is explained in the first point here: https://github.com/Sturdy-Subnet/sturdy-subnet/tree/main?tab=readme-ov-file#subnet-overview. \n\nThere are no known vulnerabilities within the subnet.",
        "Compute Requirements:": "Users can run miners on the subnet off a typical consumer CPU (i.e. 4 core CPU) using the base algorithm we’ve provided. Validators can also run with the same specs - but require some storage space should they choose to run an “organic validator”. Disk space is needed to store a database for API keys which third-party applications can use to integrate with our subnet through said organic validators. \n\nMiners can increase their rewards by improving their asset allocation algorithms so that they return higher yields. There isn’t a specific model required – the goal is for users to innovate and improve on the state of the art.\n\nWe are planning to develop a user interface for users and applications to interact with.\n\nThere are a number of updates scheduled after we launch on mainnet/Finney, including committing allocations directly to the Bittensor network, creating an info bridge to the EVM to eliminate the need for an API, integrating more applications, and providing more base algorithms for miners.",
        "Notebook and Code:": "1) The “top” miners are the ones who return the highest yield allocations with quick response times. If one would like to simply find the miner with the highest APY,  the subnet example script provided  in (3) (see below) should suffice. Otherwise the foundation can simply obtain the uid for the top miner by simply looking through its metagraph and searching for the one with the highest incentive:\nimport bittensor as bt\n\nmetagraph = bt.metagraph( netuid = 104, network = 'test')\nmax_uid= int(torch.argmax(metagraph.incentive))\nprint(f\"best miner uid: {max_uid}\")\n\n2) Please refer to our response to Question 3\n\n3) Here is an example python script that the foundation can use to query our testnet subnet through one of our validators:\nimport requests\nimport sys\nfrom requests.structures import CaseInsensitiveDict\nurl = \"http://35.236.58.204:9000/allocate\"\nheaders = CaseInsensitiveDict()\n# Test API key created for the foundation - ~1k max requests, 120 req/min\nheaders[\"Authorization\"] = \"Bearer abfc5664-22a4-4d45-9a75-f4401f3dcadb\"\nheaders[\"Content-Type\"] = \"application/json\"\n\n\ndata = '{ \"assets_and_pools\": { \"total_assets\": 1.0, \"pools\": { \"0\": { \"pool_id\": 0, \"base_rate\": 0.0, \"base_slope\": 0.011, \"kink_slope\": 2.014, \"optimal_util_rate\": 0.8, \"borrow_amount\": 0.032 }, \"1\": { \"pool_id\": 1, \"base_rate\": 0.01, \"base_slope\": 0.012, \"kink_slope\": 1.3, \"optimal_util_rate\": 0.8, \"borrow_amount\": 0.02 }, \"2\": { \"pool_id\": 2, \"base_rate\": 0.01, \"base_slope\": 0.015, \"kink_slope\": 0.502, \"optimal_util_rate\": 0.8, \"borrow_amount\": 0.006 }, \"3\": { \"pool_id\": 3, \"base_rate\": 0.0, \"base_slope\": 0.048, \"kink_slope\": 1.233, \"optimal_util_rate\": 0.8, \"borrow_amount\": 0.08 }, \"4\": { \"pool_id\": 4, \"base_rate\": 0.0, \"base_slope\": 0.032, \"kink_slope\": 2.506, \"optimal_util_rate\": 0.8, \"borrow_amount\": 0.006 }, \"5\": { \"pool_id\": 5, \"base_rate\": 0.01, \"base_slope\": 0.021, \"kink_slope\": 2.633, \"optimal_util_rate\": 0.8, \"borrow_amount\": 0.081 }, \"6\": { \"pool_id\": 6, \"base_rate\": 0.0, \"base_slope\": 0.032, \"kink_slope\": 2.716, \"optimal_util_rate\": 0.8, \"borrow_amount\": 0.068 }, \"7\": { \"pool_id\": 7, \"base_rate\": 0.0, \"base_slope\": 0.019, \"kink_slope\": 0.818, \"optimal_util_rate\": 0.8, \"borrow_amount\": 0.007 }, \"8\": { \"pool_id\": 8, \"base_rate\": 0.0, \"base_slope\": 0.037, \"kink_slope\": 2.934, \"optimal_util_rate\": 0.8, \"borrow_amount\": 0.023 }, \"9\": { \"pool_id\": 9, \"base_rate\": 0.01, \"base_slope\": 0.011, \"kink_slope\": 1.609, \"optimal_util_rate\": 0.8, \"borrow_amount\": 0.09 } } } }'\n\n\nresp = requests.post(url, headers=headers, data=data)\n\n\nprint(resp.status_code)\nprint(resp.json())\n\n\n# Print top miners' uid (w.r.t yield only) with their yield and allocations:\nmax_apy = sys.float_info.min\nbest_uid = None\nbest_info = None\nallocs = resp.json()[\"allocations\"]\nfor k, v in allocs.items():\n  if float(v[\"apy\"]) > max_apy:\n    max_apy = float(v[\"apy\"])\n    best_uid = k\n    best_info = v\n\n\nprint(f\"----==== Best miner uid: {best_uid} ====----\")\nprint(f\"----==== Best APY and allocations: ====----\\n{best_info}\")",
        "Applications and Collaborations:": "The Sturdy protocol (sturdy.finance) is the first application building on top of the subnet. From Day 1, the protocol will use the subnet to optimize yields on its $40,000,000 in assets. We are engaging with a number of other prospective applications that could integrate the subnet (e.g. Yearn). Our goal is to hit $1b under management by the end of the year.\n\nWe are collaborating with SN19 on their Request Layer, which will serve as the interface through which applications communicate with validators. ",
        "Development Roadmap:": "- Onboard additional applications to the subnet (goal of $100m under management by June and $1b by end of year)\n- Implement central API router so that validators do not have to communicate with applications individually\n- Develop info bridge from Bittensor <> EVM to commit allocations directly on-chain\n- Modify mechanism from scoring based on ‘Day 0’ yield to predicting yield in the future\n\nA more detailed roadmap can be found here: https://sturdyfinance.notion.site/Sturdy-Subnet-roadmap-82413fdd426c409f85034b7da0694da6",
        "Testnet Information:": "Our subnet is currently on testnet. We previously offered a competition where we gave away 2 TAO to the best performing miner and validator on the subnet. We’ve also given away TAO to users who have spent time running miners/validators and uncovered bugs or edge cases. \n\nOnce we register on mainnet, before applying any changes to our live environment, we’ll first run tests on a local dev blockchain along with unit and integration tests that are provided with the repo. Once we are satisfied with our results we’ll deploy these changes into our testnet. Over this testing period, we will receive user feedback and apply any immediate hotfixes which need to be made before deploying to mainnet. After testing, we’ll then merge the updates into the main branch and make a community announcement to prepare participants to transition to the updated version of our subnet.",
        "Demo Recording:": "https://www.loom.com/share/ae91f094897a43a7893bceb647fcc353?sid=61ae2140-99b4-4ee0-b680-728af8e12dc3",
        "Relevant Links:": "Github: https://github.com/Sturdy-Subnet/sturdy-subnet\nLanding page: sturdysubnet.org",
        "Please ensure that all responses are concise and provide the necessary information to understand the operational parameters of the subnet": null,
        "Email Address": ""
    },
    {
        "subnet": "pi-16",
        "SN Name and SN Number": "BitAds.ai - UID 120 - TESTNET",
        "Subnet Owner Discord Username": "eseck",
        "Subnet Objectives and Contributions:": "BitAds.ai - Decentralized Advertising on Bittensor\n\nRevolutionizing Online Advertising with Decentralization. Discover how BitAds leverages the Bittensor Network to offer cost-effective, high-quality advertising through a unique incentive mechanism for miners and validators.\n\n🚫The Problem:\nThe current advertising landscape, particularly as shaped by the web2 paradigm, presents significant challenges not only for the users who are subjected to ads but also for the companies that invest heavily in advertising. At the heart of these challenges are the highly centralized tech organizations that dominate and control the industry, such as Google AdSense, Facebook Audience Network, and Apple Advertising. This centralized control results in a significant power imbalance, lack of transparency, and high costs.\n\n💡The Solution:\nThe BitAds network emerges as a revolutionary solution, harnessing the power of blockchain technology to foster a decentralized and incentivised advertising environment. By reimagining the foundational principles of advertising transactions, BitAds seeks to rectify the issues of transparency, fraud, inefficiency, and the high costs associated with conventional advertising methods.\n\n🔗Usefull Links:\nSubnet Video Presentation: https://www.youtube.com/watch?v=5vJjnIrzMLk\nWhitepaper: https://bitads.ai/whitepaper\nRoadmap: https://bitads.ai/roadmap\nAPI Docs: https://bitads.ai/api\nGitHub: https://github.com/eseckft/BitAds.ai\n\nIt enhances the Bittensor network by leveraging its decentralized structure to distribute advertising tasks among miners, initially focusing on promoting the Bittensor project itself. \n\nThis approach not only aims to improve the visibility and adoption of Bittensor but also establishes a robust foundation for the future growth of both BitAds and Bittensor, making the network a powerful marketing engine.\n\nValidators create and manage advertising campaigns using the BitAds Core platform, which provides tools for creating landing pages and tracking campaign performance. Miners generate unique links for campaigns to promote across the internet. They are rewarded with TAO tokens for driving organic traffic to these links. BitAds Core acts as the central platform for campaign management, traffic analysis, and miner validation.\n\nIncentive Mechanism:\nMiners are incentivized with TAO tokens, not based on the client's payment offer, but on the organic traffic they attract. This system ensures cost-effective advertising for clients while rewarding miners substantially for their efforts.",
        "Communication Protocols:": "2.1- Which communication protocols are utilized by this subnet?\n\nPeer-to-Peer (P2P) Protocol: The subnet in the Bittensor network utilizes peer-to-peer communication for nodes to discover, connect, and exchange data directly with each other without the need for a central server.\n\nAdditionally, there's integration with a server via HTTPS for specific functions, extending the capabilities beyond pure peer-to-peer communication.\n\n2.2 - What type of data is transmitted, how frequently does this occur, and what is the typical data size?\n\nThe type of data transmitted within the subnet includes validator requests to the server, communication between validators and miners, and evaluations of miners. These transmissions occur no more frequently than once every 30 minutes.\n\nThe typical data size varies depending on the specific message or request being transmitted, but it's generally kept within a reasonable limit to ensure efficient communication and network performance.\n\n2.3 - Is there any security or encryption applied to the messages? If not, are there plans to implement such measures? Describe the methods used to secure communications.\n\nSecurity and encryption measures are indeed implemented within the subnet. All participants initially register on BitaAds, enabling the implementation of security measures when working with APIs. This registration process ensures that only authorized participants can utilize the miner or validator scripts.\n\nOn the server side, several security measures are in place:\n- Script Version Verification: The server verifies the version of the script being used by the participant, ensuring compatibility and security.\n- Key Pair Verification: The server validates the correspondence of key pairs between participants, enhancing the security of communications.\n- Access Control: Access control mechanisms are enforced to restrict access to sensitive data and functionalities based on the identity and permissions of the participant.\n- Logging and Monitoring: The server logs and monitors all incoming requests, recording details such as the requester's identity, accessed data, and actions performed. This facilitates auditing and enables quick detection of suspicious activities.\n\nThese security measures collectively ensure the integrity, confidentiality, and authenticity of communications within the subnet, mitigating potential security threats and unauthorized access.\n\n2.4 - GitHub Link Relevant to Communication Protocols\n\nhttps://github.com/eseckft/BitAds.ai/blob/main/neurons/validator.py#L175\nhttps://github.com/eseckft/BitAds.ai/blob/main/neurons/validator.py#L244\nhttps://github.com/eseckft/BitAds.ai/blob/main/helpers/request.py#L25\nhttps://github.com/eseckft/BitAds.ai/blob/main/helpers/request.py#L42\nhttps://github.com/eseckft/BitAds.ai/blob/main/helpers/request.py#L69\n",
        "Incentives Mechanism:": "3.1 - Please detail the reward mechanism for this subnet and include links to the relevant GitHub repositories.\n\nThe rewards mechanism is based on unique visits and CTR (click through rate).\n\nThe scoring formula for BitAds miners incorporates a thoughtful approach to quantifying the effectiveness and impact of miners based on two key performance indicators: Unique visits and Click-through rate (CTR).\n\nParameters and Normalization:\n\nUnique Visits (U): This measures the total number of distinct visitors directed to the campaign via the miner's unique link. It's a direct indicator of the reach and traffic generated by the miner.\n\nClick-Through Rate (CTR): Expressed as a decimal, this metric captures the efficiency of the campaign in engaging visitors. Specifically, it measures the proportion of visitors who click the \"call to action\" button and, if prompted, complete a captcha. A CTR of 5% is represented as 0.05, for example.\n\nMaximum Expected Values (Umax and CTRmax): These thresholds are set to normalize the unique visits and CTR, ensuring they're scaled to a value between 0 and 1. This normalization facilitates a fair comparison between miners, accounting for varying scales of performance. For your formula, Umax is set to 1000, and CTRmax is 0.15.\n\nNormalization is performed as follows:\n\nUnorm = U / Umax\nCTRnorm = CTR / CTRmax\n\nWeight of Parameters (Wu and Wc): \n\nThese weights reflect the relative importance of Unique visits and CTR in calculating the miner's score. By adjusting these weights, you can balance the emphasis on traffic generation versus engagement. In our model, both parameters are equally valued, with Wu = 0.5 and Wc = 0.5.\n\nScore Calculation\nThe Miner Score is computed by applying the weights to the normalized values of unique visits and CTR, as follows:\n\nMINER SCORE=(Wu⋅Unorm)+(Wc⋅CTRnorm)\n\nGiven the example of a miner with 1000 unique visitors and a CTR of 5% (0.05), and with the normalization constants provided (Umax = 1000, CTRmax = 0.15), the calculations would be:\n\nUnorm = 1000 / 1000 = 1\nCTRnorm = 0.05 / 0.15 = 0.333\n\nThus, the Miner Score would be:\n\nMINER SCORE= (0.5 x 1)+(0.5 x 0.333)=0.5+0.1665=0.6665\n\nConditions and Adjustability:\n\nThe formula caps the Miner Score at 1, ensuring scores remain within a 0 to 1 range. If the calculated score exceeds 1, it's adjusted to 1, maintaining a standardized scoring scale.\n\nBoth the maximum expected values (Umax, CTRmax) and the weights (Wu, Wc) are configurable through the admin panel of BitAds. This flexibility allows you to recalibrate the scoring model based on evolving campaign goals, performance\n\n3.2 - How are servers within your subnet incentivised? Is there a ranking system for incentives on your subnets?\n\nIn this decentralized advertising subnetwork, miners are incentivized to bring high quality traffic to the active campaigns on the BitAds platform by promoting their unique links on various social media platform (Youtube, Facebook, Instagram, Whatapp, Twitter and so on..) and even on Google/Bing/Amazon ads.\n\n3.3 - What type of data do validators use for queries? Is there a risk of data exhaustion? If not, provide examples of how data is generated or created to ensure unique validations.\n\nValidators use two types of data for queries: campaigns and analytical data (for computing and evaluating miners).\n\nCampaign Data: Validators receive campaign data during each of their queries to the API. This campaign data is then sent to miners for processing. Validators typically receive a new campaign once every 30 minutes, which they distribute to miners and process their responses.\n\nAnalytical Data: Validators also receive aggregated analytical data about miners from the previous period. This data is used to compute and evaluate miners' performance. Validators process this data and perform evaluations of miners before their next query to the API.\n\n3.4 - GitHub Link to Incentives Mechanism\n\nhttps://github.com/eseckft/BitAds.ai/blob/main/neurons/validator.py#L198",
        "Data Sources and Security:": "4.1 - What is the origin of the data used by validators? Indicate if any data augmentation processes are in place.\n\nThe data used by validators originates from the API. Validators retrieve all the necessary data from the API, process it within their scripts, and then utilize it in subsequent steps. There are no specific data augmentation processes in place beyond the processing performed within the validators' scripts.\n\nBasically, the data (advertising campaigns in our case) are coming from BitAds where they are submitted manually by the subnet owner, or through the Validator API (coming from mobile/web applications built on top of BitAds).\n\nFor example https://FirstAds.ai is the first web application built utilizing BitAds Validator API where users can come and register their own advertising campaigns and start promoting their products or services with the help of Bittensor miners.\n\n4.2 - Are there any known vulnerabilities within your subnet, such as susceptibility to lookup attacks due to limited dataset size? If so, what measures are planned to safeguard the subnet?\n\nAll known vulnerabilities within the subnet have been addressed and resolved. This was made possible thanks to the security measures implemented in the API.\n\nBitAds campaigns have multiple levels of protection against fraudulent activity such as bot or script-driven fake activity. In particular, verification for human authenticity occurs through the \"AWS Well-Architected Framework\" and CAPTCHA.\n\nAll incoming requests are forwarded to AWS WAF for inspection by the web ACL\n\nAWS WAF (Web Application Firewall) is a web security service that helps protect web applications from common web threats such as SQL injections, cross-site scripting (XSS), and cross-site request forgery (CSRF).\n\nHuman Verification Check is an additional layer of protection in AWS WAF, designed to help distinguish humans from bots. It is useful for preventing automated attacks such as DDoS attacks and spam. In BitAds architecture it is one of the levels of protection against traffic manipulation.\n\nEach time the BidAds API is accessed, validators' and miners' scripts transmit their BitTensor wallet keys for verification of their presence in the registered users' database. BidAds also checks the status of each user (whether they are active or blocked), as well as the compatibility of validators' and miners' script code versions with the current version provided by BitAds developers. This, on the one hand, requires users to constantly update their scripts and prevents unauthorized interference with them.\n\nAdditionally, every 30 minutes, there is an update of the lists of allowed participants in the process. Miners receive a list of validators, and validators receive a list of miners with whom they can communicate. This way, the system is protected from external intrusion.\n\n4.3 - GitHub link to Data Sources\n\nhttps://github.com/eseckft/BitAds.ai/blob/main/helpers/request.py",
        "Compute Requirements:": "5.1 - What are the computational prerequisites for participating in your subnet?\n\nThe computational prerequisites for participating in our subnet are not resource-intensive, and they do not involve executing complex operations. The requirements are published in the repository.\n\n5.2 - How can miners increase their rewards? Are they required to train specific models or run predetermined models?\n\nMiners can increase their rewards by registering on BitAds, launching scripts, and generating traffic for advertising campaigns. To maximize their rewards, miners should aim to generate as much high-quality traffic as possible. \n\nThis traffic is aggregated, and every 30 minutes it is computed using a special formula, which determines the miner's evaluation. There is no requirement for miners to train specific models or run predetermined models; their rewards are primarily based on the quantity and quality of the traffic they generate.\n\n5.3 - Is there any public interface or user interaction with the subnet? If not currently available, are there plans to develop one?\n\nThe functionality that miners and validators may require for interacting with the subnet is available on BitAds.ai.\n\nUsers (paid customers) can use FirstAds (https://firstads.ai) to create their own advertising campaign and start promoting their products/services directly there with just a few clicks.\n\n5.4 - Are there any significant updates scheduled for the subnet? Please provide details if available.\n\nWe plan to implement the following updates in the following weeks/months:\n\n- Template and Design Expansion: Add more templates, colors, and layouts to BitAds landing pages.\n- Device Targeting: Implement device targeting feature to specify desired traffic source.\n- Performance Analytics: Implement daily performance analytics for validators to enhance campaign monitoring.\n- Geo-Location: Implement geo-location filtering to enable validators and clients to specify desired traffic origins in BitAds.\n- Campaign Information Bot: Launch an interactive discord/telegram bot to provide miners with immediate access to campaign information and notifications.\n- Traffic Source Analysis: Implement traffic source analysis to precisely track visitor origins.\n- Domain Selection Expansion: Expand landing page domains to enable validators and clients to select from a wider range of options.\n- Conversion Tracking: Integrate conversion tracking in order to measure conversion rates on client websites.\n\nOur roadmap is available here: https://bitads.ai/roadmap",
        "Notebook and Code:": "As a Validator, you can use the BitAds Dashboard to view all the traffic statistics for each active miner in the subnet. This feature allows you to quickly check each miner's stats and examine the quality of their traffic, which is organized by advertising campaign. \n\nThis way, you can see how effectively each miner is promoting the campaigns and assess the value of the traffic they're generating.",
        "Applications and Collaborations:": "7.1 - Have any applications been developed on top of your subnet? While not mandatory, this information is beneficial.\n\nThe first application developed on the BitAds subnet is FirstAds. This platform enables users to create and promote their campaigns, incentivizing BitAds miners to generate organic traffic for these campaigns at a minimal cost.\nhttps://firstads.ai\n\n7.2 - Is there any ongoing collaboration with other subnets? This is also not a requirement but is valuable information.\n\nNot at the moment. We could use the Bittensor Scraping Subnets in order to find the BitAds (x.bitads.ai) campaigns posted on different social media (e.g. Twitter).\n",
        "Development Roadmap:": "We plan to implement the following updates in the following weeks/months:\n\n- Template and Design Expansion: Add more templates, colors, and layouts to BitAds landing pages.\n- Device Targeting: Implement device targeting feature to specify desired traffic source.\n- Performance Analytics: Implement daily performance analytics for validators to enhance campaign monitoring.\n- Geo-Location: Implement geo-location filtering to enable validators and clients to specify desired traffic origins in BitAds.\n- Campaign Information Bot: Launch an interactive discord/telegram bot to provide miners with immediate access to campaign information and notifications.\n- Traffic Source Analysis: Implement traffic source analysis to precisely track visitor origins.\n- Domain Selection Expansion: Expand landing page domains to enable validators and clients to select from a wider range of options.\n- Conversion Tracking: Integrate conversion tracking in order to measure conversion rates on client websites.\n\nOur roadmap is available on our website: https://bitads.ai/roadmap",
        "Testnet Information:": "BitAds.ai is currently registered on TESTNET (UID 120). Miners and Validators can easily test our subnet functionality there.\nWe're using the TESTNET environment to test things out before pushing it to main repository.",
        "Demo Recording:": "https://www.youtube.com/watch?v=5vJjnIrzMLk",
        "Relevant Links:": "Subnet Video Presentation: https://www.youtube.com/watch?v=5vJjnIrzMLk\nWhitepaper: https://bitads.ai/whitepaper\nRoadmap: https://bitads.ai/roadmap\nAPI Docs: https://bitads.ai/api\nGitHub: https://github.com/eseckft/BitAds.ai\n\nhttps://bitads.ai – The core of the subnet where all the Validators and Miners must register in order to have access to the BitAds API. Here is the place where all the advertising campaign are and where all the traffic data is recorded and stored.\n\nhttps://x.bitads.ai/lty9sdtvcg55s - The first BitAds campaign promoting Bittensor.\n\nThe first campaign \"Join the Bittensor Revolution where AI meets the Decentralization\" on the BitAds Network will be BittensorWiki, a platform where you can find everything you need to know about the Bittensor Network.\nIn fact, this campaign will serve as a powerful marketing tool for the Bittensor Network, as miners will be incentivized to generate organic traffic for the BittensorWiki campaign.\nhttps://bittensorwiki.com\n",
        "Please ensure that all responses are concise and provide the necessary information to understand the operational parameters of the subnet": null,
        "Email Address": ""
    },
    {
        "subnet": "eta-7",
        "SN Name and SN Number": "Mainnet UID 7 | Testnet UID 92",
        "Subnet Owner Discord Username": "ch3rnobog",
        "Subnet Objectives and Contributions:": "SubVortex enriches the Bittensor ecosystem by providing an alternative to the Finney network and promoting decentralization, reliability, and efficiency. It offers miners and validators a seamless experience with low barriers to entry and continuous support. We thrive to create a high performing network of subtensor nodes to provide miners and validators an alternative to running on the Finney network or having to setup/operate their own subtensor nodes. By scoring the subtensor nodes and creating competition between them, the network will continually improve and the reliability of running on the SubVortex network of nodes will reduce downtime risk across the network.\n\nThere are currently no other subnets that are competitors or trying to build a similar subnet making SubVortex unique within the Bittensor ecosystem.\n\nThe SubVortex team is creating a network of subtensors that is geographically diverse because of the incentive mechanism. The subtensors are added to our load balancer so when it's used to run any commands i.e. btcli s list --subtensor.network REDACTED, the host connects to the optimal subtensor based on the requestors IP location. This results in faster response times and ensures the host isn't relying on a single local subtensor or Finney. Once we are done building the production load balancer and make it publicly accessible our scripts will keep it updated with the best performing subtensors that are operating \"mining\" within subnet 7. This will create a geographically decentralized network of subtensors that our miners are incentivized to keep running with optimal internet speeds, hardware specs, uptime etc. As more miners/validators start to use the load balancer we will start to see a significant reduction in the network load on Finney. It is our belief that we are building the type of infrastructure that will assist Bittensor scale the number of subnets. Basically, using it will create a redundant connection to the network using the optimal subtensor based on things like your location. This will improve response time, reduce load on Finney, and balance network traffic across all available subtensors etc.",
        "Communication Protocols:": "The subnet utilizes two protocols:\n\n- IsAlive – used to verify the availability of the miner. It's a request sent by the validator to ensure the miner is active and reachable.\n\n- Score – used to grant miners access to detailed scoring information. It's an informative request aimed at assisting miners in understanding their current emission status.\n\nThe validator transmits the following data to the miner:\n\n- UID of the validator that evaluated the miner\n\n- Availability score received by the miner from that validator\n\n- Latency score received by the miner from that validator\n\n- Reliability score received by the miner from that validator\n\n- Distribution score received by the miner from that validator\n\n- Final score received by the miner from that validator\n\nThis information is sent through the synapse Score, at every step of an epoch. The size of the score is few kilobytes.\n\nThese messages are informative notifications to ensure miners have configured their setups correctly. Additionally, the content of these messages is solely focused on scoring-related information, containing no confidential data.\n\nThe protocol can be found in the protocols.py file in the SubVortex repository https://github.com/eclipsevortex/SubVortex/blob/main/subnet/protocol.py",
        "Incentives Mechanism:": "SubVortex's incentive mechanism will score miners based on multiple criteria of their subtensor node:\n\n· 50%: Availability - Subtensor nodes must be reliable to ensure good uptime.\n\n· 16.67%: Latency - Subtensor nodes must be efficient to ensure good performance.\n\n· 16.67%: Reliability and Stability - Subtensor nodes must be efficient to ensure good service quality.\n\n· 16.67% Global distribution - Subtensor nodes must be worldwide to ensure a good reach.\n\nThe final score used to set the weight is an average of all these scores and will replace 20% of the weight of the previous weights. This is the current scoring metric, but as we introduce load balancers scoring system will be updated accordingly to reflect network needs.\n\nAvailability\n\nThis reward incentivizes miners to maintain high levels of uptime and accessibility.\n\nTo assign a score for each miner, we establish a connection with the subtensor and retrieve the current block. The score will be determined by the success of getting that block. Miners receive\n\na 1 or 0 for their availability and the score is independent of other miners. When a miner receives a 0 for availability, their latency and distribution scores will also be zero.\n\nLatency\n\nThis reward incentivizes miners to have low-latency services and minimize response times. To assign a score to each miner, we first establish a connection with the miner’s locally running subtensor and retrieve the current block. The score is determined by the amount of time taken to process that request, using a normalized method as part of the reward system.\n\nThe validator can be in a different country than the miner, so we incorporate a distance-based weighting factor into the scoring formula using the haversine formula.\n\nValidators take a random sample of 10 miners and measures their latency. The sample ensures every miner is measured before repeating previously measured miners. Miners are compared to the latency of all the other miners and given a score relative to those. The best latency receives a score of 1, the worst receives 0 and all the miners in between receive a score relative to their position using a linear distribution.\n\nReliability and Stability\n\nThis reward incentivizes miners to have high levels of reliability and minimize the occurrence and impact of failures. To assign a score to each miner, we will establish a connection with the subtensor and retrieve the current block. The score is determined by computing the ratio of successes/attempts, using a normalized method and the Wilson formula as part of the reward system.\n\nGlobal Distribution\n\nThis reward incentivizes miners to distribute subtensors across different geographical locations to optimize performance and reduce latency in all parts of the world. This increases the decentralization of the network.\n\nFor countries with 1 subtensor in them, the miner receives a score of 1. For countries with multiple subtensors in the same country, the miner receives a score of 1/n where n is the number of subtensors in that country. The distribution score considers all miners that have been validated at least once and have an availability score of 1.",
        "Data Sources and Security:": "SubVortex implements a security-focused challenge mechanism for validating the performance and integrity of miners (subtensor nodes) within the network:\n\n· Dynamic Data Validation: We retrieve real-time data from miners, including the current block from their local subtensor, and compare it to the validator's data to ensure consistency and integrity.\n\n· IP and Geolocation Checks: We obtain the IP address of each miner and use a geolocation API to determine the country of origin, which could be used for regional compliance or to detect anomalous activity.\n\n· Performance Metrics: We measure the latency of responses from miners and calculates various performance scores, such as availability, latency, reliability, and distribution. These metrics are crucial for assessing the health and trustworthiness of the network.\n\n· Reward System: Miners are rewarded based on their performance scores, with a weighted average that considers different aspects of their contributions. This incentivizes good behavior and penalizes poor or malicious activity.\n\n· One Miner Per IP Enforcement: We enforce a policy where only one miner per public IP is allowed, which is a security measure to prevent sybil attacks and ensure fair distribution of rewards.\n\n*Note - A Sybil attack is a type of attack on a network or service in which an attacker subverts the service's reputation system by creating many pseudonymous identities and using them to gain a disproportionately large influence or in this case having multiple miners using the same subtensor node to unfairly earn more rewards.\n\n· Penalty for Violations: If more than one miner is detected on the same IP, the code penalizes all miners associated with that IP, which deters attempts to game the system.\n\n· Event Logging: All events and scores are logged, providing an audit trail that can be used for monitoring and forensic analysis in case of security incidents.\n\n· Asynchronous Execution: The use of asynchronous tasks allows for concurrent processing of multiple miners, improving the efficiency of the challenge and reducing the potential for bottlenecks.\n\n· Integration with External Tools: The code integrates with wandb (Weights & Biases) for tracking experiments, which could be used for monitoring and analyzing the performance and security of the network over time.\n\nOverall, the subnet's code has been designed to ensure the security and reliability of the Bittensor network by validating miner data, enforcing rules, and maintaining a transparent and fair reward system.\n\nTo date, our security assessments have not discovered any critical vulnerabilities within the system. However, we acknowledge the persistent threat posed by adversaries who may endeavor to bypass our security protocols, particularly those designed to prevent the operation of multiple miners from a single subtensor node. Our dedication to maintaining a secure environment remains steadfast. We are continuously enhancing our monitoring and detection capabilities to proactively identify and neutralize any malicious efforts aimed at exploiting the in-place challenge and reward mechanisms.",
        "Compute Requirements:": "Compute requirements for the subnet are low and require no GPU. The miner's main function is to run a local lite subtensor node which does not require much compute. 4 vCPU and 8GB of memory is generally sufficient. Validators will need to perform more computational work relating to challenge scores, but similar specifications to miners will suffice. Higher spec VPS will however, help produce better score in the latency aspect of incentive calculations.\n\nMiners can increase their rewards by setting up their subtensor in a country with less subtensors or where there are none yet. This will result in a higher distribution score. Miners can also ensure they have the lowest latency possible. As we continue to gather data from our back end, we will be evaluating the incentive mechanism and adjusting or adding new criteria with the goals of increased decentralization and performance as the key drivers.",
        "Notebook and Code:": "We created a temporary UI on wandb for our miners to have the information they need to make decisions to improve their performance.\n\nThe wandb UI can be found at https://wandb.ai/eclipsevortext/subvortex-team?nw=nwusereclipsevortext and the sections containing different metrics.\n\n- Miners– a table listing all the miners with the UID, version, country and the different scores (final, availability, reliability, latency and distribution).\n\n- Distribution– a histogram listing all the countries with the number of subtensor associated.\n\n- Overview – the best UID and the time for the validator to process a step.\n\n- Scores –one graph per score/per miner such as reliability score, availability score, latency score, distribution score, final score and moving average score.\n\n- Miscellaneous – one graph per miner to show the time the subtensor took to return the current block the validator.\n\nAll the source code for these metrics can be found in the file https://github.com/eclipsevortex/SubVortex/blob/main/subnet/validator/state.py in the method log event in the repository.",
        "Applications and Collaborations:": "While this subnets success is not heavily reliant on front-facing applications, it can be used by any miners and validators within their daily Bittensor operations. The application of this subnet is to build on the infrastructure of the network and support the expansion and heavy loads of traffic that will continue to increase as more subnets are added. Our load balancer will be able to be used in any miner or validator start command.\n\nWe have built a wandb dashboard to allow miners and validators to see the subtensor statistics to help optimize their miners and understand what is causing them to increase or decrease in incentive over time. We plan to build a front-end website with similar data plus more features and a more user-friendly and aesthetically pleasing user interface.\n\nWe have been contacted by subnets 15, 12, 31, and 32 about potential collaborations, but further details have not been explored yet.",
        "Development Roadmap:": "Our first goal is to get as many miners/subtensors registered on our subnet as quickly as possible to have the initial network of subtensor nodes setup and running. With low hardware requirements, we are attracting new users to the network and potentially increase global adoption. Lowering the barrier to entry will bring more people to the Bittensor network, many of which are highly intelligent and have the aptitude to bring lots of value to the network but have not had the exposure to mining.\n\nAs of this writing, we have miners/subtensors in 39 different countries showing significant decentralization across geological regions. We have built a load balancer that can be used to serve other subnets or individual miners once announced publicly. The initial design is a global load balancer with geolocated round-robin routing policy. As we refine our miner scoring mechanism, we'll leverage statistics from the load balancer to see which region (US, CA, GB, FR, etc..) has the most traffic and put more weight in those geographical regions to encourage more subtensor concentration in those areas. The overall reliability and latency score of the miners from validator will then also be used to adjust weights within each regional zone to allow it to carry more network load. Conversely, if the reliability or latency score starts to decrease due to the node being overwhelmed, its weight on the load balancer will be decreased. The overall weights distribution can then be fed back to the validator to adjust the overall\n\ndistribution score. This will ensure that machines that handle increased loads will have better incentive and promote stronger subtensor nodes to be maintained to best serve the overall network.\n\nTo prevent single point of failure, we ensure the global load balancer entry is available on several namespace servers spread across the globe. Each regional zones will have several subtensor nodes to ensure availability. Appropriate monitoring will be in place to alert the team when the load balancer is not responding properly, and if required the team can also separately bring up additional subtensor nodes to augment capacity or improve overall availability.\n\nWe plan on publishing a public dashboard to help the community understand how well their subtensor is performing and how distributed they are globally. Lots of these stats are already displayed on our wandb initial dashboard, but in the future, we will build a customized website with significantly better UI than what is available on wandb.\n\nWe also plan to have the subnet running archive nodes and we will create split rewards between miners running archive nodes or lite nodes. We will explore potential opportunities to collaborate with other subnets for running archive nodes. Some possibilities include using subnet 21 to store the archive node files or working with subnet 15 that currently requires miners to run bitcoin nodes.",
        "Testnet Information:": "We spent significant time developing in testnet (UID 92) as we only wanted to go live on mainnet once we were confident that our subnet was functioning as desired, and we closed any potential exploits. We thoroughly tested several areas of the subnet including:\n\n· How can we accurately and fairly measure the performance of the machine running the subtensor nodes\n\n· How can we ensure a miner is not simply referencing a remote subtensor node as their own\n\n· Eliminate the ability to run multiple miners on the same physical servers (referencing the same subtensor node).\n\n· Simplifying/automating the setup process to make it as user-friendly as possible. We understand some of the users who are just starting with TAO mining may not be technically savvy and want to make the overall experience as smooth as possible.\n\nAll updates/changes are thoroughly tested multiple times and documentations are updated before promoting to mainnet. The team tries to make themselves as available to provide support to the community as much as possible.\n\nIf there are significant updates that materially change aspects of the subnet such as the scoring mechanism, we will pause key registrations temporarily to allow miners adequate time to make appropriate changes. One future update that will potentially require this is if we add different emission weights to different regions for the global distribution score. We would allow miners to enough time to change their locations without having a high risk of being de-registered.",
        "Demo Recording:": "https://www.loom.com/share/feba3420544540738e31ffe8de645e0e?sid=ce9466a3-13ea-4aef-b62e-86ab26a54b05",
        "Relevant Links:": "SubVortex git hub repo https://github.com/eclipsevortex/SubVortex\n\nWandb initial dashboard with validator and miner data. https://wandb.ai/eclipsevortext/subvortex-team?nw=nwusereclipsevortext\n\nSubVortex Load Balancer https://docs.google.com/document/d/1jvutbvzidqHBKrY1gwUz_dY2g3A-MUzCC0bwD1-r-Bs/edit\n\nSubVortex Future Load Balancer design. https://docs.google.com/document/d/1OSAcEjHoGsrEQ85ofImtsWoVlkdFSXXD/edit\n\nSubVortex Official twitter account https://twitter.com/SubVortexTao\n\nThis video was not created by the SubVortex team, but it was created by a community member and is a great marketing video. https://www.youtube.com/watch?v=pPry9eJpLXY",
        "Please ensure that all responses are concise and provide the necessary information to understand the operational parameters of the subnet": "The SubVortex team is steadfast in its dedication to enhancing the Bittensor ecosystem. Our efforts are focused on establishing a paradigm of excellence for subnets within the community. Drawing from our foundational experience as miners, we empathize with the challenges faced by our peers and have diligently crafted a platform that reflects our commitment to quality.\n\nWe take pride in providing meticulously crafted documentation and streamlined scripts that facilitate a seamless setup process for miners. Our four-person team is unwavering in its commitment, offering daily support to both miners and validators to ensure their success.\n\nOur vision is long-term, and we are resolute in our mission to contribute to the growth and scalability of Bittensor. We are not merely participants in this ecosystem; we are active builders, invested in the collective progress and the future it holds.",
        "Email Address": ""
    },
    {
        "subnet": "upsilon-20",
        "SN Name and SN Number": "BitAgent SN20 TN76",
        "Subnet Owner Discord Username": "FrankRizzo RogueTensor",
        "Subnet Objectives and Contributions:": "Primary purpose - LLM-driven tool execution for automation, see more in our WIP doc - https://docs.google.com/document/d/1QVCzDu0eMmkdglD65F_Q_UjnCJauVEr62WgG8SgACt0/edit?usp=sharing \n \nEnhancement to BT - provide LLM-driven automation capabilities to downstream businesses and consumers, bringing attention to Bittensor, see example of this on our downstream business website for MSPs (IT support companies) - https://msptech.ai/ \nAs far as core capabilities - the generated tasks are designed to ensure with reasonable expectation that the miners are able to do a few key tasks well -\nTraditional QnA with citations for potential human verification - respond with reasoned semantic-based input to queries (in the form of (a) naked LLM flows, (b) RAG-enhanced context stuffing LLM flows (i.e., from a corpora of text, leverage relevant content) and (c) serper query (i.e., google) RAG flows).\nTool use - leverage tools (this is where BitAgent gets its name) to infer logically about a query.  Examples of tools at this level are sandboxed python code interpreters, plot libraries, and handcrafted primitive skills that we've built into our broad API offering.\nAutonomous operation of customer tools and APIs - this is the final tier where BitAgent is going - we expect our miners to handle function calling / tool use (i.e., provided in the prompt context is a list of tools and a format for operating those tools). The miner LLM essentially makes function calls or function plans with parameters it deems relevant.  This allows the downstream user to provide API calls or in-house functions for the LLM to operate on.\n",
        "Communication Protocols:": " - Which communication protocols are utilized by this subnet?\n2 protocols - QnATask and QnAResult\nQnATask protocol - for tasking\nInput into the protocol is provided from a validator to miners as a “prompt” and “datas”.\nThe “prompt” is a string and “datas” is a list of dicts of {source: content, …}.\nThe “source” is a string representing the reference citation of the associated “content”.\nThe response from the miner to the validator is noted as “response”.  This is a dict containing “response” and the “citations”.  “response” is text.  “citations” contains {source: content, …} that was most relevant from the provided “datas”.\nQnAResult - for result transparency to the miner\nAdditionally, we have a results protocol (QnAResult) that is not meant to be responded to, it’s just to relay feedback to the miner to provide criteria evaluated along with scores related to their response so the miner can improve with transparent direction.\n   - What type of data is transmitted, how frequently does this occur, and what is the typical data size?\nType: Text data is being generated (validator), transmitted (validator and miner) and received (miner and validator).\nFrequency: Miners receive a generated task every 5-10 seconds. In addition to generated tasks, organic tasks flow in via on-demand queries with the highest priority, allowing them to be processed quickly.   \nData size: The text data ranges in size from 4KB to 300KB.  This is dependent on the amount of source corpora being sent back and forth.\n   - Is there any security or encryption applied to the messages? If not, are there plans to implement such measures? Describe the methods used to secure communications.\nMessages are processed through Bittensor’s Dendrite protocol which implements message signing using hashes, this helps ensure data integrity. \nOrganic traffic flows in through HTTPS.  One potential risk we inform downstream customers of is that their information is being sent to validators and miners (operators of the infrastructure) and can be viewed by those systems and their operators.\nOur tasking API only allows the IPs from registered and v-permitted validators from sn20.\nMiners blacklist any requests that are not from those validators (registered and v-permitted).\n   - GitHub Link Relevant to Communication Protocols\nDendrite Protocol - https://github.com/opentensor/bittensor/blob/0759f6a584a05e0d1dcbbf2baf54ae80b36e26cb/bittensor/dendrite.py#L674\nthe QnATask protocol - https://github.com/RogueTensor/bitagent_subnet/blob/main/bitagent/protocol.py\n ",
        "Incentives Mechanism:": "  - Please detail the reward mechanism for this subnet and include links to the relevant GitHub repositories.\n\nRewards are distributed proportional to the miners’ abilities to perform well on generated tasking.  The tasks are randomly generated along with ground truth and the evaluation is automated. Every new task is unique. All of the tasks and criteria used to evaluate the miners are provided to the community in our main git repo for transparency.\nWe are focused on core tasks mentioned earlier and the evaluation thereof.\nThe core tasks being evaluated are:\nQ&A with Citations\nRandom selections of corpora are provided as content for RAG implementations\nFrom the corpora, a single source & content is selected as the true source\nThe corpora contains 10s to 100s of context chunks, determined at random\nThe question prompt is derived from that selected source content\nEvaluation criteria:\nMust not error and must meet protocol\nMust respond quickly (often less than 10 seconds) \nMust pass back relevant citation for the true source content\nMust respond to the question prompt with a relevant answer determined by:\nAnswer must be relevant to prompt and relevant to content\nAnswer must match above 50% to mistral-based ground truth\nAnswer must pass a cosine similarity assessment given content and prompt and variations thereof\nhttps://github.com/RogueTensor/bitagent_subnet/blob/main/bitagent/task_api/tasks/generated_qna_task.py - QnA Task\nhttps://github.com/RogueTensor/bitagent_subnet/blob/main/bitagent/task_api/criteria/qna_criteria.py - QnA Critieria\nhttps://github.com/RogueTensor/bitagent_subnet/blob/main/bitagent/task_api/criteria/default_criteria.py - Default Criteria\nSummarization\nThe summary task is generated in 2 ways -\nHalf the time, through random selections of data + summary ground truths fetched from a couple hugging face datasets.  Then the data (text to be summarized) is processed through an LLM to be rewritten to avoid any lookup attacks or data exhaustion.   \nAdditionally, the other half the time, the summary task is LLM-generated data + summary ground truths (from LLM for results to be compared to) and provided for summarization.  \nThe question prompt is the data needing summarized\nEvaluation criteria:\nMust not error and must meet protocol\nMust respond quickly (often less than 6 seconds) \nMust respond to the question prompt with a relevant answer determined by:\nAnswer must match above 50% to mistral-based ground truth\nAnswer must match above 50% to hugging face ground truth\nAnswer must pass a set of cosine similarity assessments for relevance\nhttps://github.com/RogueTensor/bitagent_subnet/blob/main/bitagent/task_api/tasks/summary_task.py - Summary Task\nhttps://github.com/RogueTensor/bitagent_subnet/blob/main/bitagent/task_api/criteria/summary_criteria.py - Summary Criteria \nhttps://github.com/RogueTensor/bitagent_subnet/blob/main/bitagent/task_api/criteria/default_criteria.py - Default Criteria\nLogic-based Q&A\nRandom logic-based challenges are generated with known ground truths (number selection).  The one that we are hardening and sending out to miners is the Pet Tricks task.  The Pet Tricks task is taking a known set of pet tricks (e.g., roll over, lie down) and accompanying descriptions.  Then an LLM is used to create a relatively ambiguous and clever representation of a randomly selected trick to make it difficult for cosine similarity to detect the trick ID, but would be easier for an LLM to infer. \nThe question prompt is the list of tricks and descriptions along with the ambiguous representation of the selected trick.\nEvaluation criteria:\nMust not error and must meet protocol\nMust respond quickly (often less than 5 seconds) \nMust respond to the question prompt with a relevant answer determined by ground truth\nhttps://github.com/RogueTensor/bitagent_subnet/blob/main/bitagent/task_api/tasks/generated_logic_qna_task.py - QnA Logic Task - look for Pet Tricks as the currently only active task\nhttps://github.com/RogueTensor/bitagent_subnet/blob/main/bitagent/task_api/criteria/qna_logic_criteria.py - QnA Logic Criteria\nhttps://github.com/RogueTensor/bitagent_subnet/blob/main/bitagent/task_api/criteria/default_criteria.py - Default Criteria\nTool execution (WIP)\nTBD\nThe subnet repo - https://github.com/RogueTensor/bitagent_subnet/tree/main\n   - How are servers within your subnet incentivised? Is there a ranking system for incentives on your subnets?\nMiners are incentivized to outperform on the tasks compared to other miners, this instills a competition within the subnet.  Ranking within the system is based on how well the miner performs on the tasks as a collective across many validators.\nOur subnet is the only or one of few subnets to send back exact scoring as a result to miners with criteria scoring so they can improve with transparent feedback - see above on QnAResult\nWe also offer access to a centralized wandb instance that shows every task and miner response on the subnet - showing a ton of data points for everyone’s perusal \n   - What type of data do validators use for queries? Is there a risk of data exhaustion? If not, provide examples of how data is generated or created to ensure unique validations.\n  - GitHub Link to Incentives Mechanism\n\nType: Text data either generated by LLM or Faker or Hugging Face\nRisk of exhaustion: No, we use an LLM to rewrite any datasets we pull in with enough randomness during task generation to have new tasks forever with LLMs set to high enough or random temperatures\nhttps://github.com/RogueTensor/bitagent_subnet/blob/db41cc51159ca7f79431f5a9b31ff23c663fe9c8/bitagent/task_api/tasks/task.py#L155 - Task Generator\n",
        "Data Sources and Security:": "- What is the origin of the data used by validators? Indicate if any data augmentation processes are in place.\nData generated by LLM and/or fetched from Faker and Hugging Face (and passed through an LLM for rewrite) is used in some cases as input to LLMs to generate unique queries based on interesting data.  All other questions are generated using the Task Generator (where an LLM generates the tasks or rewrite of faker/huggingface data) - https://github.com/RogueTensor/bitagent_subnet/blob/db41cc51159ca7f79431f5a9b31ff23c663fe9c8/bitagent/task_api/tasks/task.py#L155 \n   - Are there any known vulnerabilities within your subnet, such as susceptibility to lookup attacks due to limited dataset size? If so, what measures are planned to safeguard the subnet?\n\nKnown and corrected vulnerabilities - \nValidator Axon lookup attack - validator axons on the subnet are open for downstream application use.  This means a miner could forward their requests to the validators on the subnet to have them processed by the top miners on the subnet.  We block all  miner hotkeys from accessing validator axons.\nWandb Lookup Attack - if the miner was willing to take a hit on speed, they could look for posted wandb updates, there is now a stricter timeout to prevent the effort from being optimal.  We’re also considering queueing the wandb logging and delaying the write.\nSummary task lookup attack - the datasets we use from hugging face are limited.  Everything is fed through an LLM for rewrite to increase uniqueness and less alignment to the original data source.\nSome of our logic tasks were easy to hardcode against - we have removed those until they can be used without encouraging overfitting\nPrompt injection - Some of the past criteria used LLMs to evaluate, this opened us up to LLM prompt injection attacks - we have removed the reliance on LLMs for evaluating criteria.  Focus is now on relevance and context matching.\n0.0.0.0 IPs were getting free incentive b/c no validators were checking them b/c they were “not serving” - we changed to task anyone earning incentive.\n\n  - GitHub link to Data Sources\nhttps://github.com/RogueTensor/bitagent_subnet/blob/main/bitagent/task_api/dataset.py ",
        "Compute Requirements:": " - What are the computational prerequisites for participating in your subnet?\nValidators may choose to host a Task API of their own which will require GPU, we recommend at least a 3090 with 24GB VRAM.  Alternatively, Validators may leverage a hosted Task API, at which point it only requires CPU processing, some minimal RAM and minimal storage.\nMiners on the other hand require the use of LLMs and embedders which work best with GPU.\nOur min compute yaml is up-to-date - https://github.com/RogueTensor/bitagent_subnet/blob/main/min_compute.yml \n   - How can miners increase their rewards? Are they required to train specific models or run predetermined models?\nMiners can train models or use foundation models natively or with fine tunes of their choice.  Additionally, miners can prompt engineer better tool handling workflows and system level prompts to perform better than the other miners. They can also improve their embedding speeds, LLMs speeds and RAG workflows.  It’s truly a subnet for AI engineers and potentially researchers who want to test new models.  We reward accuracy and speed.\n   - Is there any public interface or user interaction with the subnet? If not currently available, are there plans to develop one?\nYes - all legit validators have an open, served axon to allow downstream applications the ability to use the subnet.  They use the same QnATask protocol and the task will be farmed to top miners and a response will be fed back.  Examples in the works:\ndownstream customer interactions for MSP Tech (https://MSPTech.ai) \nchat interfaces through slack, discord, twitch and telegram as examples for ways to leverage the subnet\na browser plugin as a fun example\na terminal script\nSee notebook in other question for example usage\n   - Are there any significant updates scheduled for the subnet? Please provide details if available.\nBusiness partnerships - we just announced a partnership with 3 MSPs to integrate bitagent/subnet20 into their workflows.  We’re furthest along with Technology Solutions where we have integrated with their ticketing systems and their internal slack chat. \nOrganic Traffic - as described in a previous question, we now offer access to the validators through an open axon that will feed priority traffic to the miners.  This is for quick response needs like chat and user-facing applications.\nWe just released a Task API (opensource, hosted and local, as preferred by the validators) that has a ton of benefits -\nWith this push, we are able to add on demand organic traffic into the subnet queue (example - slower need, organic items like a ticket note update (see press release) will be pushed to a queue for later handling, having lower priority than the on-demand validator-axon requests.\nOrganic tasks flow through the Task API and Validators will fetch organic requests from the Task API endpoint\nTo keep things simple for the Validators, they will fetch/evaluate generated tasks from/through the same API endpoint they use for organic traffic\nThe Task API will serve organic tasks when available and generated tasks when organic tasks are unavailable \nValidators will no longer require a GPU to run LLMs on their own unless they would like to host their own Task API\nValidators also no longer need to fetch HuggingFace data\nOnly registered validators, with set IPs on the subnet, have access to the Task API endpoint \nValidators will require less updates - this allows newly generated tasks and task types to be added without requiring the Validators to update anything unless they host\nThe Task API code (including tasks and criteria, as before) will remain in the main public repo for this subnet\nNew tasks - we’ll be releasing tool-based autonomy tasks soon.\n",
        "Notebook and Code:": "This notebook contains the aforementioned demonstrations - https://github.com/RogueTensor/bitagent_subnet/blob/main/docs/OTF-example.rt.ipynb ",
        "Applications and Collaborations:": "- Have any applications been developed on top of your subnet? While not mandatory, this information is beneficial.\nPiecing the core capabilities of BitAgent (noted above) together and we have our first business facing product - MSPTech.ai (http://msptech.ai) on subnet 20 with the following capabilities serving the IT sector\n\"Help Desk Ticket Assistance\" Tier 0 - Tier 1 level triage interaction (IT speak for help desk level folks) - MSPTech.ai performs 2 key tasks at those levels -\nSupport ticket updating with troubleshooting information for higher tier support operators to quickly reference (using the LLM to provide troubleshooting information with verifiable citations gained from the MSP's knowledge base (RAG) and serper queries) - this allows a typical team of 10 tier 0/1 techs per client to be reduced to 3 tier 0/1 level support techs\nSupport ticket updating with questions to ask the customer (the one that submitted the inquiry) - this further enables the higher level tier support with a quick glance at the types of information that may be missing - saving countless hours of support staff querying\n\"Internal Chatbot\" - similar to the discord, telegram and twitch bots we have built on top of subnet 20 and demonstrated already, we also have slack and teams bots that most MSPs tend to leverage at the corporate level - this is where their teams of staff talk and interact on a day-to-day basis in the ever-increasing remote world. BitAgent is integrated into the MSP's internal chats to provide conversational QnA, among many other things to help the support staff on-demand with tickets they are working (this leverages relevant chat history + knowledge base + serper queries to provide responses with citations).\n\"Proactive Triage\" - this is IT speak for ticket routing. BitAgent is able to infer from the knowledge base of what groups/teams work on what types of tickets to automatically route tickets to the teams they need to go to for much faster customer support\n\"Whitelisted Tool Execution\" - not promised yet, but is a WIP - as mentioned above - our miner LLMs are being tasked to determine the best \"tool\" / \"function\" to call upon to provide automation.  In the IT world the whitelisted (i.e., tools with low risk of negative impact) tools may be the ability to add or remove a user to/from an access group, or to restart a network router, or to email questions to the customer for more information, or ANY number of custom integrations with in-house APIs the MSP has access to and would like automation built upon.\n\nThis is just the beginning of where we are headed.  Our next sector where interest has been expressed from people in our networks is the insurance world - where you can see a direct correlation between IT tickets and claims tickets.\n\n\n   - Is there any ongoing collaboration with other subnets? This is also not a requirement but is valuable information.\nThere are currently no collaborations but we do plan on partnering with others.\nPotential Partnerships\nSN03 (Scraping) - replace hugging face datasets\nSN12 (Horde) and (SN27) Compute for compute recommendations for miners\nSN17 (Flavia) for larger scale LLM inferencing\nSN18 (Cortex.t) for Q&A data instead of HF\n",
        "Development Roadmap:": "See most up-to-date Technical Roadmap in our shared bitagent sn20 doc - https://docs.google.com/document/d/1QVCzDu0eMmkdglD65F_Q_UjnCJauVEr62WgG8SgACt0/edit ",
        "Testnet Information:": "- Did your subnet participate on testnet? Describe the scope and participation of your subnet on the testnet.\nYes, we operate TN76 where we and a few others (not known to us) host a validator and task API. There are a handful of validators and 60+ miners at last count on our testnet.  Just like for mainnet, we publish the results to wandb to allow for us and the miners who are testing to view the results and potentially discover improvements to explore, or exploits / vulnerabilities we need to address. \n   - Provide information on how updates from the testnet were managed and transitioned into the live environment.\nOur validator hosts the latest code and before pushing changes to mainnet we host it on the testnet for at least a week to allow miners to adapt for the upcoming mainnet release. When the new code is pushed most validators get auto-updated via a script they have to monitor the version of new git repo pushes. \n\t\nWith the new task api, validators will not require updates as frequently which will increase uptime and allow for tasks to be updated on a more regular basis. \n",
        "Demo Recording:": "https://www.loom.com/share/95d3d8319614403383abface0d70f119 \nThis video shows an IT support specialist asking questions to the slack bot (powered by subnet 20) to help them support their customer.  This implementation is passing serper/google results to subnet20 as context to be used by the miners with their LLMs.  They must find the most relevant content and answer the question from there.\n\nhttps://www.loom.com/share/bb7b6d690fa64be5953ad8c76f903059?sid=d9a077f8-272a-4d7f-92ca-c7911ea8c9f1 \nThis video is showing off the IT ticket updates left by the subnet integrated into ConnectWise - top IT platform, supporting a massive market share of MSPs.  IT tickets are automatically routed through our subnet to get a) troubleshooting tips and b) questions to ask the customer.  These notes are then available for IT support to work with.\n",
        "Relevant Links:": "Subnet Document - https://docs.google.com/document/d/1QVCzDu0eMmkdglD65F_Q_UjnCJauVEr62WgG8SgACt0/edit#heading=h.9gk7b884ect1\nRepo - https://github.com/RogueTensor/bitagent_subnet/tree/main\nMSPTech.ai website - https://msptech.ai/\nWIP Demos page - https://roguetensor.com/bitagent/demos\nWandB link for testnet - https://wandb.ai/bitagenttao/bitagent-testnet-logging/table?nw=nwuserbitagent\nWandB link for mainnet - https://wandb.ai/bitagenttao/bitagent-logging?nw=nwuserbitagent \nMarket Watch PR - https://www.marketwatch.com/press-release/bittensor-subnet-20-launches-innovative-ai-support-technician-pilot-program-with-leading-it-service-companies-393e97b9 ",
        "Please ensure that all responses are concise and provide the necessary information to understand the operational parameters of the subnet": null,
        "Email Address": ""
    },
    {
        "subnet": "kappa-10",
        "SN Name and SN Number": "sn10 - D3 Subnet",
        "Subnet Owner Discord Username": ".chriswilson1016 (Gitphantom)",
        "Subnet Objectives and Contributions:": "Our objective is to construct the world's largest training dataset. \nThe repository for the bittensor dataset can be found on Huggingface at the following URL:\n    https://huggingface.co/datasets/bittensor-dataset/twitter-text-dataset\n    https://huggingface.co/datasets/bittensor-dataset/twitter-image-dataset\nThis dataset allows us to continually enhance our models with the most recent data.\nThe D3 Subnet, standing for Decentralized Distributed Data Scraping subnet, plays a crucial role in the advancement of artificial intelligence by ensuring ample training data for all Bittensor AI networks.\n",
        "Communication Protocols:": " - The communication protocols used by this subnet do not include synapse between validator and miners.\nMiners commit the URL of their Huggingface data repository to the blockchain.\nValidators retrieve miners' commitments from the blockchain and evaluate them.\n - Data is transmitted every 200 blocks by miners, and validators evaluate all miners at the same frequency.\n - To secure communications, we employ the chain-commit method, which leverages the power of the blockchain to prevent attacks such as relay attacks. \nAdditionally, each dataset file name generated by miners is random, ensuring that no one can know another miner's repository name before their commit\n\nhttps://github.com/gitphantomman/d3_subnet/blob/da1ce33b72a167a70dda5b27a70606072de210c2/template/utils/huggingface.py#L29\n",
        "Incentives Mechanism:": "Miners within the D3 Subnet are assessed based on the volume of unique data they contribute to the network, excluding any duplicates. To excel, miners are encouraged to gather as much data as possible, commit their findings as fast and frequently as possible to the blockchain.\n\n It's important to note that we verify the validity of the miner's data. If the data is incorrect (e.g., self-generated by miners, not scraped), the miner receives a score of 0.\n\nTo ensure the accuracy of data counts while eliminating duplicates, validators require a Redis database equipped with an indexing table.\n\nThe owner collects all the data of network downloading dataset from miners' commits and using the indexing table similar to validators.\n\nhttps://github.com/gitphantomman/d3_subnet/blob/main/template/validator/reward.py",
        "Data Sources and Security:": " We have ensured that there are no security vulnerabilities.\nValidators utilize their own indexing database (Redis) and synchronize it with the main dataset at startup.\nThey then update their indexing database with each validation.\nValidators also use the Apify actor to verify the correctness of the miner's response.\n",
        "Compute Requirements:": "    - Miners require an Apify account and local storage. (about 100GB)\n    - Miners can boost their rewards by rapidly scraping a large number of tweets.\n      Miners are encouraged to commit as quickly as possible (every 200 blocks).\n    - Everyone can download directly from here.\n    https://huggingface.co/datasets/bittensor-dataset/twitter-text-dataset\n    https://huggingface.co/datasets/bittensor-dataset/twitter-image-dataset\n    - We will publish leaderboard of this subnet in a week.",
        "Notebook and Code:": "\n3) To download using code.\nfrom datasets import load_dataset\ndataset = load_dataset(\"bittensor-dataset/twitter-text-dataset\")",
        "Applications and Collaborations:": "- Leaderboard is developing now. \n- We will produce training dataset for text-prompting, image-generation, video-subnet.. all of subnets using ai models. Now there's already text dataset and image dataset at here: https://huggingface.co/datasets/bittensor-dataset/",
        "Development Roadmap:": "- We will add some more sources: facebook, reddit, ...\n- We will add more datasets: audio, video\n- We will make leaderboard.\n- And we're planning some apps based on this large dataset.",
        "Testnet Information:": "- Our testnet is 18.\n- We set the same environment with mainned, so you can test your validator and miner there.",
        "Demo Recording:": "mining: https://www.loom.com/share/906b4e73cfa34cc7b2e612d9abe1f878\nvalidation: https://www.loom.com/share/1d8b3e95ef8246eb92833c90fecce149\n",
        "Relevant Links:": "https://scrapingsubnet.my.canva.site/whitepaper\nhttps://huggingface.co/datasets/bittensor-dataset",
        "Please ensure that all responses are concise and provide the necessary information to understand the operational parameters of the subnet": "Yes, thank you.",
        "Email Address": ""
    },
    {
        "subnet": "beta-2",
        "SN Name and SN Number": "Omron SN2, testnet SN 118",
        "Subnet Owner Discord Username": "gagichce, sudo_ron",
        "Subnet Objectives and Contributions:": "We propose to enhance the Bittensor network by way of the contributions not only to our subnet but the overall network and public good for the long-term vision of the Decentralized AI industry.  How we accomplish this is by introducing zero-knowledge Machine Learning (zk-ml) to the Bittensor network.  This allows AI models to be circuitized which essentially builds a fingerprint.  This circuit can be used to publicly verify that the prediction from a model was produced from a specific AI model and we call this Proof-of-Inference.  Why is this important?  It addresses the second criteria, how do we enhance the current rewards structure for miners and validators by providing external incentives.  We feel that the current incentive structure does a great job but currently some issues have arisen.  By participating in the Bittensor network we have observed that Miners are incentivized to run the most common and popular models which does create a self-referencing mechanism between the Miners and Validators and there isn't necessarily an incentive to run new and novel state of the art models.  We feel by introducing external data for a rewards mechanism by way of free market is an elegant decentralized solution. Specifically, this subnet enhances the Bittensor network as a whole by providing external uses for protocols outside the Bittensor ecosystem; thereby amplifying bittensor’s mission throughout a variety of external networks. \n\nAdditionally, zero-knowledge proofs are generally more CPU-intensive—providing an opportunity for non-GPU miners to participate—the ultimate aim is to incentivize the development of proving systems optimized for GPU-based operations. This approach not only enhances the performance and efficiency of these operations but also expands the potential for broader adoption and technological impact within the zk-ML field.  The fastest miners achieving the highest scores is crucial to Omron’s goal of creating a robust, publicly accessible, and permissionless zk-ML cluster. This cluster will be available as an Actively Validated Service on EigenLayer represented as an Omron co-chain, which leverages the strength of Bittensor’s incentive model to drive the development of succinct, efficient models that can be circuited.\n",
        "Communication Protocols:": "We use synapse and dendrite-axon communication between neurons in the network. Every block, validators send a JSON payload to miners, requesting a specific AI model with specific inputs. Data size is sub 200 bytes for this communication. In response, miners provide an output from the model along with a zero knowledge proof of their inference. This segment of the communication is typically ~22kb in size. We do not apply additional security measures to the communications.\nhttps://github.com/inference-labs-inc/omron-subnet/blob/main/neurons/_miner/miner_session.py#L29\nhttps://github.com/inference-labs-inc/omron-subnet/blob/main/neurons/_validator/validator_session.py#L265",
        "Incentives Mechanism:": "Incentive is provided to reduce response times while still achieving valid, proven inferences. One of the key issues in zkml is performance - and we believe that adding incentives for miners to speed up their verified inferences will benefit zkml and the network as a whole.\nThere is no risk of data exhaustion. The model currently deployed accepts 5 floating point values which have significant precision, making data exhaustion infeasible due to potential input combinations being 10^22. We plan to implement a feed-in of on-chain data for the model as well, which inherently prevents data exhaustion.",
        "Data Sources and Security:": "Input data is sourced both randomly and via external sources. External staking services will contact our APIs, which will forward queries to validators within the Omron subnet who will in turn solicit responses from miners on each specific set of inputs. When no external service queries are available, validators will randomly select a model to run and generate random input to provide the models. In terms of random data being input, there are no bounds, and thus there is an unlimited number of potential inputs. In terms of third party queries, external services will not have the need to resubmit requests for the same data, as each query will be unique to the current events they are experiencing. \nhttps://github.com/inference-labs-inc/omron-subnet/blob/main/neurons/_validator/validator_session.py#L257",
        "Compute Requirements:": "Medium hardware requirements are needed to run the subnet, however a more performant machine will likely lead to higher scores within the subnetwork due to response times contributing to incentive scores. For miners, 32GB of RAM, 100GB of storage, 1GB of network speed are minimum requirements. For validators, 16GB of RAM, 100GB of storage and 1GB of network speed are the minimum requirements.",
        "Notebook and Code:": "The “top” miner in the Omron subnet can be found using argmax to find the UID with the highest incentive score. A demonstration of positive and negative scoring along with UID query can be found below at:\nhttps://github.com/inference-labs-inc/omron-subnet/blob/main/neurons/opentensor_demo.ipynb",
        "Applications and Collaborations:": "No applications have currently been developed on top of this subnet, however integrations with both third party restaking and integrated bittensor staking optimization applications are underway and will be launched shortly.",
        "Development Roadmap:": "V1 - Initial subnet launch. During this phase, Omron will generate verified inferences using randomized input data through an LSTM model. External restaking data is collected by the Omron team to develop restaking optimization LSTM models.\nV1.1 - Update incentive mechanism to consider proof generation time (lower is better) and proof size (smaller is better)\nV1.2 - Require miners to generate and use their own proving keys, provide validators with their verification key.\nV2 - Launch of Bittensor “Smart Delegation”. Help TAO holders decide which validators to delegate to and make a decision based on potential yield & risk. Miners which receive additional incentive when their recommendation is used.\nV2.1 - Add support for miners deciding which subnets to mine.\nV2.2 - Add support for validators deciding which subnets to validate.\nV3 - Model expansion and integration with third party staking and restaking protocols. The subnet will generate using both randomized data and live data via external protocols and delegations.",
        "Testnet Information:": "Yes, we have a fully functioning testnet operating at NETUID 118. We actively use it for miner and validator testing along with experimental upgrades and operational simulations. We refined our model’s architecture several times during testnet to better suit the target hardware, and were able to reduce proving times significantly before going live.\nOur team has a background in mission critical enterprise solutions and are familiar with staging and deploying updates in a manner as to minimize risk and ensure stable operation.",
        "Demo Recording:": "https://www.loom.com/share/3bd676e89c114c329e33bfaf350d9e00?sid=00bad9bc-156f-4a19-8f16-ceb97ddbf450",
        "Relevant Links:": "https://omron.ai\nhttps://twitter.com/omron_ai\nhttps://twitter.com/inference_labs (parent org)\nhttps://github.com/inference-labs-inc/omron-subnet\n",
        "Please ensure that all responses are concise and provide the necessary information to understand the operational parameters of the subnet": "Visit our subnet channel on discord and say hi! 🥩",
        "Email Address": ""
    },
    {
        "subnet": "zayin-31",
        "SN Name and SN Number": "NASChain - SN-31",
        "Subnet Owner Discord Username": "Mutex.lock",
        "Subnet Objectives and Contributions:": "NASChain aims to perform distributed neural architecture search within the BitTensor ecosystem. NAS algorithms are multi-objective optimization algorithms designed to search for the optimal neural network architecture for any given use case (dataset). This search endeavors not only to maximize accuracy for a specific use case but also to minimize the memory and computation footprint of the neural network for that use case. Such efficiency is critically important in the industry, where even the smallest reductions in memory and computation costs can lead to savings of millions of dollars, especially when performing inference at a large scale or deploying models on devices with hardware constraints.Performing NAS demands a significant amount of GPU computation power and is notably expensive when offered as a service. For instance, executing NAS on Google Cloud can incur costs ranging from $23,000 to $100,000 over a span of 10 days on multiple high-performance GPUs. NASChain adopts a unique approach by implementing NAS based on the Genetic Algorithm, where genomes representing different neural networks in the search space are trained by miners in the subnet. These are then accumulated and mutated for the next generation in a central server referred to as the GenoMaster\nhttps://cloud.google.com/vertex-ai/docs/training/neural-architecture-search/overview",
        "Communication Protocols:": "- Which communication protocols are utilized by this subnet?\nCommunication between miners, validators, and the GenoMaster is based on HTTP requests to the Central Optimizer server (GenoMaster). Currently, axons are not utilized for communication between miners and validators, but work is in progress to report validation results to miners using axons\n   - What type of data is transmitted, how frequently does this occur, and what is the typical data size?\nMiners regularly request jobs from the server via HTTP requests, receiving a JSON message that includes the training hyperparameters, such as batch size, random seed value, dataset location, and an encoded genome representation of the specific neural network architecture to be trained by the miner. The miner's response to the server is an array of three floating-point numbers in the following format: [Accuracy, #Parameters, #FLOPs]. Validators request a list of finished jobs from the server to apply a validation method to them and calculate rewards.\n   - Is there any security or encryption applied to the messages? If not, are there plans to implement such measures? Describe the methods used to secure communications.\nThe information passed between the miner and the server, as well as between the validator and the server, is not encrypted at the moment, since it does not include any sensitive information\nhttps://github.com/nimaaghli/NASChain/blob/main/src/validator/forward.py\n",
        "Incentives Mechanism:": "- Please detail the reward mechanism for this subnet and include links to the relevant GitHub repositories.\nThe subnet incorporates a two-level validation and incentive mechanism, where miners earn points for both proof of work and their productivity, based on the time it takes them to complete their training jobs. Every miner returns the response to the Genomaster in an array of size three, such as [accuracy, parameters, FLOPs]. To ensure the results are legitimate from the miners, the Server will assign each job to three different miners randomly, assuming that no miner can be in the job batch more than once (the subnet will not function if there are fewer than three miners in the network). Once responses are returned from all miners of the job batch, they will be delivered to validators upon request. To mark the three results as legitimate, they should be in agreement. Below, we describe the validation method in more detail.\nLevel 1: Agreement-Based PoW(Proof of Work) Scoring\n1.Job Batches: Defined as B = {b_1, b_2, ..., b_n}, each batch b_i corresponds to evaluations from different users for the same job.\n2.Distribution:\nEach unique genome training task is assigned to three different miners randomly, ensuring that the same genome is not assigned to the same miner more than once.\nThis set of three miners constitutes a single job batch b_i.\n3.Responses: Upon completion of their tasks, each miner submits their results as an array of three values [M_A, M_P, M_F], corresponding to the accuracy (A) of the genome training, the number of parameters (P) in the genome model, and the number of FLOPs (F) in the genome model, respectively.\n4.Consensus: The validators collect the results into a 3x3 matrix, where each row represents the results from a single miner. The validation criteria are as follows:\nAccuracy (A): The accuracy values should be within a tolerance of ±1%. Since the same neural architects with the same hyper parameters on the same testset should yield the same accuracy. This is to ensure that the miners did actually train the gnome and are not sending random values back. \nParameters (P) and FLOPs (F): These values must be exactly the same across all miners. We provide the code to the miners that profiles P and F for any given architecture. \n5.Reward Allocation\nIf all three miners agree on all three metrics according to the validation criteria, each miner receives points.\nIf only two miners' results are consistent with each other and meet the validation criteria, those two miners receive points, and the third does not.\nIf all three miners disagree (i.e., their results do not meet the validation criteria), no points are awarded, and the job batch is rejected by the system (referred to as \"GenoMaster\").\n\nLevel 2: Total Number of Jobs Finished\nThe total contribution of a user is also evaluated based on the total number of jobs they have completed, fostering not only accuracy and consensus but also productivity. The total number of jobs finished can have a direct relationship with the type of GPU used by the miner. Faster GPUs will not only finish their own jobs faster but also have the chance to take over jobs from slower miners, resulting in better rewards for them.\nThe results submitted by miners are expected to show agreement unless there has been tampering with the mining code, especially regarding training parameters such as weight initialization seed, number of training epochs, or batch size. The three-batch agreement system is designed to ensure that all miners use exactly the configuration dictated by the GenoMaster, to ensure that the results returned are reliable and correct.\nIn terms of productivity and constant improvement, the system will reward faster miners, as they will be able to finish more jobs during the training phase of each generation. This encourages not only adherence to specified configurations for consistency and accuracy but also efficiency and speed in completing tasks.\n\n  - GitHub Link to Incentives Mechanism\nhttps://github.com/nimaaghli/NASChain/blob/main/src/validator/reward.py\nGraphical introduction to our reward system in our readme file:\nhttps://github.com/nimaaghli/NASChain\n",
        "Data Sources and Security:": " - What is the origin of the data used by validators? Indicate if any data augmentation processes are in place.\nValidators request job results and job completion information submitted by the miners to the server (GenoMaster). They receive a dataframe of all jobs submitted by the UIDs to the server in JSON format.\n   - Are there any known vulnerabilities within your subnet, such as susceptibility to lookup attacks due to limited dataset size? If so, what measures are planned to safeguard the subnet?\nWe have not published the code for the server (GenoMaster) publicly and are currently addressing all potential vulnerabilities and implementing blacklisting methods before open-sourcing the code. However, we have created a dashboard of all activities happening in GenoMaster for transparency at this address:  http://51.161.12.128:5000/\n  - GitHub link to Data Sources\nThe repo is private to make sure all possible vulnerabilities are resolved during the mainnat trials. We can give access to the bittensor team upon request.\nhttps://github.com/nimaaghli/GenoMaster\n",
        "Compute Requirements:": "   - What are the computational prerequisites for participating in your subnet?\nNAS deploys a dynamic range of model architectures that require varying amounts of GPU memory. Currently, we suggest using GPUs with at least 16GB of memory.\n   - How can miners increase their rewards? Are they required to train specific models or run predetermined models?\nMiners receive rewards for reliability (proof of work) based on an agreement to train the same model with randomly assigned to two other miners. Secondly, they are rewarded for the speed of training the genomes. This ensures that there will be competition in the system to consistently use the best GPUs. Miners can increase their rewards by providing reliable and fast GPUs. \n\nMiners, as part of a single job, receive a unique neural network architecture encoded as a genome of 1s and 0s. Miners have encoder code that converts the encoded model architecture into a PyTorch trainable model. We are currently only testing the NAS (Neural Architecture Search) on the CIFAR-10 image classification use case. Miners train each unique architecture from scratch with hyperparameters dictated by GenoMaster and return the objectives back to GenoMaster.\n\n   - Is there any public interface or user interaction with the subnet? If not currently available, are there plans to develop one?\nNot Currently, our plan is to provide a web interface where customers can upload their dataset and define their goals, such as hardware limitations and desired accuracy. In the background, the frontend will create NAS jobs and use the miners to find the best model for the user's requirements.\n\n",
        "Notebook and Code:": " - Add a notebook or provide the code that does the following:\n 1) Query the top miner uid  (We will be using the foundation hotkey to do this)\n 2) Demonstrate each reward/penalty mechanism/Scoring of the top miner response\n 3) Queries the API and/or links to a frontend(if applicable)\nhttps://github.com/nimaaghli/NASChain/tree/main/notebooks\n",
        "Applications and Collaborations:": "- Have any applications been developed on top of your subnet? While not mandatory, this information is beneficial.\nOur goal for some time has been to ensure we can successfully perform distributed NAS (Neural Architecture Search) and present the results. The application for this subnet is going to be a NAS service provided to customers in the same way it is offered by Google Cloud, AWS, etc.\n   - Is there any ongoing collaboration with other subnets? This is also not a requirement but is valuable information.\nNot Currently but we have initial ideas on delivering datasets to miners with FileTAO(21). Additionally, for very large models that a single miner cannot train within our subnet, we are considering submitting them to a Hivetrain (25).\n",
        "Development Roadmap:": "1.Test the functionality of every unit in the subnet (Optimizer, GenoMaster, JobWatchdog, Miners, Validators, Incentive Mechanism, Subnet Self-Improvement Algorithm).\nSuccessfully perform NAS on well-known datasets (CIFAR-10, CIFAR-100, and ImageNet) for classification, as well as well-known time series and radar use cases, and compare the results to those in the literature.\n2.Publish a paper on the findings and the methodology (target is NeurIPS).\n3.Work on the front-end application for the subnet.\n4.Expand dataset support or improve model evaluation processes to enhance the overall effectiveness of the NAS system.\n5.Develop an advanced dashboard for monitoring NAS, providing comprehensive insights and analytics.\n6.Conduct R&D on developing and improving the NAS backend as a multi-objective optimizer. (We are currently leveraging open-source genetic algorithm implementations of NAS for the initial framework.)\n",
        "Testnet Information:": "- Did your subnet participate on testnet? Describe the scope and participation of your subnet on the testnet.\nWe tested our subnet code on subnet (123) on the testnet. A total of 8 miners and 1 validator participated to test the functionality of the subnet.\n   - Provide information on how updates from the testnet were managed and transitioned into the live environment.\nFeedback from the miners helped with fixing bugs in the miner software and also improved the incentive mechanism.\n\n",
        "Demo Recording:": "https://www.loom.com/share/98ef8ea2bf6a4f92a51b63cf1dd4501d?sid=4338c40f-89d3-4b49-b2ac-44aa0ee24105",
        "Relevant Links:": null,
        "Please ensure that all responses are concise and provide the necessary information to understand the operational parameters of the subnet": null,
        "Email Address": ""
    },
    {
        "subnet": "",
        "SN Name and SN Number": "3D Gen // TestNet 89",
        "Subnet Owner Discord Username": "Ben @bnjms // Max (Tech Lead) @mx4096 ",
        "Subnet Objectives and Contributions:": "Long Term - Democratize 3D content creation and empower anyone to create virtual worlds for gaming, entertainment (VFX / film), and XR consumer / retail applications.\n\nShort Term - Create the largest 3D synthetic datasets and asset stores based on current user demands for 3D content creation (e.g. informed by gaming industry marketplace searches)\n\n3D AI is a solution space not yet meaningfully engaged with on the Bittensor network but with actual tangible real world use cases and opportunity for extensive interconnectivity. For example our synthetic dataset text queries are created by LLMs, our validators use 2D image-based rendering techniques in scoring, and our generated 3D assets require on-chain storage. All key points for interconnection and enhancing the overall Bittensor network.",
        "Communication Protocols:": "We utilize HTTP-based communication protocols, specifically leveraging Bittensor's axons and dendrites.\n\nThe communication pattern resembles a classic scheme with stateless workers pulling jobs from a queue. However, each validator maintains its own task queue.\n\nMiners send PullTask synapses to the Validators to request tasks. Miners then submit the results using SubmitResults synapses. Miners are incentivized to evenly distribute the pulls across the Validators.\n\nMiners can increase the number of generation endpoints, which will increase the throughput of their neuron and, in turn, increase their rewards.\n\nValidators are expected to serve the axon to allow miners to pull tasks. Additionally, Validators can optionally support additional synapses to provide a public API.\n\nText or image (in planned future releases) prompts are sent in response to PullTask. Compressed 3D model is sent back. Generation time highly depends on the GPU the miner is using. One A100 generates the model in ~3 minutes. The model size is in the range of 30-90MB. The generation frequency depends on the profitability of the network. If running multiple GPUs is profitable, then the frequency and overall traffic will be higher. Default values are: 60MB/3 min for each miner.\n\nNo encryption is planned. All communications are open.\n\nhttps://github.com/404-Repo/three-gen-subnet/blob/v2/neurons/common/protocol.py\n\nhttps://github.com/404-Repo/three-gen-subnet/blob/13e766bbf91e403710b625132cea7561741358ba/neurons/miner/workers.py#L20 \n\nhttps://github.com/404-Repo/three-gen-subnet/blob/13e766bbf91e403710b625132cea7561741358ba/neurons/validator/__init__.py#L89 \n",
        "Incentives Mechanism:": "Miners are rewarded for 3D model generation. The total miner reward is a number of generations made during an 8-hour window, multiplied (factored) with the average fidelity score. The fidelity score is a CLIP-based comparison of the 2D renders generated by the validator for the submitted model and the initial query. To remove randomness (unlucky render angle, CLIP volatility), the fidelity score is rounded to 1.0 in case of 0.8 and higher, and rounded to 0.75 in case of 0.6 and higher.\n\nWe've collected 300k+ prompts suitable for 3D generation and continue updating the dataset with new values. Additionally, we have organic traffic from Discord bots (used internally by team and collaborators while on Testnet, to be released publicly once on Mainnet). With the current generation time, dataset exhaustion is possible, but we generate and filter new prompts faster than miners generate models.\n\nMore details on validation:\n\nOur input for the validation mechanism is a buffer with Gaussian Splatting data that is essential for geometry reconstruction and the text prompt that was used for the generation of this splat. To evaluate the input model we need to estimate how far/close the input prompt from the generated model. We use CLIP to get those estimations. The algorithm is as follows:\n- We create a list of negative prompts that CLIP model will use for comparing the input prompt to.\n- We render several views of the Gaussian Splatting model and embed both rendered images and the input text prompt to a higher space where they can be compared by CLIP model.\n- We get the estimation per rendered view and then just average the score. We also try to omit ambiguous views where the CLIP model failed to identify the object correctly.\n\nhttps://github.com/404-Repo/three-gen-subnet/blob/13e766bbf91e403710b625132cea7561741358ba/validation/serve.py#L33 \n\nhttps://github.com/404-Repo/three-gen-subnet/blob/13e766bbf91e403710b625132cea7561741358ba/neurons/validator/__init__.py#L229 \n\nhttps://github.com/404-Repo/text-prompt-generator ",
        "Data Sources and Security:": "We are creating a new dataset of prompts that is suitable for 3D generation. We have over 300k+ unique and filtered prompts now, and the goal is to have at least 500k. With a 3-minute generation time per prompt and 30-90MB result size, it's quite possible to pre-mine the whole dataset if significant resources are involved. While this poses a risk in the long term, it's good in the short term, as our goal is to build the largest AI-generated collection. However, the basic provided model can't cope with some of the prompts, and most competitive miners are expected to experiment with the AI model to improve it. Additionally, we are already testing a new generation pipeline: text -> image -> 3D, with additional styling filters applied to the image, which will increase the initial dataset multiple times. Furthermore, we are expecting significant organic traffic from the partnership programs. In conclusion, the dataset is not infinite, and there are steps in our roadmap to continuously grow it.\n\nhttps://github.com/404-Repo/three-gen-subnet/blob/v2/resources/prompts.txt\n",
        "Compute Requirements:": "The bare minimum for the miner and validator would be a nvidia-l4 level VM. However, as the subnet incentivizes the throughput to stay competitive, the miner would need nvidia-tesla-a100 or higher.\n\nThe first and easiest thing a miner can do to increase the reward would be to run the higher-spec VM and generate models faster. Running multiple generation endpoints would give the miner a huge advantage. While training or changing the model is not expected from the miner, we will be continuously providing miners with updates from the 3D generation worlds. We deliberately left some prompts in the dataset to be hard for the predetermined model, resulting in a 0 validation score. Miners who can overcome this will also be rewarded more.\n\nValidators, optionally, provide public API and can be a source of the organic requests.\nhttps://github.com/404-Repo/three-gen-subnet/blob/13e766bbf91e403710b625132cea7561741358ba/neurons/common/protocol.py#L48 \n\nThe major update is a new generation pipeline: text -> image -> 3D.",
        "Notebook and Code:": "With the new version, it's no longer possible to query a specific miner. The miner's reward is the number of accepted generations multiplied by the fidelity factor during the sliding 8-hour window. The algorithm is:\n\nWhen there is an 80% match with the prompt, the miner gets a fidelity score equal to 1.0. When there is a 60% match with the prompt, the miner gets a fidelity score equal to 0.75. The exponential moving average (EMA) of the miners' fidelity scores is calculated and used as the fidelity factor. If the generation results fail to match the prompt, the fidelity score is not decreased, but the result is not accepted. This way, 50 perfect generations are equal to 100 generations where half of the results are not accepted.\n\nOne of the ways to manually check the validator's correctness would be to run the validator on the testnet/mainnet and monitor the logs for top miner activity. Additionally, the saved validator state could be used to see all miners' recent observation times and average fidelity score (fidelity factor).\n\nValidation service: https://github.com/404-Repo/three-gen-subnet/blob/v2/validation/serve.py\n\nReward calculation: https://github.com/404-Repo/three-gen-subnet/blob/876ba0f4961eff953e1deacf1a4ee38bdad408f8/neurons/validator/miner_data.py#L63 \n\nMock scripts: https://github.com/404-Repo/three-gen-subnet/tree/v2/neurons/mocks\n\nPublic API: https://github.com/404-Repo/three-gen-subnet/blob/876ba0f4961eff953e1deacf1a4ee38bdad408f8/neurons/common/protocol.py#L50 \n\nMock client: \nhttps://github.com/404-Repo/three-gen-subnet/blob/v2/neurons/mocks/mock_client.py\n\nThe public API is in the test mode. Only whitelisted/hardcoded wallets will be accepted. While we intend to keep allowing only whitelisted wallets to use the subnet, the hardcoded solution will be replaced with a more dynamic one. This change will happen after a short testing period on the mainnet.\n",
        "Applications and Collaborations:": "We do not yet have applications developed on top of our subnet, largely because we are currently on testnet and feel we should first be operating on mainnet with a certain level of security for long-term operations to commence collaborations.\n\nIn preparation for this we have been in contact with several game & virtual world developers (e.g. https://monaverse.com/, a leading blockchain and browser-based immersive environment) who are ready to build applications on our subnet when we confirm with them that we are ready and on mainnet. In addition, our team has built a front-end 3D model viewer to showcase the results of our asset store creation and this will include metadata tags to ensure miner and validators are attributed proper model provenance (opening up future monetisation potentials for these parties).\n\nAgain - won't be live until mainnet but latest draft here: https://www.figma.com/proto/n4Lh23IFCNdwZ7FbfpzXf3/404-Brand-Pivot?type=design&node-id=108-226&t=uilhBP4Ev8sDHvJf-1&scaling=min-zoom&page-id=108%3A225&mode=design\n\nFinally, the team behind this subnet (atlas.design) works with some of the largest AAA web2 gaming companies in the world - including Square Enix, Sony, Shrapnel, CDPR (and others we are not allowed to publicly disclose) - building custom AI solutions and the goal is to onboard these players into the web3 ecosystem via Bittensor and our subnet.\n",
        "Development Roadmap:": "We are planning a variety of diverse real-world applications to be built on top of the 3D AI technology innovations and development facilitated and empowered by this subnet. In our whitepaper (linked below) we outline some tangible applications that we will actively facilitate through partnerships, collaborations and front end interfaces. \n\nThese applications focus within the Gaming vertical as our team has strong domain knowledge in this industry and sees strong web3 and web2 opportunities arising here. One could easily expand these applications into related entertainment verticals, especially given the entertainment market as a whole is moving towards gamification - exemplified by the February 2024 Disney x Epic partnership announcement. Attention is becoming an increasingly scarce resource and passive consumption is being replaced by active engagement in the same way that finalized products in the entertainment industry are being replaced by continuous creation.\n\n“We compete with (and lose to) Fortnite more than HBO”\nNetflix letter to shareholders\n\nWhitepaper: https://docs.google.com/document/d/1tAAew-0X_5w-0iR5YG-_OFp1xF2oRjzX-7GiDQaxiHE/edit?usp=sharing",
        "Testnet Information:": "We are not on a mainnet yet and all our tests are on the testnet (89). Once we register a subnet on mainnet we plan to continue to support the testnet environment, so that we can rollout features safely and allow both miners to experiment with the code.\n\nIt may also be worth noting here that before we were de-registered from mainnet we had very positive community feedback (still seen on our testnet channel). We also were the ones to suggest having a testnet section on the discord (https://discord.com/channels/799672011265015819/799672011814862902/1209600303553445889) which you implemented and this allowed us to continue interacting with the community while we were building and preparing for launch. \n\nWe have two team members that are fully dedicated towards helping us build a community, address technical issues and grow our visibility both within the Bittensor community and beyond it (with the goal of onboarding people into the community). In addition, we have three ML Engineers and a Tech Lead with blockchain & substrate experience that are fully dedicated to ensure any exploits or issues are rapidly addressed. \n",
        "Demo Recording:": "n/a",
        "Relevant Links:": "Aside from the links provided throughout this submission, a nice article showing our contribution to the overall Bittensor ecosystem was noted in this medium post: https://medium.com/collab-currency/running-bittensor-9d0e810d2483",
        "Please ensure that all responses are concise and provide the necessary information to understand the operational parameters of the subnet": "We would like feedback on this submission, the goal of submitting while on testnet is to know that weights will be provided so we can then move onto mainnet and execute on our partnerships and front ends.",
        "Email Address": ""
    },
    {
        "subnet": "he-29",
        "SN Name and SN Number": "Fractal Research SN29",
        "Subnet Owner Discord Username": "theAdoringFan & girlfriend-deficit",
        "Subnet Objectives and Contributions:": "The primary purpose of the subnet is to serve as a solution for inference at scale. We are showcasing this with text-to-video generation. Text-to-video isn’t highlighted elsewhere in Bittensor, so it furthers the ecosystem by providing more breadth to the modalities covered by Bittensor. Additionally, by providing massive inference at scale, it allows a stable environment for builders. Please read more about our contributions here: https://fractalnet.io/whitepaper",
        "Communication Protocols:": "The communication protocols are http implemented via FastAPI. Data transmissions are in the form of “challenges” and “responses”, containing queries, and returning generated videos. Importantly, we've added inference for end users through the same synapse that validators do challenges with-- this prevents miners from knowing what end-user responses are, ensuring they respond to all requests. There are currently no encryption methods, but will add HTTPS via FastAPI. \nGithub to protocol.py: https://github.com/fractal-net/fractal/blob/main/fractal/protocol.py",
        "Incentives Mechanism:": "The reward mechanism is made to be incredibly resilient to gamification. With challenges, a request is generated (a text sentence to generate a video from), and is run by both the validator and the miner. An output hash is generated by each as well, and the output hashes are compared. If the output hashes don’t match, the miner fails the challenge. This ensures that model inference is actually being run. Inference requests (end-user requests) will not redundantly run, to prevent wasted compute.There are challenges tiers to reward longtime performant validators. If a validator is deregistered, it can quickly return to a higher tier and earn more rewards (but has to answer more challenges). \nhttps://github.com/fractal-net/fractal/blob/main/fractal/verifier/reward.py\n\nplease check out our paper on incentive mechanism:\nhttps://discord.com/channels/799672011265015819/1207399745031770152/1228585646503886869",
        "Data Sources and Security:": "The dataset is created by Fractal and uses a pipeline to prevent staleness. We are unaware of any vulnerabilities. Challenge data rotates constantly so lookup attacks are quite difficult. We also us a seeding mechanism for generation requests where seeds range from 0 to 2**32-1 to improve security & further protect against lookup attacks. ",
        "Compute Requirements:": "Compute requirements are currently RTX 3090 for both validators and miners, however this will scale with our next release (where we improve model quality). Miners can increase their rewards by performing better for longer periods of time (not missing any challenges). It is critical to the health of bittensor to not have failed api requests. Front end is available at fractalnet.io. We have an update scheduled for next week that will increase model quality, increase hardware requirements, add inference requests so that validators can easily query the models, and adding auto update feature. We are also using subnet funding to rewrite the btcli in rust (https://github.com/fractal-net/tenso-rs) + improve the frontend (fractalnet.io)\n\n",
        "Notebook and Code:": "we do not have a validator so cannot query miners on mainnet :-( but here is the api implementation:\nhttps://github.com/fractal-net/fractal/blob/main/neurons/api/app.py\n\nreward scoring:\nhttps://discord.com/channels/799672011265015819/1207399745031770152/1228585646503886869\n\nfront end:\nfractalnet.io",
        "Applications and Collaborations:": "fractalnet.io\n\nworking with philanthrope to allow users the option to store generated videos in the storage subnet. this can also be used as syntethic data for training t2v models. ",
        "Development Roadmap:": "Key developments include improving model quality and optimizations around latency: we see this subnet in a sense as an application load balancer, and view inference speeds and reliability as really important when Bittensor has apps with a lot of users building on it. Fractal ensures that miners are able to respond to inference requests– but we need to make sure its the fastest response possible. To do this, we will have validators record response time and create a mapping to allow for end user requests to reach the optimal miner and return a response as fast as possible. Additionally, we will continue to improve model quality + hardware requirements so that the end product is as strong as possible.",
        "Testnet Information:": "We participated on testnet, running 3 validators and a handful of miners (roughly 10-12) from a series of different instances. We let this run for a few days to ensure everything worked, including pushing updates. We are currently testing all new updates on testnet, using it as a staging environment. ",
        "Demo Recording:": "https://www.loom.com/share/cf3a663f0ea849aea05c534e9fc15efb?sid=f1115b11-c184-496a-aede-6de85c4cfa52",
        "Relevant Links:": "https://fractalnet.io\nhttps://fractalnet.io/about \nhttps://github.com/fractal-net/fractal",
        "Please ensure that all responses are concise and provide the necessary information to understand the operational parameters of the subnet": null,
        "Email Address": ""
    },
    {
        "subnet": "rho-17",
        "SN Name and SN Number": 17,
        "Subnet Owner Discord Username": "atem1896",
        "Subnet Objectives and Contributions:": "Diffusion models (pre-training/finetuning)",
        "Communication Protocols:": "No communication, except with subtensor.commit()",
        "Incentives Mechanism:": "def iswin( loss_a, loss_b, block_a, block_b ):\n    loss_a = (1 - constants.timestamp_epsilon) * loss_a if block_a < block_b else loss_a\n    loss_b = (1 - constants.timestamp_epsilon) * loss_b if block_b < block_a else loss_b\n    return loss_a < loss_b\n\nBest win_loss = best model = more weights\nNo query\nhttps://github.com/PlixML/pixel/blob/master/neurons/validator.py",
        "Data Sources and Security:": "SOTA Dataset (From Vision 19 Subnet) https://github.com/PlixML/pixel/blob/master/finetune/dataset.py",
        "Compute Requirements:": "24GB VRAM (with 8 bit quantization)\nThey must train their model using the dataset generated from pixel dataset generate.\n\n- Updates where we're going to change datasets, for example to make a finetuned animated SDXL model.\nWhen there are enough emissions, start pretraining an 20B image model. We want to perform MidJourney or DALL-E 3. https://www.recraft.ai/about an example of what we aim to do",
        "Notebook and Code:": "---",
        "Applications and Collaborations:": "We simply use high-quality SOTA datasets from subnet 19\n",
        "Development Roadmap:": "- Finetuning MidJourney V6\n- Finetuning Anime version\n- Finetuning DALL E 3\n[..]\n- Pretraining 20B Diffusion Model\n",
        "Testnet Information:": "X",
        "Demo Recording:": "X",
        "Relevant Links:": "https://huggingface.co/spaces/PlixAI/pixel-subnet-leaderboard",
        "Please ensure that all responses are concise and provide the necessary information to understand the operational parameters of the subnet": null,
        "Email Address": ""
    },
    {
        "subnet": "kappa-10",
        "SN Name and SN Number": "Name: Apollo UID: 10",
        "Subnet Owner Discord Username": "@cjtf_ @burck",
        "Subnet Objectives and Contributions:": "**Collaborative Distributed Zero Knowledge Proofs**\n\nApollo enhances the Bittensor Network by producing ZK proofs in a collaborative way. Rather than having all miners compete over the same problem, our miners will each solve a part of a larger problem. More miners, bigger proofs.\n\nOur API allows companies using ZK to completely outsource their devops and setup for proving clusters against a competitive price, essentially making our subnet a one stop shop for proving solutions that is easier to use and much better priced than current cloud providers.\n\nMoreover, our first of its kind infrastructure for collaborative compute will not only make current solutions easier to use, but also unlock new ZK usecases that were, until now, too compute heavy, like provable inference, etc.",
        "Communication Protocols:": "--Communication\nThere is direct validator to miner communication through synapses. One synapse is currently implemented, which sends an encoded polynomial, some auxillary data and a request to compute a KZG commitment. Data size is in the MB range, with plans to reduce this to the KB range when distributed proofs are fully implemented.\n\n--Security\nCurrent protocol is unencrypted. Future updates may introduce encryption, depending on the scheme. \n\n--Links\nprotocol ref: https://github.com/apollozkp/zkp-subnet/blob/main/base/protocol.py",
        "Incentives Mechanism:": "--Incentives\nA proof is either valid or invalid, and it is (almost) trivial to check validity, so we score miners on their response time and the size of their work. Currently the size of work is constant, so miners are scored only on response time.\n\n--Type of data\nValidators query miners with generated data to test their proving speed. In particular, miners are asked to provide a commitment to a randomly generated polynomial and to open the polynomial at a randomly chosen point. The size of the polynomial is chosen to be sufficiently challenging.\n\n--Links\ndata generation ref: https://github.com/apollozkp/fourier/blob/main/src/engine/blst.rs\n\nincentives ref: https://github.com/apollozkp/zkp-subnet/blob/0438ac8fec48dceb267ea603109129316266dae1/neurons/validator.py#L143",
        "Data Sources and Security:": "--Origin\nData is generated client side and is cryptographically safe. \n\n--Vulnerabilities\nNo vulnerabilities are known.",
        "Compute Requirements:": "--Computational prerequisites\n---MEM\nAt least 32GB mem for both miner and validator. This should remain constant even with future updates. Future updates may introduce context switching which would favor miners with more mem.\n---COMPUTE\nAt least 8 core CPU is enough to generate a proof in reasonable time, more is better. Future updates will introduce cuda implementation to allow GPU miners to leverage their hardware.\n---BANDWIDTH\nQueries can be LARGE, so miners with good bandwidth have a significant advantage. Future updates will mitigate this somewhat.\n\n--How can miners increase their rewards?\nA miner can increase its rewards by submitting a valid response faster than others. This is influenced by:\n1. Compute - a valid response usually requires the result to some computational challenge\n2. Bandwidth - the challenge usually has some data attached\n3. Collocation - Saves a little on latency, should be negligible, may matter in the future\n\n--Significant updates\n--- Distributed Proofs\n--- public API\n--- context switching wrt trusted setup\n--- Cuda",
        "Notebook and Code:": "1) Query top miner:\nhttps://github.com/apollozkp/zkp-subnet/blob/fd9dd891f422d0eff313de3567f4ea240efe1cfc/test.py#L53\n\n2) Reward/penalty mechanism\nhttps://github.com/apollozkp/zkp-subnet/blob/fd9dd891f422d0eff313de3567f4ea240efe1cfc/neurons/validator.py#L103\n\n3) Not applicable",
        "Applications and Collaborations:": "none and none\n\nCurrently in promising talks with possible clients who wish to outsouce their proving cluster work to our subnet.",
        "Development Roadmap:": "- implement vanilla-PLONK style constraint aggregation\n- build payment infrastructure to fully open a public API for proof generation with payouts to miners and validators\n- extend constraint agregation support to any type of circuit (KZG only)\n- Explore segmented lookup tables in constraint aggregation work\n- Perform further research into distributing work for other commitment schemes\n- Explore other fruitful opportunities for miner collaboration outside of ZKP generation",
        "Testnet Information:": "Apollo is live on testnet at UID 115. We have our full deployment there including validating and mining nodes. We will continue to use the testnet to test new developments before they are rolled out to mainnet.",
        "Demo Recording:": "n/a right now",
        "Relevant Links:": "https://hackmd.io/@cjtf0991/BJjwNMKW0\n",
        "Please ensure that all responses are concise and provide the necessary information to understand the operational parameters of the subnet": null,
        "Email Address": ""
    },
    {
        "subnet": "psi-23",
        "SN Name and SN Number": "NicheImage - SN23",
        "Subnet Owner Discord Username": "MrNiche",
        "Subnet Objectives and Contributions:": "We want to make AI universally accessible and tailored to each individual’s needs.\nWe do this by developing NicheImage, an inference subnet for running the best generative AI models for every niche, so that as many as possible can access a high quality model for their use case.\n\nDue to our structure of having different emission pools for different models that can use different scoring, we can easily add, adjust and remove new models based on demand, ensuring we can always provide the most sought after models.\n\nFurther our subnet excels at providing fast as well as affordable generation for live inference as well as dataset generation, due to organic requests being prioritized and then the excess request capacity is automatically used for synthetic dataset generation. Ensuring that we utilize the network’s full capacity at all times.\n",
        "Communication Protocols:": "- Which communication protocols are utilized by this subnet? What type of data is transmitted, how frequently does this occur, and what is the typical data size?\n\nNicheImage uses HTTP/HTTPS as well as Bittensor’s Synapse Protocol.\nEach miner sets a rate limit that is divided among validators, so if a miner sets a limit of 100 images per 10 minutes, a validator with 10% of all Tao would send 10% of 100 images per ten minutes, meaning 10 requests per 10 minutes interval.\n\nA typical query looks like this:\nA validator sends a synapse using dendrite.query, which is one of the following types:\na) A text for text2img - <1kb in size.\nb) A text for text2text - <1kb in size.\nc) A text and an image for ControlNet - usually 100kb-5mb in size.\nd) An image for img2img - usually 100kb-5mb in size.\n\nAll images in the synapses are encoded using base64.\n\nThe miner receives the synapse and forwards it to a model endpoint that may or may not be on the same server, using http. Having the model run in a separate process than the miner allows multiple miners to use the same endpoint and more GPUs can be addedThe model endpoint generates an image or a text as a response to the synapse, and returns it to the miner that returns it to the validator.\n\n\n- Is there any security or encryption applied to the messages? If not, are there plans to implement such measures? Describe the methods used to secure communications.\nWe have security measures for validators that want to share API access by utilizing asymmetric ed25519 cryptography to authenticate between the validator and the server they want to share access with. That way validators can choose to share their API access with someone running a “proxy server” that authenticates itself with ed25519. Further, validators do not store any data locally, meaning that encryption for storage is not needed.\n\nThe verify function here:\nhttps://github.com/NicheTensor/NicheImage/blob/main/neurons/validator/validator_proxy.py#L63\n\n- GitHub Link Relevant to Communication Protocols\nSynapse implementation: https://github.com/NicheTensor/NicheImage/blob/main/image_generation_subnet/protocol.py#L21\n\nValidator query miner’s configuration: https://github.com/NicheTensor/NicheImage/blob/main/image_generation_subnet/validator/miner_manager.py#L37\n\nValidator getting synthetic challenge: https://github.com/NicheTensor/NicheImage/blob/main/neurons/validator/validator.py#L439\n\nValidator query miner’s to generating image: https://github.com/NicheTensor/NicheImage/blob/main/neurons/validator/validator.py#L363\n\nValidator calculate the rewards: https://github.com/NicheTensor/NicheImage/blob/main/image_generation_subnet/validator/forward.py#L67\n\nValidator proxy, allow our client query miners: https://github.com/NicheTensor/NicheImage/blob/main/neurons/validator/validator_proxy.py#L90\n\nFrontend MVP: https://github.com/toilaluan/streamlit-nicheimage/tree/add_new",
        "Incentives Mechanism:": "Miners get rewarded based on what model they run, their response speed, and how many requests per ten minute interval they can support.\n\nThere are currently seven image models and two text models supported. Model has a specific amount of emission dedicated to them. You can find the current models and their emission distribution on: https://github.com/NicheTensor/NicheImage\n\nThe emission distribution between models works like this: Let’s say one model, RealitiesEdgeXL, gets 30% of emission, that means that 30% of incentive goes to the miners that run RealitiesEdgeXL. If there are very few miners, they will get very high incentive, while if there are many miners, they will each get less emission. This means that by controlling what models get what emission, we can adjust the capacity the network has to give responses for any given model.\n\nFor example if the RealitiesEdgeXL model becomes more in demand, then we can simply increase the emission it gets to 50%, and more people will run it, thus increasing network capacity for this model. Further it allows us to test out new models with low emission, and scale it up when it is ready.\n\nMiners compete with other miners running the same model through having faster responses and higher request capacity. When a miner starts they specify the model they are running, and the total rate limit per 10 minute interval. Then validators know that if they have X% of all Tao on the network, then can send X% of the requests to the miners per 10 minute interval. Only one of the requests sent to miners per interval is actually scored, and it can be either synthetic or organic. However, since miners don’t know which request is actually scored, they need to respond to all of the requests. This structure makes it predictable for both miners and validators how many requests they can send.\n\nHere is the exact formula used to calculated rewards:\nReward = (1 - time_penalty) * (0.8 + 0.2* rate_limit_score)\nTime_penalty = processing_time^3 / 12^3\nRate_limit_score = total_volume_per_10_minute_interval ** 0.5 / 1000**0.5\n\nTime_penalty is in the  add_time_penalty function: https://github.com/NicheTensor/NicheImage/blob/main/image_generation_subnet/validator/forward.py \n\nTotal score is in the async_query_and_reward function:\nhttps://github.dev/NicheTensor/NicheImage/blob/main/neurons/validator/validator.py \n\nRate_limit_score (called reward scale) is in the update_miners_identity function:\nhttps://github.com/NicheTensor/NicheImage/blob/main/image_generation_subnet/validator/miner_manager.py \n\nLastly, we know that the miner is running the correct model by comparing the output with an image/text we generate ourselves and know is correct.\n\nFor images we compare the clip embeddings of the images and make sure the cosine distance is below a certain threshold, and for text models we ask the model to return the top 5 most likely tokens for every token it generates, and we can check that those 5 tokens are indeed the same that we get. Thus we get around the issue of different hardware randomly producing slightly different output.\n\nPrompts for generating images are created by first picking a random seed phrase from a dataset containing over 190 000 seed phrases. Then that seed phrase is fed into an image prompting model that adds 60 to 90 tokens with a temperature of 1. The high temperature means that the text added to the seed phrase is very random, and there can be several thousands of combinations for any single length, and 30 different lengths. This results in there being several billion possible image prompts. You can see exact details of prompt generation here: https://github.com/NicheTensor/NicheImage/blob/main/dependency_modules/challenge_generating/prompt_generating/app.py ",
        "Data Sources and Security:": "For the synthetic requests, there are these main fields:\n_ Prompt for Image Generating: Prompts for generating images are created by first picking a random seed phrase from a dataset containing over 190 000 seed phrases. Then that seed phrase is fed into an image prompting model that adds 60 to 90 text tokens with a temperature of 1. The high temperature means that the text added to the seed phrase is very random, and there can be several thousands of combinations for any single length, and 30 different lengths. This results in there being several billion possible image prompts. This vast potential for prompts makes storing and reusing previously generated images useless. You can see exact details of prompt generation here: https://github.com/NicheTensor/NicheImage/blob/main/services/challenge_generating/prompt_generating/app.py\n\n- Conditional Image for Image Generating (for img2img, controlnet,... pipeline): generated from a Stable Diffusion 1.5 model: https://github.com/NicheTensor/NicheImage/blob/main/services/challenge_generating/image_generating/app.py\n\n- Prompt for Text Generating Model: generated from Gemma-7B Instruction model with various words seeds, currently we’re working on Twitter data:  https://github.com/NicheTensor/NicheImage/blob/main/services/challenge_generating/llm_prompt_generating/app.py\n\nFor the organic traffic: requests params are configured on the frontend or api user.\n",
        "Compute Requirements:": "Miners compete by giving faster responses and having a higher rate limit. Thus while the image and text models could be run with slower GPUs such as an A5000, currently most miners use 4090 GPUs. Some use a single 4090 for one miner, while others use multiple 4090s for multiple miners and load balance between the GPUs.\nMiners can increase their rewards by:\n\n1. Getting more and better hardware which allows them to give faster responses and higher rate limits. For example load balancing between multiple GPUs decreases the risk of delayed responses if they get multiple requests at once.\n\n2. Make software improvements to speed up generation, for example by exporting models to TensorRT or other high speed frameworks.\n\n3. Picking underrepresented models. Since different models have different emission buckets, if one model is run by few miners in comparison to the emission it gets, those miners will receive more emission, incentivizing more miners to switch to that model.\nYes, there is a public interface that shows miner statistics as well as allows you to generate images using the different models: http://studio.nichetensor.com",
        "Notebook and Code:": "Here is a notebook that demonstrates it: https://github.com/NicheTensor/NicheImage/blob/report-main/query_top_miner.ipynb ",
        "Applications and Collaborations:": "Yes, there are several applications using our Subnet.\n\nFirstly we are the frontend we ourselves has developed that allows you to use all of the image models as well as view statistics about each miner, such as their scores and what model they run: https://nicheimage.streamlit.app/ \n\nSecondly you can use our network through tao.bot: https://www.tao.bot/ \n\nThirdly, MakeItAQuote.com has started to use our subnet to generate images for their service where people input quotes and get cool images containing the quote.\nWe have a collaboration with sn22 where we use their Twitter dataset to prompt our text models in order to create a new and up to date dataset.\n",
        "Development Roadmap:": "1. New Model Additions\nAdd JuggernautX and DreamShaperXL with advanced optimization to generate even better images.\n2. Updated API Docs\nWe are building out the docs to make it easier for companies to get started with using our API.\n3. Refine High Quality Image Dataset\nBy using scoring models we can pick the best images the network is generating to create a smaller but even higher quality dataset.\n4. Improved UI\nBy improving the looks and usability of the UI, we can get more people to try out our models.\n5. New Website and Monetization\nWe are working on a new website that will have our updated product offering so companies can easily sign up for our services and pay, which we in turn give to validators. Planned for April-May.\n6. Bittensor Exclusive Models\nWorking together with model creators, we can help fund their development to open source models, but have the models be for non-commercial use and Bittensor mining only. Ensuring open access, but still allowing model creators to monetize their work. Planned for May.\n7. Create the Super-ensemble\nCurrently we have only fixed model categories, meaning that it is specified what models the miners can run. We will introduce open model categories where miners can run any model, and the performance is scored. Unique specialization in this category will be incentivized, meaning that naturally multiple different models with different specializations would occur. This creates an ensemble model of specialized models that is greater than any single individual model. Planned for July.\n",
        "Testnet Information:": "We use testnet 119 to test all upcoming changes before pushing to main, and we also run a validator there to allow miners to try out setting up a miner there before joining the mainnet. We always test updates on testnet before mainnet.",
        "Demo Recording:": "Here is the demo: https://www.loom.com/share/2e155172e39646099aa48c5400227ebf?sid=10cb3293-4aaa-4e10-b999-b9a71b51d01e\n",
        "Relevant Links:": "Full presentation of NicheImage on Novelty Search: https://youtu.be/E-xl3Bq9z1I\nTwitter: https://twitter.com/NicheTensor \nStudio: http://studio.nichetensor.com\nWebsite: NicheTensor.com",
        "Please ensure that all responses are concise and provide the necessary information to understand the operational parameters of the subnet": null,
        "Email Address": ""
    }
]