How to Launch a Token-Curated Registry for AI Models

introduction

IMPLEMENTATION GUIDE

Launching a Token-Curated Registry for AI Models

A technical guide to building a decentralized registry for curating and ranking AI models using token-based governance.

A Token-Curated Registry (TCR) is a decentralized application where a list is curated by stakeholders who deposit a token. For AI models, this creates a community-vetted marketplace where quality, safety, and performance are verified by token holders. The core mechanism is simple: to add a model, a user stakes tokens; the community can challenge the submission by also staking tokens, triggering a vote. This cryptoeconomic design aligns incentives, as bad actors risk losing their stake. Popularized by projects like AdChain for advertising, the TCR pattern is ideal for managing dynamic, subjective datasets like AI model rankings where centralized moderation fails.

To launch a TCR for AI models, you must define the registry parameters and deploy the smart contracts. Key parameters include the deposit amount for listing a model, the challenge period duration, and the vote commit/reveal periods. A basic TCR contract has functions for apply(), challenge(), vote(), and resolveChallenge(). Here's a simplified interface in Solidity:

solidity
interface ITCR {
    function apply(bytes32 _listing, uint _deposit, string calldata _data) external;
    function challenge(uint _listingID, string calldata _reason) external;
    function vote(uint _challengeID, bool _supports) external;
}

The _data field typically holds a URI pointing to the AI model's metadata, such as its performance benchmarks on platforms like Hugging Face or TensorFlow Hub.

The curation mechanism relies on a commit-reveal voting scheme to prevent bias and manipulation. After a challenge is issued, token holders commit a hash of their vote and stake during a commit period. In the subsequent reveal period, they reveal their vote. Votes are weighted by the voter's token balance. If the challenge succeeds, the challenger wins the depositor's stake; if it fails, the depositor's model is added to the registry and the challenger's stake is forfeited. This system ensures that only models the community deems valuable—based on criteria like accuracy, bias mitigation, or license compliance—are listed, creating a trust-minimized directory.

Integrating off-chain data is critical for a useful AI model TCR. Smart contracts cannot evaluate a model's performance directly. Therefore, the listing data (the _data URI) should point to a decentralized storage solution like IPFS or Arweave, containing a structured metadata JSON file. This file should include verifiable attributes: the model's framework (PyTorch, ONNX), training dataset, inference latency, accuracy metrics on standard benchmarks, and a cryptographic hash of the model weights for provenance. Oracles like Chainlink can be used to fetch and verify benchmark scores from trusted sources, bringing objective data on-chain to inform voter decisions.

After deployment, bootstrapping community participation is the next challenge. Initial token distribution can occur via a fair launch, an airdrop to AI researchers, or a liquidity mining program. Governance must decide on key upgrades: should the registry be permissioned (anyone can apply) or permissionless? What is the appeal process for a challenged model? Successful TCRs often evolve into Decentralized Autonomous Organizations (DAOs), where token holders also vote on parameter adjustments like stake amounts. For ongoing maintenance, consider a curation guild or subDAOs focused on specific AI verticals like computer vision or large language models, ensuring scalable and expert-led curation.

prerequisites

TECHNICAL FOUNDATION

Prerequisites and Tech Stack

Before building a Token-Curated Registry (TCR) for AI models, you need a solid technical foundation. This section outlines the required knowledge, tools, and infrastructure.

A Token-Curated Registry is a decentralized application (dApp) where a token-based economic mechanism governs a list of high-quality entries. For AI models, this means creating a system where token holders vote to include, challenge, or remove models based on criteria like accuracy, bias, or efficiency. Core prerequisites include a strong understanding of smart contract development on a blockchain like Ethereum, Solana, or a compatible Layer 2 (e.g., Arbitrum, Optimism). You should be comfortable with Solidity or Rust, depending on your chain, and have experience with development frameworks like Hardhat, Foundry, or Anchor.

Your tech stack will be divided into on-chain and off-chain components. The on-chain layer consists of the TCR's core smart contracts. These handle the registry logic, token staking for submissions and challenges, and voting mechanisms. You'll need to integrate a token standard (like ERC-20 or SPL) for your curation token. For the off-chain layer, you need a way to index and serve registry data. This typically involves a graph protocol like The Graph for querying blockchain events and a backend service (e.g., Node.js, Python) to manage AI model metadata, hashes, and external evaluation metrics.

