🚀 Summary

What if every Waves project had its own AI expert, one that knows its documentation, understands its logic, and can even read the blockchain in real time? This is what we’re building: a full ecosystem of intelligent agents for Waves and Unit Network, powered by OpenAI, LibreChat, and a growing library of modular knowledge bases.

Each agent has:

• Its own knowledge base (vector store hosted on OpenAI),
• A dedicated Express backend instance,
• Custom logic to handle technical or contextual queries efficiently,
• Live blockchain connectivity through MCP servers (Model Context Protocol).

The goal: give every Waves project its own AI-powered interface, accessible directly through a common UI, all while keeping knowledge modular, open, and continuously updated.

🌊 Why We Built This

The Waves and Unit Network ecosystems are full of powerful, innovative projects , from DeFi protocols and DAOs to AI-powered infrastructure and NFTs.

But for new users, developers, or even teams, accessing each project’s documentation, understanding its logic, or keeping up with updates isn’t always easy.

So we set out to build a network of autonomous AI agents, each specialized in a specific project and capable of:

• Understanding its full documentation,
• Answering technical questions,
• Fetching real-time blockchain data from Waves nodes.

All within one unified, open-source interface.

This entire initiative is funded and supported by the Waves DAO, built for the Waves + Unit Zero ecosystem.

🧠 Part 1: Automated Knowledge Base Generation

Every project in the ecosystem, Waves, Unit Zero, Block AI, Arkimals, WX Network, Swop, Puzzle, Power now has its own structured knowledge base.

We developed a Node.js script that automatically extracts and processes documentation from multiple sources:

• GitBook docs,
• Technical PDFs,
• HTML pages.

The script cleans the data, converts it into Markdown via TurnDown (or Jina), then enhances and restructures it using ChatGPT, ensuring a well-formatted, readable, and hierarchy-aware knowledge document , ready to be embedded into a dedicated vector store.

For projects that don’t yet have formal documentation, we strongly recommend GitBook.
Our Knowledge Base tool is specifically optimized for GitBook, since most Waves and Unit Network projects already use it.
GitBook ensures a smooth and automated integration, allowing our system to continuously extract and structure new content for each project’s agent.

Each project then has two knowledge-base versions:

• Full → detailed technical context.
• Summary → concise information for fast lookup.

🔗 Independent Vector Stores hosted on OpenAI

Each knowledge base is stored as its own isolated vector store on OpenAI — meaning every project’s data is separated, secure, and individually addressable.

While these stores are hosted under our OpenAI account, each project can request dedicated API access to its own vector store, allowing it to reuse its knowledge base in its own applications or integrations.

In practice, this setup ensures that:

• Each project’s data remains independent and protected,
• The infrastructure is centrally managed but project-specific,
• And teams can build directly on top of their agent’s knowledge if they wish.

This isn’t decentralized in the blockchain sense, but it’s modular, transparent, and designed to give each project control and flexibility over its own AI foundation.

This is the foundation of every agent: its memory.

⚙️ Part 2: An Express Backend that Spawns One Agent per Project

Once the knowledge bases are ready, we built a central Express backend that connects to LibreChat via custom endpoints.

This backend spawns a dedicated AI agent instance per project, each configured with:

• Its own vector store,
• Custom system instructions,
• Optional MCP servers for live data access.

Currently, the ecosystem includes:

• Waves
• Unit Zero
• Block AI
• Arkimals
• WX Network
• Swop
• Puzzle
• Power

Each agent is independent yet part of a shared, scalable architecture, forming a network of autonomous project-level experts.

Smart Model Selection

To optimize performance and cost:

• GPT-5 is used for technical or code-related queries,
• GPT-4-mini handles simpler, contextual questions.

This hybrid logic ensures faster responses and lower cost, without compromising quality.
All interactions are streamed in real time for a smoother experience.

💬 Part 3 : LibreChat Integration: One Interface, Many Agents

On the frontend, everything is unified within LibreChat, the open-source chat interface that serves as a single hub for all agents.

Each project appears as a custom AI endpoint in the LibreChat configuration, meaning users can:

• Select the Waves Agent, the Puzzle Agent, etc.,
• Ask technical or conceptual questions,
• And even switch agents mid-conversation while keeping the full context.

Example:
You start chatting with the Waves agent about smart accounts.
Halfway through, you have a question about PuzzleSwap.
You can switch to the Puzzle agent, and your next message goes to it , with the entire conversation context preserved.

This makes multi-project exploration seamless, many agents, one chat environment.

A Beta Open to the Ecosystem

This version is already live, but it’s still evolving.
Each agent is currently only trained on its public official documentation, but the next step is to work directly with project teams to:

• Expand their knowledge bases,
• Add private or advanced documentation,
• And refine the AI responses.

We invite all Waves ecosystem projects to reach out if they want to:

• Create their own AI agent,
• Add or update their documentation,
• Connect a custom MCP to their protocol,
• Or discuss any custom AI needs around their project, from specialized integrations to private AI tooling.

🌐 Part 4 : Connecting Agents to the Blockchain with MCP Servers

The next step is to give agents live on-chain awareness.
We’ve started developing MCP (Model Context Protocol) that connect agents directly to Waves blockchain data.

Waves Node API MCP

The first module, Waves Node API MCP, lets agents query the Waves node directly for real-time on-chain data like:

• Balances,
• Transactions,
• Data entries,
• Smart contract states, and more.

It’s still in development and currently supports only a few endpoints.
The goal is to cover all relevant Waves Node API endpoints, allowing agents to blend static knowledge with live blockchain insight , offering explanations, simulations, and real-time analysis.

Upcoming MCPs

After Waves, several other MCPs could be considered, for example:

• Puzzle AMM MCP → live liquidity, price and pool data etc from PuzzleSwap.
• Power DAO MCP → on-chain governance and proposal insights.
• WX / Swop MCPs → real-time liquidity, prices, and volume.

Each new MCP expands the ecosystem’s capabilities, turning agents from static assistants into interactive blockchain interfaces.

Automated Knowledge Base Updates

Another major step underway is automatic Knowledge Base regeneration.
We’re adding a cron-based task system that checks each project’s official documentation (e.g., GitBook) daily.
Whenever a change is detected, the corresponding knowledge base is regenerated and updated automatically.

This makes the system dynamic and self-maintaining, agents always stay in sync with the latest project documentation.

Even better, it empowers project teams: they can simply update their docs, and their AI agent will improve automatically within hours, no manual update required.

🚀 Toward a Unified AI + Blockchain Ecosystem

This Waves-funded initiative is a first step toward a future where:

• Every protocol in the Waves and Unit Network ecosystem has its own specialized AI agent,
• All are accessible through LibreChat for users or API for project team,
• And each can pull real-time blockchain data through its MCP integrations.

It’s a living, modular, and collaborative AI network, built by and for the Waves community.

Agents for Waves, Unit0, Block AI, Arkimals, WX, Swop, Puzzle, and Power are already live.

💡 Part of the Waves Ecosystem?

If you’re building on Waves or Unit Network:

➡️ Publish your GitBook docs,
➡️ Get your own AI agent integrated into LibreChat,
➡️ Or reach out to discuss custom AI integrations and features tailored to your project.

Together, we can give your project an intelligent voice , powered by the Waves AI ecosystem.

BlockAI Team

BlockAI Website | Twitter | Telegram | Reddit | Linkedin

Introduction to QOC and MCP

In the rapidly evolving landscape of AI-assisted decision-making, two concepts have emerged as game-changers: QOC (Question–Option–Criteria) and the Model Context Protocol (MCP). While they originate from very different problem spaces, they share a common goal in enabling intelligent systems to produce better, more grounded, and more transparent answers.

What is QOC?

At its core, QOC is a general framework for distributed decision-making. Imagine you could present any question to a system and receive not just a single answer, but a structured decision process that breaks down how that answer was reached. QOC does exactly that.

It starts with the Question, the problem you want to solve. From there, it generates multiple Options understood as possible answers or solutions. Then comes the Criteria, the factors that matter when deciding between the identified options. These criteria are weighted according to their importance, and each option is evaluated on how well it meets the given criteria.

With these elements in place, QOC makes the decision process explicit: a formula can be applied to the criteria weights and the evaluations to calculate a preferred option. The result is a transparent, explainable choice, one that can be challenged and refined. The best of this approach is, it could be fully automated, thanks to AI.

QOC’s power lies in its flexibility. It’s not tied to a single domain, it can help a community decide on a policy change, guide an engineer toward the best technical architecture, or even assist a user in picking their next holiday destination. In essence, it’s a universal blueprint for rational decision-making.

What is MCP?

If QOC is about how to make decisions, the Model Context Protocol (MCP) is about how to connect decision-making systems to the real world.

Released by Anthropic at the end of 2024, MCP has quickly become the de facto standard for letting Large Language Models (LLMs) access live data and trigger actions beyond their training set. In the early days of AI assistants, models were confined to what they “knew” at training time. MCP changed that, it opened the door for AI to interact with APIs, databases, and even custom workflows in a standardized, secure way.

Today, MCP is supported by most major LLM platforms, making it the easiest, most future-proof way to integrate AI agents into existing systems. It acts as a bridge: the client of the Large Language Model speaks MCP, the outside world speaks its native protocols, and MCP translates between them.

By pairing QOC’s structured reasoning with MCP’s universal connectivity, we get something powerful: a decision-making framework that can not only think clearly but also act meaningfully within any connected ecosystem.

BlockAI’s implementation of the QOC process