Essential tooling includes a wallet integration library such as ethers.js or web3.js for the frontend, and a testing framework to simulate complex curation battles and economic attacks. You must also decide on a storage solution for the actual AI model files (weights, architectures). Storing large files directly on-chain is prohibitively expensive, so you'll need to use decentralized storage like IPFS or Arweave, storing only the content hash on-chain. Finally, consider an oracle service (e.g., Chainlink) if your TCR requires external data for automated model validation, such as benchmark scores from a trusted source.

key-concepts

FOUNDATIONS

Core TCR Concepts for AI Curation

Token-Curated Registries (TCRs) use economic incentives to create decentralized, high-quality lists. This guide covers the key components for launching a TCR to curate AI models.

The Stake-and-Challenge Mechanism

The core mechanism of a TCR involves staked deposits and challenge periods. To add a model to the registry, a curator must stake tokens. During a set challenge period, any other participant can challenge the listing by matching the stake, triggering a vote. This creates a cryptoeconomic filter where only models deemed valuable by the community survive, as bad listings result in slashed stakes for the proposer.

EXPLORE

Voting and Token Weighting

When a listing is challenged, token holders vote to decide its fate. Votes are typically weighted by the number of registry tokens held. Key design choices include:

Commit-Reveal Schemes: To prevent vote copying and bribery.
Partial Locking: Voters may need to lock tokens for the duration of a challenge.
Fee Distribution: Winners often share the loser's staked deposit, aligning incentives with correct outcomes. For AI models, voters assess criteria like accuracy, bias, and license compliance.

EXPLORE

Parameter Tuning for AI Lists

Launching a TCR requires setting precise, game-theoretic parameters. Poor settings can lead to a failed registry.

Deposit Size: Must be high enough to deter spam but not prohibitive for legitimate submitters. For AI models, this could scale with model size or compute cost.
Challenge Period: 3-7 days is common, allowing sufficient time for community review of complex AI artifacts.
Application/Challenge Fees: Small fees in the native token prevent griefing attacks. These parameters are often adjusted via governance proposals after launch.

EXPLORE

Integration with Model Repositories

A TCR doesn't store the AI model itself; it curates pointers to external data. For AI models, the registry entry should include:

A content hash (e.g., IPFS CID) of the model weights and configuration.
A link to a verifiable inference endpoint or Hugging Face Model ID.
Metadata like training dataset, license, and performance benchmarks. Using decentralized storage (IPFS, Arweave) and oracles for verifiable execution (EVM) ensures the listed resource remains available and authentic.

EXPLORE

Curate-to-Earn Incentive Models

Sustaining active curation requires designing the token economics. Beyond staking rewards, common models include:

Workload Rewards: Tokens are minted and distributed to voters who participate in correctly resolving challenges.
Curator Shares: A portion of application fees is distributed to all token holders, similar to a dividend.
Reputation Systems: Successful curation can grant non-transferable reputation scores, influencing future vote weight. The goal is to reward those who improve the registry's quality.

Real-World TCR Implementations

Study existing implementations to inform your design. While few are specifically for AI, their mechanics are transferable.

AdChain: Curates non-fraudulent advertising domains. Uses a challenge-and-vote system with a 7.5 million token deposit.
Kleros: A decentralized court that uses TCRs for curated lists (e.g., token lists, registries). Features appeal mechanisms for disputed rulings.
The Graph: While not a pure TCR, its curation market allows signal staking on subgraphs, directing indexer resources to high-quality data APIs.

EXPLORE

contract-architecture

SMART CONTRACT ARCHITECTURE

Launching a Token-Curating Registry for AI Models

A Token-Curated Registry (TCR) uses economic incentives and community governance to curate a high-quality list of AI models on-chain. This guide details the core smart contract architecture required to build one.

A Token-Curated Registry (TCR) is a decentralized application where token holders vote to add or remove items from a list, creating a community-verified dataset. For AI models, this can be used to curate a trusted registry of model addresses, metadata, and performance hashes. The core mechanism involves a challenge period where any listed entry can be disputed by staking tokens, triggering a vote. This creates a cryptoeconomic game where low-quality submissions are financially penalized, aligning incentives for honest curation. Key components include a registry store, a voting contract, and a token staking mechanism.

The smart contract system typically comprises several interacting contracts. A central Registry.sol contract maintains the list of approved AI model entries, each storing a URI for metadata (like the model's hash, framework, and license). A Voting.sol contract manages proposal creation and the commit-reveal voting process for challenges. A staking contract, often an ERC-20 with custom extensions, handles the deposit and slashing of the native registry token (TCRT). When a user submits a model, they must stake TCRT; if their submission is successfully challenged and removed, they lose their stake, which is distributed between the challenger and voters.

Implementing the voting logic requires careful design to prevent attacks. A common pattern is a commit-reveal scheme to prevent vote copying. During the commit phase, voters submit a hash of their vote and choice. In the reveal phase, they submit the actual vote, which must match the hash. Votes are weighted by the number of TCRT tokens the voter stakes in support of their position. The voting outcome determines whether an AI model entry is added to or removed from the registry, and how the staked tokens are redistributed. This requires secure random number generation for vote initialization and precise timing for phase transitions.

To integrate off-chain AI model data, you must use decentralized storage and oracles. The model's core data (weights, architecture) is too large for on-chain storage. Instead, store a content identifier (CID) for the model on IPFS or Arweave in the registry entry. Use a verifiable credential or a trusted oracle (like Chainlink) to attest to benchmark results or audit reports, storing the proof on-chain. The registry contract can then include a verifiedScore field populated by an oracle, giving voters objective data alongside subjective community sentiment during challenges.

Security considerations are paramount. Audit all contracts for reentrancy, integer overflow, and logic errors. Implement a minimum stake and challenge period duration that are high enough to deter spam but low enough to ensure liquidity. Consider a partial slashing mechanism for failed challenges to discourage frivolous disputes. The contract should also include emergency pause functions and a robust upgrade path using a proxy pattern (like TransparentUpgradeableProxy) managed by a decentralized autonomous organization (DAO) of token holders, ensuring the system can evolve without central control.

implementation-steps

IMPLEMENTATION

Launching a Token-Curating Registry for AI Models

This guide details the technical steps to build a token-curated registry (TCR) for AI models, using smart contracts to manage a decentralized list of vetted models.

A Token-Curated Registry (TCR) is a decentralized list where inclusion is governed by token holders. For AI models, this creates a community-vetted marketplace of quality models. The core mechanism involves a challenge period: any listed model can be challenged by staking tokens, triggering a vote by the token-holding community to determine if it should remain. This aligns incentives, as token holders are financially motivated to curate a valuable registry. The primary smart contracts you'll need are a Registry to manage the list, a Voting contract for challenges, and an ERC-20 Token for staking and governance.

Start by deploying the registry token, such as an ERC-20 with optional snapshot capabilities for voting. Next, deploy the main TCR.sol contract. Its key functions include apply() for submitting a model (requiring a deposit), challenge() to dispute a listing, and resolveChallenge() to finalize votes. Each listing should have a status (e.g., Pending, Listed, Challenged), a deposit amount, and an owner. Use a struct to store this data, mapping it by a unique identifier like a content hash (IPFS CID) of the model's metadata.

The challenge mechanism is critical. When a model is challenged, move its deposit to a pending state and start a voting period (e.g., 7 days). Implement a Voting contract, often using a fork of OpenZeppelin Governor or a simple commit-reveal scheme to resist vote sniping. Token holders vote with their stake, and the outcome determines which party (the challenger or the lister) forfeits their deposit. The winner typically receives a portion of the loser's stake, creating a skin-in-the-game incentive for honest curation.

For the frontend, you'll need to index on-chain events (like ModelApplied or ChallengeCreated) using The Graph or an indexer. The UI should allow users to: connect a wallet (via WalletConnect or similar), view the registry list, submit a new model with metadata (storing details on IPFS or Arweave), and participate in challenges. Use libraries like ethers.js or viem to interact with your contracts. Always display the staking requirements and challenge deadlines clearly to users.

Consider advanced features to improve utility. Continuous approval voting (like in Curve's gauge weights) can allow token holders to continuously allocate votes to models, dynamically ranking them. Delegation mechanisms, as seen in ERC-20Votes, let users delegate their voting power. For model metadata, standardize a schema (inspired by OpenAI's model cards) that includes performance metrics, training data provenance, and intended use cases, stored decentralized to ensure integrity and transparency.

Before mainnet launch, conduct rigorous testing. Deploy to a testnet like Sepolia or Holesky and simulate challenge scenarios. Use a forking test with Foundry to test governance interactions against live price feeds. Audit the economic incentives to prevent attacks like bribe attacks or nothing-at-stake problems. Finally, plan the initial token distribution—consider a fair launch or allocation to early AI contributors—to bootstrap a dedicated community of curators essential for the registry's long-term quality and success.

IMPLEMENTATION

Code Examples and Snippets

Smart Contract Foundation

A Token-Curated Registry (TCR) for AI models is built on a smart contract that manages a list of approved entries. The core functions include submitting a model, challenging a submission, and voting on challenges. Here's a basic structure using Solidity 0.8.x.

solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

contract AITokenCuratedRegistry {
    address public governor;
    IERC20 public stakeToken;
    uint256 public submissionDeposit;
    uint256 public challengePeriodDuration;

    struct ModelSubmission {
        string modelId; // e.g., Hugging Face repo path
        string metadataURI; // IPFS hash for model card
        address submitter;
        uint256 deposit;
        uint256 submissionTime;
        bool isChallenged;
        uint256 challengeId;
    }

    mapping(string => ModelSubmission) public submissions;
    string[] public approvedModels;

    constructor(
        address _stakeToken,
        uint256 _submissionDeposit,
        uint256 _challengePeriodDuration
    ) {
        governor = msg.sender;
        stakeToken = IERC20(_stakeToken);
        submissionDeposit = _submissionDeposit;
        challengePeriodDuration = _challengePeriodDuration;
    }

    function submitModel(string memory _modelId, string memory _metadataURI) external {
        require(submissions[_modelId].submitter == address(0), "Model already submitted");
        require(stakeToken.transferFrom(msg.sender, address(this), submissionDeposit), "Deposit failed");

        submissions[_modelId] = ModelSubmission({
            modelId: _modelId,
            metadataURI: _metadataURI,
            submitter: msg.sender,
            deposit: submissionDeposit,
            submissionTime: block.timestamp,
            isChallenged: false,
            challengeId: 0
        });
    }
    // ... Additional functions for challenge, vote, resolve
}

Key Components:

Stake Token: A governance token (like the registry's native token or a stablecoin) used for deposits.
Submission Deposit: The amount a model submitter must lock, which is forfeited if their submission loses a challenge.
Challenge Period: A time window (e.g., 7 days) during which any token holder can dispute a new submission.
Model Metadata: Stored off-chain (e.g., on IPFS via Pinata or Filecoin) to keep on-chain costs low.

TOKENOMICS DESIGN

Key Economic Parameters and Configuration

Comparison of core economic models for a TCR governing AI model quality, including staking, slashing, and reward distribution.

Parameter	Curated Registry (Base)	Work Token Model	Reputation-Weighted Voting
Staking Token	Native TCR Token	Native Work Token	Reputation Points (Non-Transferable)
Listing Deposit	500-2000 TCR	1000-5000 Work Tokens	N/A
Challenge Bond	150% of Deposit	200% of Deposit	Reputation Slash (e.g., -100 pts)
Voting Period	3-7 days	5-10 days	2-5 days
Successful Challenger Reward	50% of Slashed Deposit	30% of Slashed Deposit + Work Rewards	Reputation Boost (+50 pts)
Voter Rewards	Proportional to Staked Vote	Work Token Emissions	Reputation-Based Airdrops
Slashing for Bad Votes
Inflation Rate for Rewards	2-5% annual	5-15% annual	0% (Non-Inflationary)

frontend-integration

FRONTEND AND USER INTERFACE

Launching a Token-Curating Registry for AI Models

This guide covers building the user-facing application for a token-curated registry (TCR) that governs AI model submissions, challenges, and voting.

A Token-Curated Registry (TCR) for AI models is a decentralized application where the list of approved models is governed by token holders. The frontend is the primary interface for three key user flows: model submission by developers, challenge initiation by critics, and voting by token holders on disputes. Unlike a simple list, this UI must clearly communicate complex governance states—such as whether a model is listed, challenged, or pending—and manage user interactions with smart contracts for staking tokens. The design must prioritize transparency and ease of participation to ensure a healthy, adversarial curation process.

The core technical stack typically involves a React or Next.js frontend connected to a blockchain via libraries like ethers.js or viem. You'll need to interact with at least three main smart contract functions: apply() to submit a model with a deposit, challenge() to dispute a listing, and vote() to resolve challenges. A robust frontend will also index and display event logs from these transactions to maintain an up-to-date view of the registry's state. Using a subgraph from The Graph or a similar indexing service is highly recommended to efficiently query model details, challenge histories, and voting results without overloading the frontend with complex chain queries.

For the submission flow, create a form that captures essential AI model metadata: the model's name, a link to its weights (e.g., on Hugging Face or IPFS), a description, and the required application deposit. Upon submission, the UI should trigger a wallet transaction, show a pending state, and confirm the transaction receipt. It's critical to then listen for the _Application event from the TCR contract to update the UI, showing the new model in a "pending application" phase where it can be challenged. Error handling for rejected transactions or insufficient deposits is essential here.

The challenge and voting interface is where governance happens. When a listed model is displayed, an option to Challenge should be visible, initiating another transaction with a stake. Once a challenge is active, the UI must present a clear voting panel for token holders. This includes displaying the commit-reveal period timers if your TCR uses that pattern, showing current vote tallies, and allowing users to commit their votes. After the vote resolves, the interface should update to reflect the outcome—either the model remains listed with the challenger losing their stake, or it is removed with the applicant losing theirs.

Finally, consider advanced UX improvements. Implement real-time updates using WebSockets or polling to reflect state changes from other users. Provide detailed history panels for each model, showing all past challenges and votes. Since gas fees can be a barrier, clearly display all required deposit amounts and potential financial outcomes (losses/gains) before users sign transactions. By building a transparent, informative, and responsive interface, you lower the participation barrier and foster a more active and effective decentralized community for curating AI models.

resource-links

DEVELOPER GUIDES

Resources and Further Reading

These resources cover the on-chain primitives, governance frameworks, and off-chain tooling required to launch a Token-Curated Registry (TCR) for AI models. Each card focuses on a concrete component you can integrate into a production system.

Token-Curated Registries (TCRs): Core Mechanism

A Token-Curated Registry is the economic backbone of many decentralized curation systems. It uses token staking and challenges to maintain a high-quality list without centralized gatekeepers.

Key mechanics you need to implement:

Candidate submission: AI model providers stake tokens to propose inclusion.
Challenge period: Any token holder can challenge a listing by staking an equal or greater amount.
Voting and resolution: Token-weighted voting determines acceptance or rejection.
Incentive alignment: Correct votes are rewarded from slashed stakes.

For AI model registries, common extensions include:

Linking entries to immutable model hashes (IPFS or Arweave).
Requiring evaluation artifacts such as benchmark scores or safety reports.
Using escalating stake sizes to discourage spam submissions.

This conceptual foundation should be locked down before selecting smart contract tooling or governance frameworks.

Kleros: Decentralized Arbitration for TCR Disputes

Kleros provides decentralized arbitration that plugs directly into TCR-style contracts. It is commonly used to resolve subjective disputes, which are unavoidable when curating AI models.

How Kleros fits into an AI model TCR:

Dispute resolution when a model’s claims (accuracy, license, safety) are contested.
Juror selection using token staking and random draws.
Appeals process for high-stakes registry decisions.

Practical integration steps:

Deploy a TCR contract that references a Kleros arbitrator address.
Define clear evidence requirements such as evaluation logs or reproducibility scripts.
Tune appeal fees to balance cost and correctness.

Kleros is especially useful when model quality or alignment cannot be reduced to a single on-chain metric.

EXPLORE

Aragon OSx: DAO Governance for Registry Parameters

Aragon OSx provides modular DAO infrastructure for managing the governance layer around a TCR. While the registry logic can be autonomous, parameters often need human coordination.

Common DAO-controlled parameters:

Minimum stake size for AI model submissions.
Challenge windows and voting durations.
Accepted evaluation standards or benchmark suites.

Implementation pattern:

Use Aragon’s Token Voting or Multisig plugins to manage upgrades.
Keep the TCR contract immutable while allowing DAO-controlled parameters via a config contract.
Publish governance proposals explaining parameter changes with historical performance data.

This approach separates day-to-day curation incentives from long-term protocol governance.

EXPLORE

OpenZeppelin Governor: Custom Voting Logic

OpenZeppelin Governor contracts are a low-level option if you need custom governance logic tightly coupled to your TCR.

Why use Governor for AI registries:

Full control over voting power calculation (token balance, quadratic voting, reputation).
Ability to gate votes based on model usage, staking history, or evaluator roles.
Compatibility with existing ERC20 and ERC721 tokens.

Typical architecture:

TCR contract handles listings and challenges.
Governor contract controls upgrades, parameter changes, or emergency actions.
Timelock enforces delays on sensitive changes.

This route requires more engineering effort but is suitable for registries with novel incentive designs or research-driven governance experiments.

EXPLORE

IPFS: Verifiable Storage for AI Model Artifacts

IPFS is commonly used to store AI model binaries, evaluation reports, and metadata referenced by a TCR. The registry itself should only store content hashes.

Best practices for AI model registries:

Store model weights, configs, and licenses off-chain on IPFS.
Pin critical artifacts using a pinning service or Filecoin deals.
Reference immutable CID hashes in the TCR entry.

For evaluation-heavy workflows:

Publish benchmark results and scripts as separate IPFS objects.
Require reproducibility metadata as part of the submission process.

This ensures the registry remains lightweight while preserving verifiable access to large AI assets.

EXPLORE

TCR DEVELOPMENT

Frequently Asked Questions

Common technical questions and solutions for developers building token-curated registries for AI models on-chain.

A Token-Curated Registry (TCR) is a decentralized list where curation rights are governed by a native token. Stakeholders use tokens to vote on which items (in this case, AI models) are included or removed from the list. For AI models, a TCR creates a decentralized marketplace of verifiable quality.

How it works:

Submission: A developer stakes tokens to propose adding their AI model (with metadata like hash, framework, license) to the registry.
Challenge Period: Other token holders can challenge the submission by matching the stake, triggering a vote.
Voting: Token holders vote to accept or reject the submission/challenge. Voters are rewarded from the loser's stake.
Inclusion/Removal: Winning submissions are listed; losing ones are removed, and their stake is distributed.

This mechanism uses cryptoeconomic incentives to align model quality with the token's value, filtering out low-quality or malicious AI models.

conclusion

IMPLEMENTATION SUMMARY

Conclusion and Next Steps

You have successfully built the core components of a Token-Curated Registry (TCR) for AI models. This guide covered the essential smart contracts, governance mechanisms, and integration patterns required for a functional, decentralized curation system.

Your deployed TCR now provides a foundational framework for communities to curate AI models. The system uses TCRRegistry.sol for core listing logic, a staking contract for economic security, and a voting mechanism for collective decision-making. The next critical phase is security auditing. Before mainnet deployment, engage a reputable firm like Trail of Bits or OpenZeppelin to review your contracts for vulnerabilities in the staking, voting, and challenge logic. A thorough audit is non-negotiable for a system holding user funds.

Following a successful audit, focus on frontend and user experience. Build a dApp interface that allows users to easily: submit new model listings (with metadata like framework, task, and dataset hash), browse the curated registry, stake tokens on submissions they support, and participate in challenge rounds. Consider integrating with IPFS (via Pinata or web3.storage) for decentralized model metadata storage and with oracles like Chainlink for fetching off-chain verification data.

To grow your TCR, you need a sustainable tokenomics and governance model. Determine initial parameters: the MIN_STAKE required for listing, the CHALLENGE_PERIOD duration, and the reward/penalty slashing rates. These should be calibrated to discourage spam while encouraging quality submissions. Plan for a phased launch, perhaps starting with a whitelisted set of curators before opening to the public. Establish clear community guidelines and documentation for submitters.

Finally, explore advanced integrations to increase utility. Your TCR can become a trusted data source for other protocols. For instance, an AI inference marketplace could query your registry to only serve vetted models. DeFi platforms could use the curation signal for novel collateral types. Monitor the performance of listed models using tools like Weights & Biases or custom scripts, and consider adding performance-based re-curation cycles to the governance process.

The architecture you've built is a starting point. The real value emerges from the community that uses it. Actively engage with AI researchers and developers, iterate on the governance parameters based on real usage data, and consider forking and adapting the code for other curated registries (datasets, research papers, prompts). The code for this guide is available on the Chainscore Labs GitHub for further exploration and contribution.