BlockAI has already taken QOC from theory to practice. In fact, the QOC process has been live in their decentralized application (dApp) for some time now, a detailed early write-up can be found in our previous article. With the introduction of the QOC MCP server, this proven framework is now available to any LLM or MCP-compatible client that wants to tap into structured, explainable decision-making.

The approach follows a multi-agent decision-making model:

1. Understanding the Question and Context
   Every decision process starts when a user (or another system) submits a question along with a description of the context in which it should be answered. Context is key as it shapes how the system identifies relevant factors and who should be “in the room” when the decision is made.
2. Identifying Stakeholders as Agents
   The system’s first task is to determine the stakeholders whose perspectives matter for the question at hand. These stakeholders are represented as Agents, autonomous participants with their own viewpoints, priorities, and domain knowledge.
3. Generating Options and Criteria
   Each Agent is then asked two things:
   - What are the possible Options for answering the question?
   - Which Criteria are important for deciding between those options?These inputs reflect each Agent’s unique perspective, which means the system captures diversity in both solutions and decision factors.
4. Consolidating the Inputs
   Naturally, multiple Agents may propose similar options or criteria. In this step, the system merges duplicates and harmonizes wording so that the decision space is clear and coherent.
5. Weighting Criteria and Evaluating Options
   After consolidation, Agents assign weights to each criterion (reflecting importance) and scores to each option for how well it meets that criterion. This ensures that all perspectives are quantified and directly comparable.
6. Calculating the Preferred Option
   The system then applies the QOC formula, adapted for a multi-agent environment, to determine the preferred option. The formula integrates the criteria weights and the option scores into a single, transparent ranking.
7. Statistical Analysis for Comparable Choices
   Beyond finding the top choice, BlockAI’s implementation also runs statistical checks to identify other options that perform similarly well. This avoids tunnel vision and surfaces alternatives worth considering.

The output from the QOC MCP server is therefore much richer than a simple “best guess.” It includes:

• The preferred option
• A list of similarly strong alternatives

This makes it possible for any connected AI system — or even a human decision-maker — to see not just the “what,” but the “why” behind a recommendation.

Why does it make sense?

Most Large Language Models are excellent at producing plausible answers to a question, but they typically do so from a single, generalized perspective. This can be useful for quick, broad responses, but it leaves out something crucial: the diversity of viewpoints that real-world decision-making often requires.

BlockAI’s QOC MCP server changes that equation. By introducing multiple Agents, each representing a distinct stakeholder, the decision process becomes richer and more balanced. Instead of relying on one monolithic answer, the system synthesizes different perspectives, providing a critical advantage when questions have no single “right” solution, but many possible trade-offs.

Beyond its inclusivity, the QOC process is anchored in a mathematical model of decision-making. This isn’t just AI “guessing” what might work, but applying a well-defined formula that combines:

• Weighted criteria (what matters most)
• Option evaluations (how well each choice meets each criterion)
• Aggregation across multiple agents’ viewpoints

This structured approach delivers transparent, reproducible results that can be audited and improved over time.

And it doesn’t stop at finding the top-ranked answer. The process applies robust statistical methods to detect options that perform similarly well. This ensures that equally viable alternatives aren’t overlooked, which provides a valuable safeguard in scenarios where flexibility matters or where the top choice might later become infeasible.

When delivered through MCP, the benefits become even more compelling:

• Easy integration: Any LLM that supports MCP can tap into this decision process as if it were a native capability.
• Seamless conversation: A user can be chatting with an AI assistant, triggering the QOC process, and receive a structured, multi-agent, mathematically rigorous answer without ever leaving the conversation.

In short, this isn’t just about giving an AI more data, it’s about giving it a decision-making superpower that combines human-like diversity of thought with the precision of formal analysis.

Technical integration

One of the strengths of the QOC MCP server is that it doesn’t require a custom integration for every platform. Instead, it uses the standard Model Context Protocol (MCP) — meaning that any client, agent, or platform already supporting MCP can connect to it out of the box.

This design choice dramatically lowers the barrier to adoption. If your AI assistant, developer tool, or orchestration framework can speak MCP, it can immediately start leveraging multi-agent, mathematically rigorous decision-making without additional glue code or complex adapters.

Handling Longer Evaluations

Because the QOC process involves multiple agents, criteria weighting, statistical analysis, and sometimes more extensive reasoning, some evaluations may take longer than typical API calls. To ensure smooth operation, it’s recommended to increase the default timeout settings when configuring the server in your MCP client.

Example Configuration

Here’s a ready-to-use configuration snippet for connecting to our QOC MCP server:

{
  "mcpServers": {
    "qoc-mcp": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://qocmcp.blockai.dev/sse"
      ],
      "env": {
        "MCP_SERVER_REQUEST_TIMEOUT": "1200000",
        "MCP_REQUEST_MAX_TOTAL_TIMEOUT": "1200000"
      }
    }
  }
}

In this example:

• MCP_SERVER_REQUEST_TIMEOUT and MCP_REQUEST_MAX_TOTAL_TIMEOUT are both set to a higher value (in milliseconds) to accommodate more complex evaluations.
• The mcp-remote command is used to connect to the public QOC MCP endpoint.
• Once connected, the client can trigger the QOC process and receive structured, explainable results without further configuration.

With this setup, any MCP-compatible AI system can embed BlockAI’s QOC process into its conversational flow, making deep, stakeholder-inclusive decision-making as accessible as asking a question.

Difference between the QOC dApp and the MCP implementation

While the QOC MCP server and the QOC dApp share the same underlying agent framework and mathematical decision model, they are built with different priorities in mind.

The QOC dApp is designed for maximum transparency. It doesn’t just tell you what the preferred option is, but it opens the entire decision process for inspection. Users can see:

• Which agents participated
• What options and criteria they proposed
• How criteria were weighted
• How each option was scored
• How coherent the evaluations were — both in terms of criteria weights and the evaluations of how well each option supports each criterion. This allows the dApp to highlight where agents shared a common perspective and where their views diverged, offering a richer understanding of consensus or disagreement within the group.
• How the final calculation was made

This makes the dApp ideal for high-stakes, business-critical decisions, where explainability is not just a nice-to-have but a requirement. In such scenarios, being able to audit, challenge, and refine the AI-driven decision is as important as the decision itself. The dApp provides a clear path for explainable AI in distributed, fully automated decision-making.

The QOC MCP server, on the other hand, focuses on seamless integration into ongoing conversations, such as those happening between a user and an LLM. While it delivers the preferred option and also highlights statistically equivalent alternatives, it does not expose every intermediate step in the same way the dApp does.

This trade-off makes sense:

• In an LLM conversation, users often need a quick, decisive answer that fits into the flow of dialogue. The MCP version delivers exactly that, without overloading the interaction with excessive detail.
• In a business or governance setting, the dApp offers the depth and transparency needed for accountability and trust.

In short: MCP for integration and speed; dApp for transparency and deep dives. Both use the same solid, multi-agent, mathematically grounded foundation — they just optimize for different contexts.

BlockAI Team

BlockAI Website | Twitter | Telegram | Reddit | Linkedin

Decentralized Autonomous Organizations (DAOs) promised a future of open, community-led governance, but in practice, many suffer from vote manipulation, lack of transparency, and binary decisions that reveal little about community sentiment. What if DAO decision-making could move beyond simple “yes” or “no” tallies and instead capture the reasoning behind every vote?

In this article, we introduce a new governance approach for DAOs based on the Question–Option–Criteria (QOC) model. By breaking decisions into clear questions, predefined options, and weighted criteria, QOC enables decisions that are not only more transparent but also more resistant to manipulation. We explore how this model can be applied to existing DAO structures, how it can evolve into more flexible multi-option governance, and how statistical safeguards can improve fairness. Finally, we look ahead to the possibility of AI-driven DAOs, where intelligent agents help assess proposals and guide decision-making with data-backed insights.

The result? A governance model that captures what the community decides and, for the first time, why it decides it.

Some problems of Decentralized Autonomous Organizations

Over the last few years, Decentralized Autonomous Organizations (DAOs) have promised a new era of community-driven governance. The idea is simple: distribute decision-making power across a network of participants, eliminating centralized control and giving every token holder a voice. In practice, however, the reality often falls short of this ideal.

One of the most pressing issues in current DAO governance models is vote manipulation. Because voting power is typically proportional to the number of tokens held, whales can easily sway decisions in their favor. Even well-intentioned governance proposals can be derailed or pushed through simply because a few powerful players control a majority of the votes. This creates an imbalance that undermines the democratic promise of DAOs.

Beyond the influence problem, there’s a severe lack of transparency around why a decision was made. Most DAOs boil down decision-making to a binary choice: “yes” or “no.” Once the vote is over, all the community sees are the final tallies. There’s no deeper insight into the reasoning behind the votes, no record of the criteria that mattered most to participants, and no way to understand the diversity of perspectives within the community.

This binary nature of DAO voting also means that projects lose the opportunity to capture nuanced community sentiment. If a proposal fails, it’s impossible to tell whether it was because of disagreement with the overall concept, concerns about specific implementation details, or dissatisfaction with timing or resource allocation. Without this understanding, projects can’t adjust their plans in ways that address the real concerns of their community members. Instead, valuable feedback is lost, replaced by a highly abstracted result: “passed” or “rejected.”

The result is a governance system that, while decentralized in theory, often struggles with fairness, inclusivity, and actionable transparency in practice.

Introduction to the QOC model

The Question–Option–Criteria (QOC) model is a structured approach to decision-making that can be applied to almost any governance scenario, including those in Decentralized Autonomous Organizations (DAOs). It provides a clear framework for turning complex, often emotionally charged debates into transparent, well-documented decisions.

The process starts with the formulation of a clear question. In a DAO, this might be: “Should we fund the development of a new feature?”, “Should the community treasury invest in a specific protocol?”, or “Should we adjust the staking reward parameters?” By framing the question precisely, participants share a common understanding of what’s being decided before the voting begins.

Once the question is defined, the next step is to identify the options — in many DAO contexts, these boil down to accepting or rejecting a proposal. However, QOC ensures that even in a binary vote, the reasoning is richer than a simple “yes” or “no.”

The real strength of QOC lies in capturing criteria , the factors that should influence the decision. In a DAO setting, these might include budget constrints, potential return on investment, security implications, community alignment, or the expected impact on ecosystem growth. QOC also allows these criteria to be weighted according to their importance in the current context, making priorities explicit.

Each option is then evaluated against every criterion. Participants assess how strongly an option supports or conflicts with a criterion, creating a transparent map of trade-offs and benefits.

Finally, QOC combines the importance weight of each criterion with the support score of each option to calculate the preferred choice. The outcome is a decision backed by structured reasoning, not just token-weighted votes — and with a clear record of why the community chose that path.

How to apply the QOC model to DAO’s

While the QOC model is flexible enough to handle complex, multi-option decisions, the first implementation for DAOs should remain close to familiar territory. To ensure adoption, we propose starting with the same basic voting structure most DAO members already know: yes/no decisions. For example, a project team might submit a proposal requesting funding, and the DAO would choose between fund or do not fund.

Over time, this binary setup could evolve into something more versatile. Instead of voting on a single proposal in isolation, the community might answer broader questions such as “How should we allocate this quarter’s treasury?” In such a case, the options could include several projects, liquidity provisioning for trading pairs, or other strategic investments. But for the early stages, keeping the model simple will make it easier for members to understand and adopt.

A key design choice for applying QOC to DAOs lies in how criteria are defined and weighted. There are two main paths forward:

1. Predefined, fixed set of criteria. The DAO maintains a consistent list of decision factors (e.g., return on investment, ecosystem impact, security risk) along with predetermined weights that indicate their relative importance.
2. Flexible, vote-specific criteria. For each proposal, the community defines which criteria matter most and assigns the weights before voting.

Both approaches have merit, but for an initial rollout, we recommend starting with a predefined set of weighted criteria. This keeps the learning curve low and avoids the overhead of redefining decision factors for every proposal. Once the community is comfortable with the process, the model could expand to allow for more tailored sets of criteria on a per-vote basis.

In the initial version, the voting process would look like this:

• The DAO presents the proposal and the predefined criteria.
• Community members evaluate how well each option supports each criterion, using a scoring scale (e.g., from “strongly supports” to “strongly conflicts”).
• These scores, combined with the fixed criterion weights (see figure 1), determine the final outcome, a decision that reflects structured reasoning rather than raw token counts.

By starting simple and gradually introducing complexity, the QOC model can integrate seamlessly into DAO governance while setting the stage for more sophisticated decision-making in the future.

Increase of transparency and fairness of DAO’s

Up to this point, we’ve looked at how the QOC model could be applied in a DAO context. But the true value of this approach lies in what it enables: greater transparency and improved fairness in governance.

The transparency benefits are straightforward. Since each vote records not just a final “yes” or “no” but also the evaluation of how well each criterion is supported, the DAO can produce a detailed decision report after every vote. This report would show, criterion by criterion, where the community saw strengths and where it saw weaknesses. For example, a proposal might be viewed positively on “ecosystem growth” but poorly on “security risk.” If the proposal is rejected, the project team can use this feedback to address the weak spots and amplify the positives before resubmitting. This transforms every vote into a source of actionable insight, rather than a binary verdict with no context.

The fairness aspect is more subtle but equally important. In traditional DAO voting, a single large token holder or a motivated group can dominate an outcome simply by casting votes in line with their interests. In QOC-based voting, manipulation is still possible, for example, a voter could deliberately score a disliked project poorly across all criteria or inflate scores for a favored project. However, because we capture all individual criterion evaluations, we can apply statistical safeguards to detect and mitigate extreme bias.

One simple yet powerful method is outlier detection. By comparing each voter’s criterion scores against the community average and measuring deviations (for instance, in terms of standard deviations from the mean, as shown in figure 2), it becomes possible to flag votes that are disproportionately extreme. The DAO could then choose to exclude these outlier votes from the final calculation. This creates a natural deterrent: members who attempt to game the system risk having their votes discounted entirely.

The combination of transparent reasoning and statistical safeguards shifts the governance dynamic. Instead of decisions being driven by sheer voting power, they are shaped by balanced, reasoned input from the community, with mechanisms in place to protect against manipulation. The result is a governance process that not only records what decision was made but also why it was made, giving DAOs the tools to evolve beyond opaque and imbalanced voting systems.

From QOC-Based Governance to AI-Driven DAOs

While the QOC model already offers significant improvements over traditional DAO voting, it also opens the door to something even more transformative: fully AI-driven governance.

In the current setup, human participants assess how well each option supports the predefined criteria. But many of these evaluations, especially those based on technical, financial, or on-chain data, could be handled by artificial intelligence. Imagine a DAO where, instead of every member manually scoring each criterion, an AI agent collects relevant data, analyzes the proposal, and produces an initial assessment for each criterion.

This AI-driven evaluation could be based on:

• On-chain analytics — e.g., assessing the historical ROI of similar proposals.
• Technical risk analysis — identifying security vulnerabilities or scalability concerns.
• Community sentiment analysis — scanning forums, social channels, and previous votes for qualitative insights.
• Economic forecasting — projecting the likely impact of a decision on token value or treasury health.

The role of the community could then shift from manually scoring every criterion to reviewing, validating, and adjusting AI-generated assessments, practicing a human-in-the-loop approach. In the long term, some DAOs might even allow the AI to make binding decisions autonomously, using human oversight only in exceptional cases of for decisions beyond a certain financial threshold.

This evolution would not only reduce the cognitive load on voters but also bring data-driven objectivity into the decision-making process. AI could help detect manipulation attempts, surface overlooked risks, and ensure that every decision is grounded in evidence rather than influence.

In this vision, the QOC model serves as a bridge, a structured governance framework that starts with human-driven transparency and fairness but is inherently compatible with a future where AI acts as an informed, impartial participant in decentralized governance.

BlockAI Team

BlockAI Website | Twitter | Telegram | Reddit | Linkedin

Introduction: A Simple Game, A Powerful Feature

Blockchain and AI integration is often abstract and difficult to visualize, especially when it involves asynchronous smart contract callbacks. To make this concept more tangible, we implemented TicTacToe on Base & BNB Chain — not because the game itself is complex, but because it provides an easy way to experience how BlockAI’s Smart Contract Callback Feature works in real-time.

This isn’t just about playing TicTacToe; it’s about demonstrating how smart contracts can trigger AI tasks, receive results asynchronously, and act on them automatically — just like any real-world decentralized application (dApp) using AI automation.

Through this game, players unknowingly interact with blockchain-based AI automation, a process that typically happens behind the scenes in more advanced use cases like decentralized marketplaces, AI-powered DAOs, or NFT generation.

How the Callback Feature Works in TicTacToe

Smart contracts on Base & BNB Chain cannot directly interact with AI models or external data sources. That’s why we use BlockAI’s Callback Mechanism to bridge the gap:

1. Player makes a move, and the smart contract checks if the game is over.
2. If no winner, the smart contract sends an AI task request to BlockAI’s contract, asking it to compute the next move.
3. An AI agent processes the request off-chain, determines the best move, and sends the result back to the smart contract.
4. The smart contract receives the AI-generated move via a callback function, updates the game state, and continues play.

Since this happens automatically and securely, it allows any dApp on Base & BNB Chain to leverage AI-powered decision-making without needing to build their own complex backend infrastructure.

TicTacToe as a Proof-of-Concept

We implemented TicTacToe because it’s a game everyone understands, making it easy to see the callback feature in action. The game mechanics demonstrate:

1. Players make a move → The contract validates it.
2. If no winner, the AI is asked to play → The contract registers an AI task.
3. AI calculates the best move off-chain → Sends the result back via a callback function.
4. Smart contract updates the board → The game continues until a winner is determined.

The callback function is secured, meaning only BlockAI’s contract can call it to prevent manipulation. This is enforced in the Solidity contract using:

function baiCallbackFunction(string calldata taskId, string calldata gameIdAndBoard) external onlyBaiContract { ... }

This prevents unauthorized parties from modifying the game state, ensuring fair gameplay.

Another key feature is move validation:

• Players can’t modify past moves or override the AI’s decisions.
• They must change exactly one position in the game board.
• Any invalid move is rejected to maintain game integrity.

This fully automates gameplay while enforcing fairness and security on-chain — the same principles that could apply to AI-enhanced finance, governance, or gaming.

Base & BNB Chain Smart Contract Implementation

The TicTacToe smart contract is implemented in Solidity and includes:

✅ AI Task Registration using registerTaskCallback().
✅ Automated Move Processing via a secure callback function.
✅ On-Chain Game State Management (board, turns, winner detection).
✅ Fee System for AI move generation, paid in $BAI tokens.

Each AI-powered move requires a small fee in $BAI tokens to cover processing costs. This ensures that AI computation is efficient and scalable within the ecosystem. The payment logic is handled in:

uint256 minFee = IBAIContract(baiContract).getPriceForType("tictactoe");
require(baiToken.transferFrom(msg.sender, address(this), minFee), "Fee transfer failed");

This means that players must send a small transaction when requesting an AI move, just like they would when calling any decentralized service.

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

import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol";
import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "@openzeppelin/contracts-upgradeable/utils/StringsUpgradeable.sol";

import "./baiMainContractInterface.sol";
import "./baiAccessControl.sol";


contract TicTacToe is Initializable, UUPSUpgradeable, OwnableUpgradeable, BAIAccessControl {

    using StringsUpgradeable for uint256;

    IERC20 public baiToken;          
    uint256 public winningAmount;     
 
    string constant PLAYER = "1";
    string constant AI = "2";
    
    struct GameState {
        string currentBoard; 
        string nextPlayer;   
        string winner;       
        address initiator;   
    }
    mapping(string => GameState) public games;
    
    
    function initialize(address _baiContract, address _baiToken) public initializer {
        __Ownable_init();
        __UUPSUpgradeable_init();
        baiContract = _baiContract;
        baiToken = IERC20(_baiToken);
        winningAmount = 5000000000000000000;
    }
        
    function checkIfMoveIsValid(string memory gameId, string memory board) internal view returns (bool) {
        string memory currentBoard = bytes(games[gameId].currentBoard).length == 0 ? "000000000" : games[gameId].currentBoard;
        bytes memory bBoard = bytes(board);
        bytes memory bCurrent = bytes(currentBoard);
        require(bBoard.length == 9 && bCurrent.length == 9, "Invalid board length");
        
        uint countMoves = 0;
        for (uint i = 0; i < 9; i++) {
            if (bBoard[i] != bCurrent[i]) {
                countMoves++;
                require(bCurrent[i] == bytes("0")[0], "Former position overwritten!");
            }
        }
        require(countMoves == 1, "Exactly one move must be made");
        
        return true;
    }
    
    function checkIfPlayerHasWon(string memory board, string memory player) internal pure returns (bool) {
        bytes memory bBoard = bytes(board);
        require(bBoard.length == 9, "Invalid board length");
        bytes1 p = bytes(player)[0];
        uint8[3][8] memory combos = [
            [0, 1, 2], [3, 4, 5], [6, 7, 8],      
            [0, 3, 6], [1, 4, 7], [2, 5, 8],      
            [0, 4, 8], [2, 4, 6]       
        ];

        for (uint i = 0; i < 8; i++) {
            if (bBoard[combos[i][0]] == p && bBoard[combos[i][1]] == p && bBoard[combos[i][2]] == p) {
                return true;
            }
        }

        return false;
    }
    
    function getPossibleMovesCount(string memory board) internal pure returns (uint) {
        bytes memory bBoard = bytes(board);
        uint count = 0;

        for (uint i = 0; i < bBoard.length; i++) {
            if (bBoard[i] == bytes("0")[0]) {
                count++;
            }
        }

        return count;
    }
        
    function splitGameIdAndBoard(string memory input) internal pure returns (string memory, string memory) {
        bytes memory b = bytes(input);
        uint index = 0;
        bool found = false;
        
        for (uint i = 0; i < b.length; i++) {
            if (b[i] == "_") {
                index = i;
                found = true;
                break;
            }
        }

        require(found, "Invalid input format");
        bytes memory part1 = new bytes(index);

        for (uint i = 0; i < index; i++) {
            part1[i] = b[i];
        }

        bytes memory part2 = new bytes(b.length - index - 1);

        for (uint i = index + 1; i < b.length; i++) {
            part2[i - index - 1] = b[i];
        }

        return (string(part1), string(part2));
    }    
    
    function baiCallbackFunction(string calldata taskId, string calldata gameIdAndBoard) external onlyBaiContract {
        (string memory gameId, string memory board) = splitGameIdAndBoard(gameIdAndBoard);
        GameState storage game = games[gameId];
        require(keccak256(bytes(game.nextPlayer)) == keccak256(bytes(AI)), "Player has to move first!");
        
        checkIfMoveIsValid(gameId, board);
        
        if (checkIfPlayerHasWon(board, AI)) {
            game.currentBoard = board;
            game.winner = "ai";
        } else {
            game.currentBoard = board;
            game.nextPlayer = PLAYER;
        }
    }
    
    function playTTT(string calldata gameId, string calldata board) external {
        uint256 minFee = IBAIContract(baiContract).getPriceForType("tictactoe");
        require(baiToken.transferFrom(msg.sender, address(this), minFee), "Fee transfer failed");
        require(baiToken.approve(baiContract, minFee), "Error setting allowance for BAI main contract");
        
        GameState storage currentGame = games[gameId];
        if (bytes(currentGame.currentBoard).length == 0) {
            currentGame.currentBoard = "000000000";
        }
        if (bytes(currentGame.nextPlayer).length == 0) {
            currentGame.nextPlayer = PLAYER;
        }
        if (currentGame.initiator == address(0)) {
            currentGame.initiator = msg.sender;
        } else {
            require(currentGame.initiator == msg.sender, "Only initiator is allowed to make moves");
        }
        require(keccak256(bytes(currentGame.nextPlayer)) == keccak256(bytes(PLAYER)), "AI has to move first!");
        
        checkIfMoveIsValid(gameId, board);
        currentGame.currentBoard = board;
        
        if (checkIfPlayerHasWon(board, PLAYER)) {
            currentGame.winner = "player";
            require(baiToken.transfer(msg.sender, winningAmount), "Winning transfer failed");
        } else if (getPossibleMovesCount(board) == 0) {
            currentGame.winner = "draw";
        } else {
            string memory data = string(abi.encodePacked(gameId, "_", board));
            IBAIContract(baiContract).registerTaskCallback(data, "tictactoe");
            
            currentGame.nextPlayer = AI;
            currentGame.winner = "none";
            currentGame.initiator = msg.sender;
        }
    }

    function getCurrentBoardForGame(string calldata gameId) external view returns (string memory board) {
        GameState storage currentGame = games[gameId];

        return currentGame.currentBoard;
    }

    function getWinnerForGame(string calldata gameId) external view returns (string memory board) {
        GameState storage currentGame = games[gameId];

        return currentGame.winner;
    }

    function setWinningAmount(uint256 _winningAmount) public onlyOwner {
        winningAmount = _winningAmount;
    }

    function _authorizeUpgrade(address newImplementation) internal override onlyOwner {}

}

Beyond TicTacToe: Real-World Applications of AI Callbacks

While TicTacToe serves as an engaging demonstration, this is just the beginning. The Smart Contract Callback Feature is a game-changer for any Web3 project looking to integrate AI-driven automation.

Imagine a decentralized application that not only executes predefined tasks but also adapts, learns, and makes intelligent decisions in real-time. With BlockAI’s callback mechanism, this vision becomes a reality.

Why settle for static smart contracts? Upgrade your dApp with AI-powered automation and bring intelligence to your blockchain applications.

Use Cases That Can Instantly Benefit from BlockAI AI Callbacks:

The possibilities for AI-powered blockchain automation are truly limitless. Below are just a few examples of how the Smart Contract Callback Feature can revolutionize Web3 applications:

✅ AI-Powered NFT Marketplaces — AI-generated assets dynamically minted and listed.
✅ Decentralized Autonomous Organizations (DAOs) — AI-driven voting, proposals, and governance analysis.
✅ DeFi & Trading Bots — AI-powered risk assessment and automated investment strategies.
✅ Metaverse & Gaming — AI-enhanced NPCs, real-time strategy computation, and procedural content generation.

Any Web3 project that needs AI-powered automation can integrate BlockAI’s callback mechanism to enhance smart contract logic — unlocking new possibilities for decentralized technology.

Try It Yourself & Start Building

With TicTacToe on Base & BNB Chain, you can experience blockchain-AI callbacks in action.

For a limited time, we’re boosting rewards in our TicTacToe game, giving you the chance to earn more $BAI tokens than ever before!

To make this event even more exciting, we’ve adjusted the AI to be more approachable, increasing your chances of winning.

This is the perfect opportunity to experience the game, test your skills, and boost your $BAI token balance. Don’t miss out! join the game now and take advantage of these special conditions before they’re gone!

Play now: base.blockai.dev & bnb.blockai.dev

This is a major step toward practical AI-blockchain integration, and we’re excited to see how developers expand on this concept.

🔹 Explore BlockAI Docs: docs.blockai.dev
🔹 Join the Community: Twitter | Telegram
🔹 Start Building AI-Powered dApps Today!

BlockAI Team

BlockAI Website | Twitter | Telegram | Reddit | Linkedin

1. B2C Approach: Web UI Access

This approach is ideal for individuals looking for an intuitive interface to leverage BlockAI’s suite of tools. Users can visit portals like bnb.blockai.dev or base.blockai.dev, connect their wallets, and access various AI-powered features, including:

• Text Generation (e.g., ChatGPT, Gemini etc.).
• Image Creation (e.g., DALL-E, Stable Diffusion etc.).
• Video Summarization.
• Brainstorming and Discussions.
• Upcoming QoC, TicTacToe Game etc.

Problems It Solves

This approach called the B2C, offering a Web UI access is designed to eliminate many of the barriers associated with traditional AI services:

• No Personal Data Required: Users interact via blockchain wallets, ensuring privacy and anonymity.
• No Monthly Subscriptions: Unlike conventional AI platforms, there are no recurring costs. Users only pay for what they need, when they need it.
• Ownership of Data: All task data is decentralized, allowing users to retain full control and ownership.
• Crypto-Only Payments: Payment is streamlined via cryptocurrencies, eliminating the need for fiat transactions and enabling global accessibility.
• One-Stop Access to Major AI Models and Tools: BlockAI provides access to multiple cutting-edge AI services (e.g., OpenAI’s ChatGPT, Google Gemini, Stable Diffusion etc.) under one platform. This eliminates the need to subscribe to multiple services individually, simplifying the user experience while reducing costs and administrative overhead.

Who is it for?

Ideal for individuals such as:

• Unbanked users or those who prefer crypto payments over traditional banking.
• People who don’t use AI frequently enough to justify a full monthly subscription.
• Users who want access to multiple AI services (e.g., ChatGPT, Stable Diffusion, Gemini etc.) without subscribing to each separately.
• Those drawn to BlockAI’s unique features, like AI Discussions, AI Brainstorming etc.

The Web UI is straightforward, requiring only a cryptocurrency wallet such as metamask, coinbase or walletconnect. It empowers users to interact with AI tools seamlessly, making advanced AI capabilities accessible to everyone.

2. B2B Approach: Smart Contract Callback Feature

Designed for developers and decentralized applications (dApps), this approach already available for any web3 project on a supported chain enables on-chain smart contracts to interact with off-chain AI systems. Since smart contracts cannot directly access off-chain resources, BlockAI bridges the gap through its Smart Contract Callback Feature.

How It Works

1. Initiating the Task:
A smart contract calls BlockAI’s contract using the registerTaskCallback method, providing:

• Description: The input or task description (e.g., a text prompt or video URL).
• Type: The AI service to be used (e.g., chatgpt, dalle, youtube).
• Callback: The callback function in the initiating contract where the AI-generated result will be returned. The function must accept a string parameter. For EVM the callback function name is pre-defined and fixed.

2. Task Execution:
BlockAI’s off-chain agent picks up the task, processes it using its AI models, and returns the output.

3. Result Delivery:
The processed result is sent back to the originating smart contract through the specified callback function, ensuring an automated and efficient workflow.

Use Cases ideas for the Smart Contract Callback Feature

1. Decentralized Marketplaces:
   NFT platforms can integrate AI tools to generate art on-demand via smart contracts, creating dynamic and unique assets.
2. Decentralized Autonomous Organizations (DAOs):
   DAOs can initiate brainstorming or discussion tasks for community decisions, receiving detailed outputs directly on-chain.
3. Gaming and Metaverse Applications:
   On-chain games can generate dynamic assets, storylines, or AI-driven NPC interactions through BlockAI’s callback mechanism.
4. Educational Platforms:
   Blockchain-based education platforms can leverage AI for video summarization, discussion analyses, or content creation, delivered directly to learners and educators.

Who is it for?

Perfect for Web3 projects looking to:

• Integrate AI directly into their on-chain logic without needing to develop, deploy, or manage custom AI agents, LLMs, or decentralized storage solutions.
• Create automated AI-driven workflows to enhance smart contract functionality while ensuring decentralization.

Exploring Two Examples of B2B Applications:

Example 1:
Project X Marketplace
Imagine a marketplace on a supported blockchain that introduces a “Surprise NFT Minting” feature. This allows users to generate an AI-created image and list it for sale immediately as an NFT. Marketplace X can implement this feature effortlessly by integrating a dapp-to-dapp call to the BAI Smart Contract.

Here’s how it works:

1. A user calls a new method, mintRandomNFT(), on Marketplace X’s smart contract with parameters like the prompt for the image (e.g., “Create a photorealistic image of a toddler riding a cat turtle”) and the AI model (e.g., stable-diffusion):

mintRandomNFT("Create a photorealistic image of a toddler riding a cat turtle", "stable-diffusion")

2. Marketplace X’s smart contract calls the registerTaskCallback() method on the BAI Smart Contract with the same parameters, adding its callback method (baiCallbackFunction) as the third parameter:

registerTaskCallback("Create a photorealistic image of a toddler riding a cat turtle", "stable-diffusion", "baiCallbackFunction")

The BAI Smart Contract returns a request_id for tracking.

3. Once the BAI AI Agent processes the request, it calls the callback method on Marketplace X’s smart contract:

baiCallbackFunction("request_id", "bafybeidfr44bue4xbnwhkruxwpltnriw27rulovqzd23bjihji3te5olq4/image.png")

The response includes the request_id and the image’s IPFS CID.

4. Marketplace X mints the NFT using the IPFS CID and lists it for sale. The generated image is now accessible via any IPFS gateway, making it fully decentralized.

https://bai.infura-ipfs.io/ipfs/bafybeidfr44bue4xbnwhkruxwpltnriw27rulovqzd23bjihji3te5olq4/image.png

Example 2:
Project Y DAO
Project Y DAO is considering investing part of its treasury into cryptocurrencies. In addition to seeking opinions from its community, it decides to consult BAI’s AI Discussion Agent for an impartial and decentralized analysis. This ensures the DAO receives unbiased insights generated by two AI instances, free from influence or alteration.

Here’s how it works:

1. A DAO owner or a member with the necessary permissions calls a new method on the DAO’s smart contract, such as:
discussNewTopic(“Should a Blockchain DAO invest part of its treasury into crypto? What are the pros and cons, and which types of crypto are safer investments?”).

2. The DAO smart contract makes a dapp-to-dapp call to the BAI Smart Contract with the required parameters:

registerTaskCallback("Should a Blockchain DAO invest part of its treasury into crypto? What are the pros and cons, and which types of crypto are safer investments?", "discussion", "baiCallbackFunction")

3. This triggers the BAI AI Discussion Agent, which processes the request and stores the result on IPFS. The agent then calls back the DAO smart contract with the response:

baiCallbackFunction("request_id", "bafybeifu5k2epnnryopjojnq6ia3kfzcnmlenynonacx2yjov2ymafgbma/discussion.json")

The response includes the request_id and the IPFS CID of the discussion results.

4. The DAO retrieves the discussion results and displays them on its forum, voting page, or other relevant platforms, providing the community with AI-generated insights to guide the decision-making process.

https://bai.infura-ipfs.io/ipfs/bafybeifu5k2epnnryopjojnq6ia3kfzcnmlenynonacx2yjov2ymafgbma/discussion.json

These are just a few examples of how the Smart Contract Callback Feature can be utilized. The possibilities are endless, limited only by the creativity and innovation of developers leveraging BlockAI’s powerful tools. Any Web3 project can implement AI into their Smart Contract logic without the need to manage its own LLM/AI, Agent, or storage.

3. B2B2C Developer API Access: Off-Chain Integration

In addition to its B2C and B2B offerings, BlockAI provides powerful APIs in Node.js, Java, and Python, enabling projects to seamlessly integrate BlockAI’s features directly into their applications. Through the API, any project can initiate calls from its web UI to interact seamlessly with BlockAI’s smart contracts.

Why This Matters

• No Need for Custom Assistants: When subscribing to services like ChatGPT, API access is typically not included, creating a custom assistant would require significant effort. BlockAI’s APIs eliminate this complexity, providing ready-made integrations for AI-powered features in any web3 projects.
• Blockchain Integration Made Easy: While the API is designed for off-chain initiated calls, it maintains the trust and transparency of blockchain by interacting with smart contracts. Users sign transactions to ensure secure and verifiable interactions.
• Flexible Web UI Integration: Projects can integrate BlockAI’s features directly into their custom interfaces, allowing seamless user interaction with AI-powered services while still leveraging blockchain for task validation and payment.

What Developers Gain

1. Access to Major AI Models in One Place: Integrate advanced AI services (e.g., ChatGPT, DALL-E, Stable Diffusion, BAI Custom features etc.) directly into applications using a single API.
2. Simplified Billing Through Blockchain: Eliminate the need for multiple subscriptions; users pay for services in crypto directly via blockchain transactions, ensuring transparency.
3. Customizable Use Cases: Developers have full control over how AI features are embedded into their user interfaces, enabling tailored solutions for their specific needs.

Who is it for?

Best suited for Web3 projects that:

• Want to integrate AI into their front-end user interfaces, providing consumers with plug-and-play AI capabilities.
• Don’t require on-chain AI logic but still want blockchain-integrated functionality at the UI level.
• Aim to offer seamless user experiences for tasks like generating AI-driven content or insights directly from their platform.

NodeJS: https://github.com/BAIToken/nodejs-api
Python: https://github.com/BAIToken/python-api
Java: https://github.com/BAIToken/java-api

Comparison of the Three Approaches

The Role of the Off-Chain Agent

The off-chain agent is the linchpin of BlockAI’s ecosystem. It:

• Retrieves task requests from the blockchain.
• Executes them using AI models like ChatGPT, DALL-E, and Stable Diffusion etc.
• Returns results to the blockchain for further processing.

This agent ensures that BlockAI’s tools are accessible to both human users (via the Web UI) and smart contracts (via callback features), solidifying its position as a bridge between decentralized and AI-driven solutions.

What Exactly is an AI Agent?

In traditional computer science, an AI agent is defined as a computational system that:

1. Perceives its environment.
2. Processes information autonomously, deciding on an action based on its goal or purpose.
3. Acts on the environment to achieve its objectives.
4. Receives feedback and continues the cycle iteratively.

This definition aligns with foundational work by Michael Wooldridge and Nicholas Jennings, who describe agents as entities capable of autonomous decision-making, interaction, and adaptation.

BlockAI Agents: How They Work

BlockAI’s agents align with this traditional definition and are enhanced by blockchain integration:

1. Input Perception:
   BlockAI agents receive tasks from the blockchain. These tasks are defined by smart contracts or users through the Web UI.
2. Autonomous Decision-Making:
   The agents process tasks using advanced AI models (e.g., ChatGPT, DALL-E etc.) without human intervention.
3. Goal Achievement:
   The agents execute tasks to generate outputs (e.g., summaries, images etc.) that meet predefined requirements.
4. Result Delivery:
   The results are recorded back on the blockchain, where smart contracts or users can access them.

By combining the B2C Web UI, B2B Smart Contract Callback and B2B2C Developer API approaches with its robust AI agents, BlockAI is paving the way for democratized access to AI tools. Whether you’re an individual exploring creative possibilities or a developer enhancing blockchain applications, BlockAI provides the tools to unlock the full potential of AI.

To explore using BlockAI into your web3 project checkout our documentation or reach out to our team directly.

BlockAI Team

BlockAI Website | Twitter | Telegram | Reddit | Linkedin

From Simple Requests to Comprehensive Chats

Previously, BlockAI offered the Simple AI Request feature, allowing users to send one-off queries to AI models like ChatGPT 4.0, Mini Orca, Google Gemini 1.5, and Llama 3.1. However, the simplicity of this feature restricted users from engaging in an extended back-and-forth conversation. Additionally, the on-chain storage of both requests and responses, while feasible on low-fee networks like Waves or Base, posed challenges for broader blockchain compatibility due to transaction fees and data size constraints on some chains like Solana.

Enhancing with Decentralized Storage

To overcome these limitations and enable the chat functionality, BlockAI has integrated the InterPlanetary File System (IPFS). By leveraging IPFS, we ensure that only the small Content Identifier (CID) for chat data is stored on-chain, while the actual chat history is securely stored in a decentralized manner. This approach significantly reduces on-chain data costs and ensures scalability across different blockchain networks.

With this architectural change, we can now provide fully dynamic discussions while reducing storage costs and transaction fees. This feature is currently available in the testing phase on the Waves network at waves.blockai.dev and will soon be extended to other networks. Once fully deployed, it will replace the AI Simple Requests functionality.

Callback Support for Smart Contracts

Any smart contract on any supported chain can now request BAI tasks on-chain using a dapp-to-dapp call and receive the IPFS CID containing the result in return. This response is delivered via the provided callback once our off-chain agent processes the request.

Here’s a preview of the flexibility this dapp-to-dapp feature offers:

1. A Smart Contract request a task on the main BAI Contract:

registerTaskCallback("Create a random lore about a dwarf name Eliott for an heroic fantasy game.", "chatgpt", "result")

1. The response is delivered directly to the requesting dapp using the provided callback (here “result”):

result("QmcVGWjXVLqpQ4woecuF3HCsX56c2Dk4CaqdUscH4TEJf1")

You can then access the data through our IPFS Gateway, such as:

https://bai.infura-ipfs.io/ipfs/QmcVGWjXVLqpQ4woecuF3HCsX56c2Dk4CaqdUscH4TEJf1

or any other IPFS gateway of your choice.

What’s Next?

BlockAI is constantly evolving, and this new feature is just one step toward our broader vision of democratized, scalable, and blockchain-compatible AI tools. Stay tuned for our upcoming release focusing on QoC Features, read more about it.

Experience the next level of AI interaction with BlockAI Chat. For more updates and innovations, visit our website or follow us on Twitter.

BlockAI Team

BlockAI Website | Twitter | Telegram | Reddit | Linkedin

In the rapidly evolving field of artificial intelligence, the ability to generate insightful and contextually relevant answers has become a cornerstone of modern AI systems. However, a recurring limitation often emerges: when posed with a specific question, many AI systems tend to provide a broad range of potential answers without committing to a concrete recommendation. For instance, when asked for advice on where to spend summer holidays, like in the following example:

an AI might generate a list of plausible destinations but fall short of delivering a decisive, tailored suggestion. A typical answer might look like the following:

While this approach ensures a degree of inclusivity and flexibility, it may not always align with users’ needs, especially in scenarios demanding focused, actionable recommendations.

This gap becomes even more apparent in use cases where clarity and precision are paramount. Users seeking definitive guidance can find themselves sifting through generalized options, which, while accurate, lack the specificity to fully address their requirements. This challenge underscores the need for an approach that not only organizes information systematically but also synthesizes it into a form that directly supports decision-making.

Our AI-driven implementation of the Question-Option-Criteria (QOC) framework is designed to address this precise challenge. The QOC framework, traditionally a tool for structured decision analysis, lends itself naturally to this problem space. By systematically evaluating possible options against a set of defined criteria, the framework enables AI to move beyond merely listing possibilities to providing well-reasoned, concrete suggestions tailored to the user’s context. This approach empowers users to make informed decisions with confidence, bridging the gap between expansive AI-generated possibilities and actionable insights.

What is QOC?

The Question-Option-Criteria (QOC) framework is a structured methodology originally rooted in the field of user interface and user experience (UI/UX) design. It was initially developed to support design decisions by systematically analyzing different options against a set of criteria to answer specific questions. Over time, its utility has expanded far beyond its origins, finding a prominent place in general decision support, particularly in scenarios involving group decision-making. The inherent flexibility and distributive nature of the QOC process make it highly effective in both small and large group contexts.

At its core, the QOC approach involves a sequence of clearly defined steps:

1. Identifying Potential Options: The process begins by outlining possible answers or solutions to the given question. These options represent the various pathways that could be considered in the decision-making process.
2. Identifying Relevant Criteria: Next, the criteria that are critical for evaluating the options are determined. These criteria serve as the benchmarks against which the options are assessed, ensuring that the decision aligns with the underlying priorities and objectives.
3. Evaluating Criteria Importance: Each criterion is then assessed to determine its relative importance in the specific context of the decision. This ensures that the decision-making process is weighted appropriately, reflecting the priorities of the stakeholders involved.
4. Evaluating Options: Finally, each option is evaluated based on how well it supports or fulfills the identified criteria. This evaluation provides a clear picture of the strengths and weaknesses of each potential choice.
5. Calculating the Preferred Option: In the final step, a preferred option is calculated using a defined formula that synthesizes the evaluations of both the criteria and the options. This formula ensures that the decision is data-driven and reflects the combined input of all evaluations.

The QOC framework is particularly powerful in distributed scenarios where multiple stakeholders are involved. In such cases, each stakeholder can contribute by suggesting their own options and criteria. These contributions are then consolidated to avoid redundancy — for instance, when different stakeholders suggest the same option or criterion but use slightly different wording. Once consolidated, all stakeholders participate in evaluating the options and criteria, as described above. The final preferred option is calculated using the same structured approach, but now incorporates the diverse perspectives and priorities of the group.

Beyond its effectiveness in facilitating collaborative decision-making, the QOC framework offers an additional advantage: it inherently documents the decision process. By systematically recording the options, criteria, evaluations, and final outcomes, the QOC approach ensures transparency and accountability. When supported by appropriate technical tools, this documentation can serve as a valuable resource for understanding the rationale behind decisions, enabling teams to revisit and refine their processes over time.

BlockAI’s implementation of the QOC approach

Our AI-based implementation of the QOC framework leverages intelligent agents to streamline and enhance the decision-making process. The system operates by dynamically instantiating relevant stakeholders as agents within the system to address the given question. This allows for a flexible and comprehensive approach to decision-making that reflects the needs and priorities of all involved parties.

Contextual Stakeholder Identification

To ensure that the most relevant stakeholders are represented, the system enables the user to provide additional context about the question. This contextual information helps the system identify the appropriate stakeholders, ensuring that the decision process is informed by the right perspectives. By incorporating this layer of customization, the system is well-suited to handle a wide variety of decision-making scenarios.

Stakeholder Contributions

Once the stakeholders are instantiated as agents, they engage in the decision-making process by:

1. Suggesting Options and Criteria: Each agent proposes potential options to answer the given question, as well as criteria for evaluating those options. These contributions reflect the unique priorities and expertise of the stakeholders.
2. Automatic Consolidation: The system consolidates the suggested options and criteria, addressing potential redundancies. For instance, when different agents suggest the same option or criterion but express it differently, the system merges them into unified entities. This ensures clarity and avoids duplication, laying the groundwork for a streamlined evaluation process.

Evaluation and Calculation

After the consolidation step, the agents evaluate both the importance of the criteria and the extent to which each option supports these criteria. This dual evaluation is then processed by the system to calculate the preferred option using a predefined formula. The formula integrates the weighted importance of the criteria with the performance of the options, producing a clear and actionable recommendation.

Example Output

As an example, consider the decision-making scenario outlined in the introduction: selecting a summer holiday destination. After instantiating relevant agents, gathering suggestions, consolidating inputs, and performing evaluations, the system might present a result such as this:

The system’s output in this example provides a clear recommendation based on the consolidated inputs and evaluations.

This AI-driven approach amplifies the effectiveness of the QOC framework by automating and distributing key elements of the process. It enables a scalable, collaborative, and thoroughly documented method for tackling complex decisions across diverse contexts.

Statistical analysis of the results and our contribution to explainable AI

One of the key challenges in the field of artificial intelligence is the lack of transparency in how modern AI algorithms, such as neural networks, arrive at their results. While these algorithms are powerful and capable of solving complex problems, their inner workings often function as a “black box,” obscuring the reasoning and processes that lead to a particular outcome. This opacity creates significant barriers for trust, accountability, and adoption.

The issue of explainability becomes even more pronounced as AI systems are increasingly used in collaborative and high-stakes decision-making scenarios. Without clear insight into why an AI system has made a certain recommendation, users may struggle to assess the reliability and relevance of the outcome, making it difficult to integrate AI into processes that demand human oversight and validation. Addressing this challenge is central to advancing the field of explainable AI (XAI), which aims to develop systems and methodologies that provide clear, interpretable, and actionable insights into AI decision-making processes.

Our work contributes to this critical area by leveraging the structured nature of the QOC framework. By systematically organizing decisions through well-defined questions, options, and criteria, our approach inherently promotes transparency. The detailed evaluations and documented decision-making process ensure that every recommendation made by our AI-driven system can be traced back to its origins, offering users a clear understanding of the “why” behind each outcome. This alignment between structured decision analysis and AI-driven processes represents a meaningful step toward more explainable and trustworthy AI systems.

The architecture of our QOC application is designed to seamlessly integrate the structured QOC framework with the advanced capabilities of large language models (LLMs). At the core of the system lies a dedicated QOC layer, on top of our LLM layer, that orchestrates the entire agent-based QOC process, as described in earlier sections. This layer acts as the decision-making engine, ensuring the systematic and transparent handling of questions, options, and criteria, while leveraging the natural language understanding and generation capabilities of LLMs.

This layered approach ensures that the decision-making process is both systematic and enriched by the contextual and linguistic strengths of LLMs. By combining structured decision analysis with the flexibility and depth of language models, our architecture provides a robust foundation for collaborative, transparent, and effective decision support.

Balancing Explainability Across Layers

In our architecture, the interplay between the LLM layer and the QOC layer highlights a critical aspect of explainable AI. The LLM layer, responsible for generating initial input for the QOC model, remains inherently unexplainable. This lack of transparency stems from the nature of neural networks, where the reasoning behind generated outputs is not directly interpretable. In contrast, the QOC layer, which processes the LLM-generated input to determine concrete answers, provides a significant step forward in explainability.

The QOC layer ensures that results are transparent and traceable. It allows for statistical analysis, enabling insights into the decision-making process. Moreover, it facilitates the identification of critical criteria that influence decisions and supports the calculation of similarly good options, which are alternatives that are not significantly worse than the recommended choice. These features make the QOC layer a cornerstone in advancing toward a more explainable AI system.

The broader challenge lies in reducing reliance on the unexplainable LLM layer and expanding the role of the explainable QOC layer. Ideally, the decision-making process would rely exclusively on explainable components, ensuring complete transparency and accountability. While this goal has not yet been fully realized, it represents an important direction for future research, aiming to bridge the gap between powerful AI capabilities and the need for trust and understanding in AI-driven decisions.

Examples for statistical evaluations of the results

Users are not only empowered with a definitive answer, as described in the last section, but can also trace the rationale behind the recommendation, ensuring transparency and confidence in the decision-making process.

For example, the results of the discussion can be represented visually through a graph.

This graph can illustrate the evaluated options alongside their scores relative to the identified criteria, providing a clear view of how each option performs. Such visualizations enhance the accessibility of the decision-making process, enabling users to grasp the reasoning behind the recommendation quickly. Moreover, the graph can highlight similarly good options, showcasing viable alternatives and reinforcing the robustness and flexibility of the decision. This approach ensures that users not only understand the recommendation but also feel confident in exploring other possibilities if needed.

Additionally, the system can provide a detailed overview of the agents that participated in the decision-making process. This includes listing their names alongside a description of their corresponding roles, offering users clarity on the contributors and their perspectives.

By identifying the agents involved, the system ensures that the decision process is transparent and accountable. This information allows users to understand the diversity of inputs and viewpoints that shaped the recommendation, reinforcing trust in the process while enabling a deeper appreciation of the collaborative effort behind the final result.

We can also include an analysis of the consolidated options and criteria in relation to the full set of options and criteria initially suggested by the agents.

This analysis highlights how individual contributions were merged into the final decision framework, providing insights into the inclusiveness and comprehensiveness of the process. By comparing the consolidated outcomes to the original suggestions, users can trace how overlaps, redundancies, and unique perspectives were handled. This fosters an understanding of the system’s ability to synthesize diverse inputs effectively and ensures that all relevant aspects were considered in the decision-making process.

Additionally, the system can perform an analysis of the consistency in the evaluations provided by the agents for both the criteria and the options. This can be achieved by calculating statistical measures such as the standard deviation of the evaluations.

A low standard deviation would indicate a high level of agreement among the agents, while a higher standard deviation may reveal differing perspectives or priorities. Such an analysis helps identify areas where consensus was strong and where discrepancies may require further attention or discussion. This evaluation consistency check enhances the transparency of the process and provides valuable insights into the alignment and diversity of stakeholder inputs.

We can identify critical criteria by analyzing their importance in relation to their standard deviation. A high standard deviation, indicating a diverse range of opinions among the agents, combined with high importance suggests that the criterion is highly debated and requires careful consideration. On the other hand, criteria with low standard deviation (indicating consistent agreement among agents) and low importance are likely less critical to the decision-making process. Visualizing this relationship on an x-y graph, with importance on one axis and standard deviation on the other, provides a clear representation: the most critical criteria appear in the upper right corner of the graph, while the less critical criteria are positioned in the lower left corner.

This approach highlights where attention should be focused during the evaluation process, facilitating informed and balanced decision-making.

Last but not least, we can identify options that are similarly good to the preferred option, defined as those that are not statistically significantly worse. To determine this, we calculate the standard deviation of the results for each option. Then, we identify options whose scores are within one standard deviation of the winning option. These options fall within a range where their performance is considered statistically indistinguishable from the top choice.

By highlighting these similarly good options, the system provides users with a broader perspective on viable alternatives, enabling them to consider multiple paths forward without sacrificing quality or alignment with the decision criteria.

BAI Team

BlockAI Website | Twitter | Telegram | Reddit | Linkedin

As quarter 3 of 2024 came to an end, we would like to provide an update on BlockAI (BAI) progress based on the previously shared roadmap. As a reminder, the roadmap was initially designed to give our community members an idea of the upcoming plans. However, we have emphasized that our approach is agile, allowing us to adapt to needs and priorities as they arise.

Cross-Chain Token Bridge

As a multi-chain project currently available on BNB, Base, and Waves, it’s essential to provide an option for token holders to bridge their $BAI across these chains. The bridge is nearly complete and has been deployed on Testnet. We plan to share it publicly soon, and may offer bounties to those who help us test it.

As for the Mainnet deployment, this will take more time. A bridge is a critical component, and it requires extensive testing and a proper external audit before its public release.

R&D (Research & Development)

Solana
In our Research & Development efforts, we explored the possibility of deploying BlockAI (BAI) on the SOLANA platform. While Solana could be a good match, it requires adjustments to our approach to data storage. Additionally, Solana’s callback system would need a distinct approach based on its unique infrastructure.

We are currently working on a deployment to the Solana Testnet and will evaluate progress from there.

First On-Chain AI Proof of Concept
As part of our on-chain AI R&D efforts, our collaboration with a university has yielded promising results. Early findings show that smaller neural networks can successfully operate directly on-chain. We’ve successfully ported our off-chain 3-in-a-row contract and a neural network designed to solve car insurance cases onto the Waves network as fully on-chain versions.
Ongoing research is focused on extending this work to EVM-based blockchains, along with an in-depth cost analysis of these implementations. We are also supporting a master’s thesis in this area, with final results expected by mid-next year, which will culminate in a scientific publication on the subject.

First Blockchain AI Game MVP
We also focused on developing a demo that illustrates our approach to bridging AI and blockchain through a Web3 game. We released a simple Tic-Tac-Toe demo on the Waves Mainnet, with $BAI tokens available as prizes.

You can try it here: Tic-Tac-Toe Demo.

Questions, Options, & Criteria Product
Our final R&D project of the quarter involved the development of the “Questions, Options, & Criteria” product. The demo is nearly ready and should be released on Testnet in the coming weeks.

Extending MVP to Full Product

Due to our research on SOLANA and other factors, we have decided to keep the platform in the MVP (Minimal Viable Product) phase. We aim to implement some significant changes first, including storing larger AI text request results on IPFS rather than automatically on-chain. This would only apply to standard requests, while Dapp-to-Dapp calls will continue to store results on-chain, along with a new fee system.

As a result, this part of the roadmap is delayed and moved to next year.

Adding New Features, LLM, and AI Models

During Q3, we introduced several updates to the platform, including a feature that allows users to pre-approve or revoke spending on EVM chains from the web app. This reduces the cost of using our services.

We also added support for the LLaMA 3 model, an open-source model developed by Meta, known for its high performance and affordability, making it the most cost-effective AI text option on our platform.

We also suggested adding Claude 3.5 (Sonnet AI), but this did not generate enough interest from the community, so we have postponed that initiative for now.

Hiring a Business Development Manager and Product Adoption

A few months ago, we began working with various partners to focus on business development and product adoption. Although the product remains in the MVP stage, we are finalizing the steps necessary to move beyond MVP and will push for more extensive public adoption afterward.

We are currently in discussions with potential marketing partners to bring unprecedented visibility to BlockAI.

Partnership Campaign

BlockAI BAI has been very active and successful in securing critical partnerships and support. We’ve been accepted into prestigious startup programs, including:

• Google Cloud for Startups
• MongoDB
• QuickNode
• IBM
• GitHub for Startups
• GitLab
• Atlassian (Bitbucket/Jira)

Community Initiatives Program

Our Community Initiatives Program, aimed at supporting community-driven projects such as content creation and tool development, did not receive substantial suggestions during Q3. This initiative will be revisited early next year as the product becomes more advanced.

Conclusion

The next few quarters will involve significant development efforts and a major focus on increasing visibility and product adoption. We may release an updated roadmap, though, like the previous one, it will serve as a guide and will adapt as needed as we move forward.

BAI Team

BlockAI Website | Twitter | Telegram | Reddit | Linkedin

From chatbots to content generation, these models are reshaping how we interact with technology. In this article, we’ll dive into the pros and cons of five prominent LLMs supported by BlockAI:

• ChatGPT-4,
• Gemini 1.5 Pro,
• Orca Mini,
• Llama 3,
• Claude 3.5 Sonnet.

ChatGPT-4

ChatGPT-4 is the latest iteration of OpenAI’s GPT series, known for its broad knowledge base and ability to understand and generate human-like text across various domains. It represents a significant leap in natural language processing capabilities.

Areas of Excellence:
ChatGPT-4 particularly shines in creative writing, complex problem-solving, and providing detailed explanations on a wide range of topics. It also demonstrates strong capabilities in code generation and debugging.

Pros:

• Exceptional language understanding and generation capabilities
• Versatile across a wide range of tasks
• Strong performance in creative and analytical tasks

Cons:

• Potential for generating plausible-sounding but incorrect information
• Expensive to use, especially for large-scale applications
• Limited customization options due to its closed-source nature

Gemini 1.5 Pro

Gemini 1.5 Pro is Google’s advanced multimodal AI model, designed to process and generate various types of data, including text, images, and code. It builds upon the capabilities of its predecessors with enhanced reasoning abilities.

Areas of Excellence:
Gemini 1.5 Pro excels in tasks requiring multimodal understanding, such as image analysis and generation. It also demonstrates superior performance in mathematical reasoning and scientific problem-solving.

Pros:

• Multimodal capabilities, handling text, images, and other data types
• Impressive performance on complex reasoning tasks
• Efficient scaling to long-context windows

Cons:

• Limited availability and testing in real-world applications
• Potential biases in training data
• Less flexibility for customization compared to open-source alternatives

Orca Mini

Orca Mini is a compact language model designed for efficiency and speed. It’s part of a family of models aimed at providing AI capabilities in resource-constrained environments.

Areas of Excellence:
Orca Mini performs particularly well in scenarios requiring quick responses and low computational overhead, such as chatbots for customer service or simple query-answering systems.

Pros:

• Compact size, suitable for edge devices and resource-constrained environments
• Fast inference times
• Open-source, allowing for customization and fine-tuning

Cons:

• Limited capabilities compared to larger models
• May struggle with complex or nuanced tasks
• Requires careful prompt engineering for optimal results

Llama 3

Llama 3 is Meta’s open-source large language model, designed to be versatile and accessible to researchers and developers. It builds upon the success of its predecessors with improved performance and capabilities.

Areas of Excellence:
Llama 3 shows strong performance in natural language understanding tasks, particularly in multilingual contexts. It also demonstrates good capabilities in code generation and text summarization.

Pros:

• Open-source architecture, fostering community development and improvements
• Strong performance across various benchmarks
• Flexible deployment options, from edge devices to cloud infrastructure

Cons:

• Potential for misuse due to its open nature
• May require more fine-tuning for specific tasks compared to proprietary models
• Ongoing development may lead to frequent updates and potential instability

Claude 3.5 Sonnet

Claude 3.5 Sonnet is Anthropic’s advanced AI model, designed with a focus on safety, ethics, and advanced reasoning capabilities. It aims to provide reliable and thoughtful responses across a wide range of applications and is offered as a cloud-based service.

Areas of Excellence:
Claude 3.5 Sonnet excels in tasks requiring nuanced understanding and ethical considerations. It performs exceptionally well in analytical writing, complex reasoning tasks, and providing balanced perspectives on controversial topics. Additionally, it has strong capabilities in artifact creation and management, as well as code generation.

Pros:

• Advanced reasoning and analytical capabilities
• Strong focus on safety and ethical AI principles
• Excellent performance in tasks requiring nuanced understanding
• Unique artifact creation and management capabilities
• Impressive code generation skills

Cons:

• Less widely available compared to some competitors
• May be overly cautious in certain scenarios due to safety constraints
• Potential limitations in multilingual capabilities compared to some other models

Conclusion

Each of these LLMs brings its own strengths and weaknesses to the table. The choice of which model to use depends on the specific requirements of your project, including factors such as task complexity, computational resources, ethical considerations, and deployment environment. As the field of AI continues to advance, we can expect these models to evolve and improve, addressing current limitations and introducing new capabilities.

Summary Table

This table provides a quick overview of the key strengths, limitations, and areas of excellence for each model, helping you make an informed decision based on your specific needs and use cases.

BAI Team

BlockAI Website | Twitter | Telegram | Reddit

In the rapidly evolving digital landscape, the convergence of blockchain technology and artificial intelligence (AI) is unlocking unprecedented opportunities. At the forefront of this revolution is BAI, a groundbreaking project that seamlessly integrates these two powerful technologies to offer a suite of tools accessible through a web UI or by smart contract with a callback system.

This initiative is not just about technological innovation; it’s about creating a decentralized, user-empowered platform that transcends traditional boundaries.

By supporting multiple blockchains:

Waves: https://waves.blockai.dev
Polygon: https://polygon.blockai.dev
BNB Chain: https://bnb.blockai.dev

BAI is setting a new standard for flexibility and accessibility in the blockchain and AI domains.

A New Era of Tokenomics: The $BAI Token

Central to the BAI ecosystem is its native token, $BAI (Blockchain AI), designed to serve as the key utility token within the platform. The introduction of $BAI marks a significant milestone in the project’s journey, encapsulating a vision for a decentralized, equitable ecosystem that leverages tokenomics to empower its users.

Read our whitepaper to learn more about our tokenomic and plans: https://blockai.dev/files/whitepaper.pdf

Acquisition: The Path to Early Support

In an exciting development, BAI has opened its private sale to early supporters, offering the $BAI token at a price of $1 per token.
Participants in this early phase will receive a 10% bonus in tokens on the total amount purchased, with this bonus being released after a six-month locking period. This initiative not only allows early adopters to gain an advantageous position but also plays a crucial role in the project’s development trajectory.

The private sale is set to conclude on March 31, paving the way for a strategic marketing campaign aimed at raising awareness ahead of the public sale scheduled for the end of April. It’s worth noting that out of the 500,000 tokens available for the first year, 120,000 have been allocated to the Waves DAO, which leaves only 380,000 tokens available for acquisition during the private and public sales.

Register now to the private sale to get a 10% bonus:
https://blockai.dev/#private_contact_form

Interested parties are invited to register for the private sale by filling out a form on the BAI website, ensuring their addresses are whitelisted for the purchase on their selected network.

Supported Networks and Assets:

• Waves: USDT, USDC, Waves
• Polygon & BNB: USDT, USDC

Utility: The Gateway to Innovation & Community Empowerment

The $BAI token is at the heart of the BAI project, serving as the utility token that enables access to a wide array of services.

This includes:

• Text & Chat: supporting platforms like ChatGPT, Orca, and Google Gemini 1.5.
• AI Image Generation: featuring Dall-E 3 and Stable Diffusion 2.1 to generate any kind of images.
• Video Summarizer: A custom BAI feature designed to summarize any YouTube video.
• AI Discussion: A custom BAI feature that enables two AI instances to discuss a given topic.
• AI Brainstorm: A custom BAI feature that allows five AI instances to brainstorm about a given subject, generating the results as a MindMap.

Moreover, this is only the beginning.
The BAI platform is committed to regularly introducing new features and enhancements, guided by the wishes and votes of its users through the DAO. This ensures that the platform not only remains at the cutting edge of technology but also truly serves the needs and desires of its community, fostering a vibrant, participatory ecosystem.

The more users engage with the platform, utilizing its services through the Web UI or the Smart Contract dapp-to-dapp callback system, the more they enhance their voting power within the BAI DAO. This system not only incentivizes active participation but also ensures that the project remains aligned with the community’s evolving needs and preferences.

A Balanced Approach to Token Supply

Understanding the pitfalls of uncontrolled token distribution, BAI has meticulously designed its tokenomics for sustainability and equity:

• Initial Minting:
  A total of 10,000,000 $BAI tokens will be initially pre-minted, with a carefully planned release schedule over several years to ensure a steady market supply.
• Controlled Release Plan:
  To mitigate rapid price volatility and market manipulation risks, the first-year sale will offer 500,000 tokens at a fixed price of one dollar each. Subsequent years will see a gradual decrease in the number of tokens sold — 300,000 in the second year and 200,000 in the third, at market prices.

Long-term Commitment & Community Involvement

• Development Team Incentives:
  1,000,000 tokens are reserved for the development team, to be disbursed after three years, ensuring long-term dedication and innovation.
• Community Decision-making:
  The potential utilization of the remaining 8,000,000 tokens will be determined by both the project team and the community, embodying the principles of decentralization and user empowerment.

Moving Forward

As BAI continues to break new ground, its fusion of blockchain and AI with a user-centric approach represents a beacon of innovation in the digital world. The project’s thoughtful tokenomics exemplify a commitment to long-term success, community involvement, and the democratization of technology. As we stand on the brink of a new digital era, BAI invites us to reimagine what’s possible.

Private Sale Terms and Conditions:
https://blockai.dev/files/Token-Sale-Terms-and-Services.pdf

BAI Team

BlockAI Website | Twitter | Telegram | Reddit