Introduction

Verisense is an infrastructural protocol for the agentic network enabling true autonomy and interoperability.

The agentic communication stacks and limitations

The existing AI communication protocols can be categorized in three types:

1. LLM Communication Protocols: Standardized API specifications used for communication between LLM-backed applications/agents and large language models (each LLM provider maintains proprietary API standards)

2. Tool/Service Communication Protocol (MCP): Primarily facilitating interactions between agents and remote tools or data services

3. Agent-to-Agent Communication Protocol (A2A): Standard protocols enabling communication between remote agents

While these protocols truly being the pillars of next-generation AI internet infrastructure, they currently present several critical limitations.

Technical Limitations:

1. Multi-tenancy Deficiency: The MCP protocol lacks native multi-tenancy support, potentially causing session conflicts when multiple agents concurrently access the same MCP service

2. Service Discovery Gap: Both A2A and MCP currently operate purely through point-to-point connections without mechanisms, lacking automatic network formation or agent-native service discovery

3. Identity and Authorization Challenges: No unified solution exists for cross-network agent authentication and permission management in agent-to-agent communications

4. Verifiability and Trust Absence: No built-in mechanisms for verifiability and trust. Agents typically operate in isolated black boxes, leaving users no easy way to establish trust or verify agent behavior and historical activity. A baseline of verifiability, traceability, and accountability is essential.

These architectural deficiencies hinder the emergence of truly agentic, interoperable, and scalable networks. Future protocol developments should prioritize addressing these constraints and lay the foundation for agentic networks and AI autonomy.

What is Verisense

Verisense introduces a trustless, permissionless blockchain protocol designed to tackle these challenges, serving as the backbone of the agentic network. It enables agents to autonomously interoperate and transact with verifiable identity, assets, reputation, and context-aware intelligence.

Agentic assets hub

Verisense implements a blockchain-based registry system that records publicly available metadata for all online agents and MCP servers. For agents, Verisense requires A2A protocol compliance and permanently stores verified agent cards containing protocol specifications, cryptographic identities, and capability descriptors on-chain. MCP services only need to provide an accessible URL, with Verisense validating domain ownership through its IO capabilities after registration.

The purpose-built identity solution for agents

Verisense incorporates decentralized identity (DID) services to enable secure transactions. Both online agents and MCP servers validate requests by performing the following steps:

1. Signature Verification

Each request must include a cryptographic signature from the requester's DID-authenticated identity. The recipient (agent or MCP) verifies the signature against the requester's DID document.

2. Credential Validation

The recipient queries the DID-linked credential issuer (on-chain or via a trusted oracle). The issuer confirms whether the requesting party has sufficient Verisense balance to pay for the service.

3. Payment Enforcement

• Only verified, solvent requesters obtain service.
• Fraudulent or underfunded requests are rejected.

Implementation Benefits

✔ Trustless transactions – No central authority manages payments

✔ Spam prevention – Ensures service consumers have adequate funds

✔ Interoperability – Works with existing A2A/MCP protocols

Note: This mechanism can integrate with automated micropayments for pay-per-call services.

Service Inspection and Performance Evaluation with Incentive Alignment

Verisense's SenseSpace is a user-facing application where all requests are processed through Katryna, a specialized system-scope agent that inspect service quality and measure task performance of online agents and MCP servers before deducting fees from user accounts and disbursing payments to providers.

Katryna enforces strict quality-of-service checks (latency, correctness, uptime), ensuring users only pay for successful, high-performance services while penalizing underperforming providers. Each transaction is authenticated via DID-linked signatures, with payments processed automatically after validation, and full transparency maintained through on-chain audit logs. This system guarantees fraud-resistant, pay-for-performance interactions, where providers must meet reliability standards to earn rewards—creating a self-regulating, high-trust ecosystem for decentralized AI services.

Cybernetic contract execution environment

Verisense blockchain introduces a novel decentralized execution environment that enables dApps to initiate I/O operations through what we term "Cybernetic Contracts". These Cybernetic Contracts extend beyond the capabilities of traditional smart contracts by incorporating real-world interactions and service integrations.

The Katryna auditing agent exemplifies this architecture as a Cybernetic Contract operating on Verisense. It dynamically monitors QoS metrics from A2A agents and MCP servers, executing automated settlements based on verifiable performance data. This framework fundamentally eliminates the opacity of centralized reward distribution: all service evaluations are validated on-chain through the decentralized network, while payment settlements strictly follow predefined smart contract logic.

By maintaining blockchain's trustless properties while achieving cloud-comparable responsiveness, Cybernetic Contracts represent a significant evolution in enterprise-grade decentralized services. The Katryna implementation demonstrates how Verisense enables truly functional Web3 service economies with:

• Transparency in service quality verification
• Autonomous settlement execution
• Resistance to centralized manipulation
• Real-world service integration capabilities

This technological breakthrough positions Verisense as a pioneer in practical blockchain infrastructure for next-generation decentralized applications.

Getting Started

Sensespace is a powerful AI assistant platform combining all agentic assets of Verisense.

Submit your task to online agents

Sensespace is the all-in-one AI assistant. All various agents listed on Verisense are available on sensespace.

1. Open Sense Space

2. Connect Account: Click the Connect button in the top right corner and choose your login method:
   • Google / Email connection
   • Polkadot wallet (SubWallet) connection
3. Start Conversation: After successful connection, enter your question in the input box to chat directly with Katryna

4. Smart Assignment: Katryna will automatically assign your question to the appropriate Agent to solve your problem
5. Specify Agent: If you need to designate a specific Agent to help solve your problem, you can directly use @AgentName followed by your question

Build homebrew agents using existing tools & resources

You can create and customize your own AI Agents on the Sensespace platform to build your exclusive intelligent assistant.

How to Create Custom Agents

1. Open Sensespace Homebrew

2. Click the Homebrew button to start creating your Agent

3. Configure Agent Properties:

• Fill out the form: Enter the Form name and description fields
• Select model: Choose the AI model to use
• Set Prompt rules: Specify the Agent's prompt rules, describing its behavior or output style
• Configure MCP: Select the MCP (Model Context Protocol) services to call

example:

4. Click confirm after completing the configuration

How to Use Custom Agents

1. Find the created Agent in the My Agents list

2. Click the Chat button to start a new session

3. Now you can chat and converse with your custom Agent

Register tools & resources on Verisense dashboard

Register various tools and resources on the Verisense Dashboard to enable more users to access your Agents and MCP services.

Accessing the Dashboard

First, open Verisense Dashboard

Currently supports registration of three resource types:

• Agents - AI intelligent agents
• MCPs - Model Context Protocol services
• Nucleus - Core nodes

Registering Agents

Important Requirements: Ensure your Agent supports the A2A (Agent-to-Agent) protocol specification. All Agents registered to Sensespace must comply with A2A protocol requirements for interoperability.

For detailed guidance on how to integrate your Agent with the A2A protocol, please refer to: A2A Protocol Integration Guide

1. Access registration page: Open Agent Registration

2. Load Agent Card:

   • Fill in the endpoint address
   • Click the Load Agent Card button
   • Wait a moment, the system will automatically load the Agent Card

3. Complete registration: Go to the bottom of the page and click register

Alternative method: You can also manually paste the Agent Card, click parse, wait for successful parsing, then go to the bottom to register

Registering MCP

1. Access registration page: Open MCP Registration

2. Fill in information:

   • MCP Name: Enter the name of the MCP service
   • Description: Briefly describe the functionality of the MCP service
   • MCP Server URL: Fill in the MCP server address

3. Important notes: MCP needs to be compatible with streamable HTTP protocol

4. Complete registration: Click the Register button

Registering Nucleus

For Nucleus registration and deployment, please refer to the detailed deployment guide: Deploy Nucleus

Agent2Agent (A2A) Protocol Integration Guide

This guide explains how to integrate your Agent with the A2A protocol for interoperability with other Agents on the Sensespace platform.

What is the A2A Protocol?

The Agent2Agent (A2A) Protocol is an open standard developed by Google and donated to the Linux Foundation designed to enable seamless communication and collaboration between AI agents. In a world where agents are built using diverse frameworks and by different vendors, A2A provides a common language, breaking down silos and fostering interoperability.

For comprehensive documentation and specifications, visit the official A2A Protocol website.

Relationship between A2A and MCP

A2A and Model Context Protocol (MCP) are complementary standards for building robust agentic applications:

• MCP (Model Context Protocol): Provides agent-to-tool communication, standardizing how an agent connects to its tools, APIs, and resources to get information
• A2A (Agent2Agent Protocol): Provides agent-to-agent communication, acting as a universal, decentralized standard that allows AI agents to interoperate, collaborate, and share discoveries

A2A acts as the public internet that allows AI agents—including those using MCP or built with frameworks—to interoperate, collaborate, and share their findings.

Essential Integration Components

1. Install A2A SDK

First, install the A2A SDK for your language:

# Python
pip install a2a-python

# JavaScript
npm install a2a-js

# Java
# Refer to https://github.com/a2aproject/a2a-java

# C#/.NET
# Refer to https://github.com/a2aproject/a2a-dotnet

# Go
# Refer to https://github.com/a2aproject/a2a-go

2. Create Agent Executor

Implement the AgentExecutor interface, which is the core component of the A2A protocol:

from a2a.server.agent_execution import AgentExecutor
from a2a.types import RequestContext, EventQueue

class YourAgentExecutor(AgentExecutor):
    """Your Agent Implementation."""
  
    def __init__(self):
        # Initialize your agent
        self.agent = YourAgent()
  
    async def execute(
        self, 
        context: RequestContext, 
        event_queue: EventQueue
    ) -> None:
        # Get user input
        query = context.get_user_input()
        task = context.current_task
      
        # Process message and generate response
        async for event in self.agent.stream(query):
            if event['is_task_complete']:
                # Send final result when task is complete
                await event_queue.enqueue_event(
                    TaskArtifactUpdateEvent(
                        append=False,
                        context_id=task.context_id,
                        task_id=task.id,
                        last_chunk=True,
                        artifact=new_text_artifact(
                            name='current_result',
                            description='Agent response result.',
                            text=event['content'],
                        ),
                    )
                )
                await event_queue.enqueue_event(
                    TaskStatusUpdateEvent(
                        status=TaskStatus(state=TaskState.completed),
                        final=True,
                        context_id=task.context_id,
                        task_id=task.id,
                    )
                )
            elif event['require_user_input']:
                # When user input is required
                await event_queue.enqueue_event(
                    TaskStatusUpdateEvent(
                        status=TaskStatus(
                            state=TaskState.input_required,
                            message=new_agent_text_message(
                                event['content'],
                                task.context_id,
                                task.id,
                            ),
                        ),
                        final=True,
                        context_id=task.context_id,
                        task_id=task.id,
                    )
                )
            else:
                # Status updates while work is in progress
                await event_queue.enqueue_event(
                    TaskStatusUpdateEvent(
                        append=True,
                        status=TaskStatus(
                            state=TaskState.working,
                            message=new_agent_text_message(
                                event['content'],
                                task.context_id,
                                task.id,
                            ),
                        ),
                        final=False,
                        context_id=task.context_id,
                        task_id=task.id,
                    )
                )
  
    async def cancel(
        self, context: RequestContext, event_queue: EventQueue
    ) -> None:
        # Implement cancellation logic
        pass

3. Implement Agent Streaming

Your Agent needs to support streaming output, returning standardized event format:

class YourAgent:
    async def stream(self, query: str) -> AsyncIterable[dict]:
        """Stream responses from your agent."""
      
        # Process query and generate response
        for chunk in self.process_query(query):
            yield {
                'is_task_complete': False,  # Whether task is complete
                'require_user_input': False,  # Whether user input is required
                'content': chunk  # Response content
            }
      
        # Final response
        yield {
            'is_task_complete': True,
            'require_user_input': False,
            'content': 'Task completed successfully'
        }

4. Configure Agent Card

Create an Agent Card describing your Agent's capabilities and skills:

from a2a.types import (
    AgentCapabilities, 
    AgentCard, 
    AgentSkill
)

skill = AgentSkill(
    id='your_agent_skill',
    name='Your Agent Skill',
    description='Description of what your agent can do',
    tags=['tag1', 'tag2'],
    examples=['Example query 1', 'Example query 2'],
)

agent_card = AgentCard(
    name='Your Agent Name',
    description='Description of your agent',
    url='http://localhost:8080/',  # Agent service URL
    version='1.0.0',
    default_input_modes=['text'],
    default_output_modes=['text'],
    capabilities=AgentCapabilities(
        streaming=True,  # Support streaming
        input_modes=['text'],
        output_modes=['text'],
    ),
    skills=[skill],
)

5. Start A2A Server

Finally, create and start the A2A server:

import uvicorn
from a2a.server.apps import A2AStarletteApplication
from a2a.server.request_handlers.default_request_handler import DefaultRequestHandler
from a2a.server.tasks.inmemory_task_store import InMemoryTaskStore

def main():
    # Create task store and request handler
    task_store = InMemoryTaskStore()
    request_handler = DefaultRequestHandler(
        agent_executor=YourAgentExecutor(),
        task_store=task_store,
    )
  
    # Create A2A application
    server = A2AStarletteApplication(
        agent_card=agent_card,
        http_handler=request_handler
    )
  
    # Start server
    uvicorn.run(
        server.build(), 
    uvicorn.run(
        server.build(), 
        host='0.0.0.0', 
        port=8080
    )

if __name__ == '__main__':
    main()

Integration Examples with Different Frameworks

LangGraph Integration

from langgraph.prebuilt import create_react_agent
from langchain_openai import ChatOpenAI

class LangGraphAgent:
    def __init__(self):
        self.model = ChatOpenAI(model="gpt-4")
        self.agent_runnable = create_react_agent(
            self.model,
            tools=your_tools,
            prompt=your_system_prompt,
        )
  
    async def stream(self, query: str, session_id: str):
        config = {'configurable': {'thread_id': session_id}}
        langgraph_input = {'messages': [('user', query)]}
      
        async for chunk in self.agent_runnable.astream_events(
            langgraph_input, config, version='v1'
        ):
            # Process LangGraph events and convert to A2A format
            yield self.convert_to_a2a_format(chunk)

CrewAI Integration

from crewai import Agent, Task, Crew

class CrewAIAgent:
    def __init__(self):
        self.agent = Agent(
            role='Your Agent Role',
            goal='Your Agent Goal',
            backstory='Your Agent Backstory',
        )
  
    async def stream(self, query: str):
        task = Task(
            description=query,
            agent=self.agent,
        )
      
        crew = Crew(
            agents=[self.agent],
            tasks=[task],
        )
      
        # Execute task and stream results
        result = crew.kickoff()
        yield {
            'is_task_complete': True,
            'require_user_input': False,
            'content': str(result)
        }

Testing Your A2A Agent

Testing with CLI Client

# Install A2A client tools
pip install a2a-python

# Test your Agent
python -m a2a.client --agent http://localhost:8080

Testing with Direct HTTP

# Get Agent Card
curl -X POST http://localhost:8080 \
  -H "Content-Type: application/json" \
  -d '{}'

# Send message
curl -X POST http://localhost:8080 \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "message/stream",
    "params": {
      "id": "task-01",
      "sessionId": "session-123",
      "acceptedOutputModes": ["text"],
      "message": {
        "role": "user",
        "parts": [{
          "type": "text",
          "text": "Hello, how can you help me?"
        }]
      }
    }
  }'

Deploy to Sensespace

Once your Agent complies with A2A protocol specifications, you can register it on the Sensespace platform:

1. Deploy your Agent service to a publicly accessible address
2. Ensure the Agent service runs on a publicly accessible port
3. Register your Agent at Verisense Dashboard
4. Enter the Agent's endpoint address and test the connection

Reference Resources

Official Resources

• A2A Protocol Official Documentation
• A2A Python SDK
• A2A Sample Code Repository

Code Examples

We strongly recommend referring to actual implementations in the official sample code repository:

• Basic Example: A2A Implementation without Framework
• LangGraph Integration: LangGraph A2A Agent
• CrewAI Integration: CrewAI A2A Agent
• AG2 Integration: AG2 A2A Agent

Learning Tutorials

• A2A Python Tutorial
• Protocol Specification

Blockchain technology innovation in Verisense

Blockchain technology has revolutionized various industries by providing a decentralized, secure, and transparent method of record-keeping and transaction processing. However, as the technology matures, several issues have emerged that hinder its broader adoption and integration with modern technologies like Artificial Intelligence (AI). This document outlines the primary challenges faced by traditional blockchain architectures and introduces Verisense as a potential solution to these problems.

Challenges Faced by Blockchain Technology

Limited to Deterministic Computation

Traditional blockchains are designed to execute deterministic computations. This design inherently excludes input/output (IO) operations, which are essential for interacting with external systems and play a crucial role in computing’s functionality. Blockchain networks rely on oracles to bridge these interactions with the external world, a mechanism that is often cumbersome and limited in scope. In the AI era, where dynamic data interactions are paramount, the rigidity of traditional blockchain structures becomes a significant barrier to innovation.

Cryptographic Fragmentation

Typically, a blockchain network implements a single digital signature cryptographic scheme, which forms the backbone of its security and integrity. This approach results in significant compatibility issues when different networks use disparate cryptographic techniques. The lack of interoperability between distinct cryptographic systems creates a substantial hurdle in developing applications that require interactions across multiple blockchain networks.

Cost-Complexity Trade-off

There is an intrinsic correlation between the cost of using a blockchain network and its degree of decentralization. More decentralized networks offer higher security and data integrity but at increased costs. Developers often face a dilemma where they must choose between the technological merits and the economic feasibility of using a particular blockchain. This challenge is further compounded by the vibrant and sometimes polarizing blockchain ecosystems, leading developers to prioritize network popularity over the application's intrinsic requirements. For instance, constructing a social media application on a highly decentralized network like Bitcoin is impractical due to cost concerns, yet decentralized finance (DeFi) applications align well with such networks given their financial focus.

Verisense is an innovative blockchain solution aiming to address the aforementioned challenges. It is designed to overcome the limitations of traditional blockchains by providing a more flexible, interoperable, and cost-effective framework. In the forthcoming sections, we will detail the core capabilities of Verisense and how it resolves these critical issues.

Introduction to Verisense blockchain

Verisense represents a distinctive approach to blockchain architecture by implementing a dual-layer network model. This configuration is specifically designed to address the limitations of traditional blockchain systems and to enable more agile and functional application development.

Hostnet

The first layer of Verisense, known as the Hostnet, is a Proof-of-Stake (PoS) network constructed using the Substrate framework. At first glance, this may seem conventional, as it lacks support for Ethereum Virtual Machine (EVM) contracts; however, this is an intentional design choice. After over a decade of blockchain innovation, Verisense recognizes that the current paradigm of smart contracts has reached an innovation plateau. Consequently, Verisense deviates from the conventional smart contract virtual machine model, directing all application operations to the second layer, the Subnet.

Subnet

An application within Verisense are referred to as a Nucleus, and each nucleus operates on an independent Subnet. A subnet is essentially a subset of Hostnet members. This architecture allows each Verisense application to determine its unique consensus requirements, selecting only the necessary nodes for verification based on its specific characteristics and needs. This strategy is inspired by the concept of restaking but extends it further by providing a set of primitive-level Software Development Kits (SDKs) for application development.

Each Subnet functions semi-autonomously, allowing developers to tailor the network’s governance and operational model to best fit the application’s needs. This reduces unnecessary overhead and increases the efficiency and scalability of decentralized applications (dApps).

Advantages Over Traditional Smart Contracts

Unlike traditional smart contracts, Nucleus offers enhanced capabilities that empower developers to create more powerful applications in web2 development way. Key features include:

• Active Network Requests: A nucleus can initiate network requests, enabling them to interact with external systems and data sources such as LLMs or other blockchains.

• Dapp-Level Multi-Type Threshold Signatures: This feature allows a Nucleus to hold some different types of private key such as EcDSA over secp256k1, Ed25519 or Schnorr over secp256k1 and sign arbitrary data. That enables the Nucleus naturally integrate with specific blockchains.

• Timers: The tool is especially beneficial for applications requiring routine operations, scheduled data processing, or time-sensitive triggers.

Verisense's architecture is a forward-thinking approach that breaks away from the limitations of conventional blockchain frameworks. By eschewing the traditional smart contract model and introducing a nuanced dual-layer system, Verisense enables developers to build more robust, flexible, and efficient applications. Its innovative use of subnets and the Nucleus application model marks a significant step forward in the evolution of blockchain technology, positioning Verisense as a pivotal player in the advancement of decentralized solutions. Further technical details and implementation guidelines will be elaborated on in subsequent chapters of this documentation.

Nucleus

In Verisense, a Nucleus represents a decentralized application running within a subnet. This section delves into the capabilities of a Nucleus, which is compiled into WebAssembly (WASM) bytecode, allowing for efficient execution within the Verisense framework. As previously mentioned in the Introduction, decentralized applications should operate within a cost-effective decentralized environment. In Verisense, the degree of decentralization, determined by the number of nodes securing a Nucleus, is customizable by developers to align with the application’s security needs. The process of achieving consensus among multiple nodes is discussed in detail in the "Monadring" section. Here, we will explore the specific capabilities that Verisense provides for Nucleus applications.

Reverse Gas Mode

Traditional blockchain systems typically employ a "pay-to-write" model, where the actor modifying the ledger incurs a cost (e.g., deploying contracts, changing contract states). This model has long posed a barrier for broad user adoption beyond the realm of Web3 enthusiasts. Verisense innovates with a reverse gas mode, where the platform charges the publisher of the Nucleus for usage. This pricing model resembles that of cloud service providers like AWS. By default, users can interact with a Nucleus (both reads and writes) free of charge, unless the developer explicitly chooses otherwise. This setup aligns more closely with traditional web applications, where certain API calls may require user authentication or payment, while others remain freely accessible.

Feature-Rich SDK

Most blockchain systems primarily offer two functionalities: key-value database read/write operations and signature verification. While smart contract virtual machines introduce Turing-complete development capabilities, the user experience often falls short compared to equivalent Web2 applications. Verisense aims to bridge this gap by offering a robust SDK for Nucleus development, featuring capabilities rarely found in other blockchains:

• Proactive Network Requests: Nucleus can autonomously initiate network requests, enabling dynamic interactions with external data sources and systems.

• Timers: Developers can set timers within a Nucleus to trigger events or operations at scheduled intervals, enhancing application functionality and automation.

• Multitype Public Key Access and Signature Functions: Nucleus can obtain various public key types and execute functions to sign any data.

The picture below shows some use cases of Nucleus.

Lifecycle

The lifecycle of a Nucleus in Verisense encompasses several distinct stages, from creation through operation and potential decommissioning.

1. Creation The creation of a Nucleus is initiated through a legitimate transaction on the Verisense Hostnet. Developers can utilize the vrx command-line tool to facilitate this process. To install the vrx tool, use the following command:

cargo install --git https://github.com/verisense-network/vrs-cli.git

Note: Verisense is subject to rapid development, hence frequent updates may be required for vrx. Please refer to the Developer Guides for detailed instructions.

2. WASM Update

In Verisense, the code of a Nucleus is an integral part of its state. This unification implies that there is no distinction between the initial deployment of code and subsequent updates. The initial deployment of a Nucleus’s WebAssembly (WASM) code is logged as the zeroth event in the Nucleus’s lifecycle.

3. Recovery

Subnet member nodes assigned to a Nucleus initiate an additional WASM virtual machine (different from the Verisense Hostnet) dedicated to operating the Nucleus. These nodes expose the Nucleus's interfaces via an RPC endpoint. Verisense implements a sophisticated billing model that tracks charges based on the following activities:

• Storage usage
• Data write requests
• Invocation of system functions

Each time the state root of a Nucleus is synchronized with the Hostnet, the corresponding account address of the Nucleus is automatically debited with the accrued costs.

Should the balance of a Nucleus's account fall below a predetermined threshold, Verisense will cease to process requests associated with the Nucleus until additional funds are deposited. This mechanism ensures that network resources are allocated efficiently and that the operation of Nucleuses remains financially sustainable.

Indexer

In blockchain networks, maintaining consensus requires that state updates are processed with deterministic time complexity. Consequently, blockchain storage is typically restricted to key-value (KV) databases, where queries and modifications have predictable time complexity. Verisense follows this same principle, with each Nucleus possessing its own isolated storage space implemented using RocksDB.

However, to enable advanced querying capabilities, an additional component akin to a blockchain explorer is often necessary. In the context of a Nucleus, such a component is referred to as an "Indexer," designed to facilitate complex business information queries. Unlike blockchain explorers, which serve the entire network, the Indexer for a Nucleus is a specialized off-chain component tailored by the developer for specific use cases within their application.

The implementation of an Indexer is at the discretion of the Nucleus developer, allowing for flexibility and adaptability to various business requirements. Developers can leverage a range of technologies to build their Indexers, including:

• Traditional relational databases
• Full-text search engines
• Services like AWS serverless architectures

This flexibility enables developers to optimize data indexing and querying based on the particular needs of their application.

Online Demo: Aitonomy

This nucleus demonstrates the abilities of Verisense including bridgeless connection with external blockchains using TSS and AI integration using networking requests.

• Aitonomy: The first AI-driven decentrailized forum for tokenizing communities

• Video on X

Monadring

The Monadring protocol is an essential subprotocol within the Verisense ecosystem, designed to attain consensus for Nucleus operations. It is engineered to function effectively even in small-scale decentralized networks by leveraging an underlying blockchain network, specifically the Verisense Hostnet. Our rigorous design and analysis of the Monadring protocol are documented in a paper available on arXiv. This section offers a concise overview of its foundational principles.

Subnet Topology

Monadring defines a topological structure among network members, forming a ring where all members are connected end-to-end. This ring structure is established by the sorting of Verisense validators via submitted Verifiable Random Function (VRF) proofs as part of their candidacy.

Token Circulation

Within a subnet, a token circulates periodically around the ring, granting state modification rights to the node currently holding it. Though the token structure is complex and detailed in our paper, it can be simplistically understood as containing each node's received events, the current state, and node signatures. When a node receives the token, it first executes events enclosed within, originating from other nodes, followed by its own events. Upon execution, it adds its events to the token, propagating it around the network. This ensures a globally recognized sequence of Nucleus events, defining the sequence of state modifications.

Full Homomorphic Encryption (FHE)

A network relying solely on VRF for random member selection lacks inherent security. Thus, we introduce FHE to sign the states contained within the token, ensuring that nodes cannot view the processing results of others for specific events. By utilizing VRF for node selection and FHE for token signing, the subnet consensus mechanism simulates a Prisoner's Dilemma scenario. Even in small-scale networks, appropriately designed incentive strategies can enforce network security.

Consensus on Network Requests

Nucleus state changes are abstractly referred to as events, akin to ledger-modifying transactions within traditional blockchains. Verisense enhances this with network request capabilities, necessitating special consensus treatment for such requests.

Handling Network Requests

Network requests within a Nucleus are partitioned into two events: request initiation and response reception. Developers initiate a network request by calling an asynchronous function, returning a request_id. For the execution environment, nodes dispatch the request while recording TLS handshake keys as parameters. Nodes execute events only when holding the token, ensuring a fair distribution of request execution across the network.

The consensus for request events is straightforward since given the same event sequence, all nodes generate a network request event. However, network request events within the token are not executed again, as their presence indicates prior execution by a token-holding node.

Handling Network Response Events

HTTPS server certificates and shared handshake keys from the request-initiating node allow deterministic session key computation through the Diffie-Hellman handshake process. Only the node that issued the original request will receive a response. This HTTP response, encrypted with the session key, is set as a response event in the token and passed to other nodes. Upon receiving this event, nodes decrypt and execute it independently.

Compare to other networking solutions

Consensus on Timers

Timers present similar challenges due to their reliance on local system time and scheduling, which cannot be synchronized perfectly across all nodes. Thus, timers are divided into two events: timer setup and timer trigger. Within a subnet, only one node will actually trigger a scheduled timer; the rest will recognize the trigger through token transmission and disable their local timers upon receiving the event.

Conclusion

The Monadring protocol enables Nucleus consensus, balancing flexibility and security in decentralized applications within Verisense. By organizing a strategic combination of VRF, FHE, and unique event handling mechanisms, Monadring supports secure and efficient consensus even in small networks. Detailed exploration of this protocol's intricacies can be found in our arXiv publication, complementing this overview with a deeper theoretical and technical foundation.

Quick Start Guide: Developing Nucleus on Verisense

This guide will help you quickly get started with developing your first Nucleus using Rust. By the end, you’ll have a simple deployed Nucleus and be able to interact with it.

Preparing Environment

First, install Rust and configure it for WebAssembly (Wasm) compilation:

Install Rust:

You can visit the Rust installation page or run the following bash command:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Add the WebAssembly target:

A Nucleus is developed in Rust and compiled into a WebAssembly (Wasm) .wasm executable. In Verisense, the core logic of a Nucleus is hosted and executed on the network in the form of this Wasm file.

WebAssembly (Wasm) is a modern binary instruction format designed to bring high-performance code execution to the web and other environments. It is portable, compact, and secure, allowing code written in multiple languages (such as Rust or C/C++) to run efficiently across various platforms.

To enable Rust to generate Wasm target files, you must add the wasm32-unknown-unknown compilation target to your Rust toolchain. The steps below show how to add this target.

rustup target add wasm32-unknown-unknown

Verify Installation

After installation, run the following commands to ensure Rust and the Wasm target are set up correctly:

rustc --version
cargo --version
rustup target list --installed

You should see output similar to:

• Version numbers for rustc and cargo
• wasm32-unknown-unknown listed among the installed targets

If all commands produce the expected output, your environment is ready for development.

Next, in chapter Creating a Simple Nucleus, you'll learn how to build a simple Nucleus program. In the following sections, we'll walk through the steps to implement, compile, and deploy your first Nucleus instance.

Creating a Simple Nucleus

In this chapter, we will guide you step-by-step through building a simple Nucleus (AVS).

Let's begin by setting up the code structure directly:

Step 1: Create a New Rust Project

Navigate to your desired project directory and create a new Rust project using cargo:

cargo new --lib hello-avs
cd hello-avs

Step 2: Update the Cargo.toml File

Replace the contents of your Cargo.toml with the following:

[package]
name = "hello-avs"
version = "0.1.0"
edition = "2021"

[lib]
crate-type = ["cdylib"]

[dependencies]
vrs-core-sdk = { version = "0.2.0" }
parity-scale-codec = { version = "3.6", features = ["derive"] }
scale-info = { version = "2.11.6", features = ["derive"] }

Step 3: Implement the Core Logic

Edit the file src/lib.rs and insert the following code:

#![allow(unused)]
fn main() {
use scale_info::TypeInfo;
use vrs_core_sdk::codec::{Decode, Encode};
use vrs_core_sdk::nucleus;
#[derive(Debug, Decode, Encode, TypeInfo)]
pub struct User {
    pub id: u64,
    pub name: String,
}
#[nucleus]
pub mod nucleus {
    use crate::User;
    use vrs_core_sdk::codec::{Decode, Encode};
    use vrs_core_sdk::{get, post, storage};
    #[post]
    pub fn add_user(user: User) -> Result<u64, String> {
        let key = [&b"user:"[..], &user.id.to_be_bytes()[..]].concat();
        println!("{:?}", key);
        storage::put(&key, &user.encode()).map_err(|e| e.to_string())?;
        Ok(user.id)
    }

    #[get]
    pub fn get_user(id: u64) -> Result<Option<User>, String> {
        let key = [&b"user:"[..], &id.to_be_bytes()[..]].concat();
        println!("{:?}", key);
        let result = storage::get(&key).map_err(|e| e.to_string())?;
        let user = result.map(|data| User::decode(&mut &data[..]).unwrap());
        Ok(user)
    }
}

}

Step 4: Compile the Project to WebAssembly

Finally, compile your project to WebAssembly by running the following command in your project's root directory (hello-avs):

cargo build --release --target wasm32-unknown-unknown

Upon successful compilation, you'll see a message similar to:

Finished `release` profile [optimized] target(s) in 0.09s

You have successfully created a simple Nucleus (AVS). The compiled WebAssembly executable (hello_avs.wasm) will be available in the directory target/wasm32-unknown-unknown/release.

What Does hello-avs Do?

Let's break down the functionality provided by this simple Nucleus step-by-step:

First, a struct named User is defined:

#![allow(unused)]
fn main() {
#[derive(Debug, Decode, Encode, TypeInfo)]
pub struct User {
    pub id: u64,
    pub name: String,
}
}

Nucleus interfaces are exposed externally using macros such as #[post] and #[get].

• The #[post] macro is used for interfaces that modify the blockchain's storage, as modifications consume gas.
• The #[get] macro is used for interfaces that do not modify the storage.

The storage interaction APIs are as follows:

• storage::put writes data to storage.
• storage::get reads data from storage.

Purpose of TypeInfo and #[nucleus]

TypeInfo

#![allow(unused)]
fn main() {
#[derive(Debug, Decode, Encode, TypeInfo)]
pub struct User {
    pub id: u64,
    pub name: String,
}
}

The TypeInfo derive macro comes from the scale-info crate. It plays a crucial role in generating type metadata at compile time, which is then embedded into your compiled WebAssembly module.

This metadata serves several important purposes:

• ABI Generation: TypeInfo enables automatic generation of an Application Binary Interface (ABI). This allows external clients (such as frontends, other chain modules, or the Verisense dashboard) to understand the precise structure of types like User, including their field names and data types.

• Cross-language Compatibility: Since the type descriptions are included, tools written in JavaScript, Python, or other languages can introspect your WebAssembly module and correctly encode/decode the data to call your functions.

• Auto-generated UI: The Verisense dashboard, for example, uses this type metadata to automatically generate input forms. It knows that when it needs a User, it should display an input for id: u64 and name: String.

In short:

TypeInfo ensures that your data structures are fully described for ABI export, enabling automated tooling, documentation, and seamless cross-language integration.

#[nucleus]

#![allow(unused)]
fn main() {
#[nucleus]
pub mod nucleus {
    ...
}
}

The #[nucleus] attribute macro comes from the vrs-core-sdk and is fundamental to marking this Rust module as a Nucleus.

Its primary responsibilities are:

• Export ABI: It collects all functions inside this module that are marked with #[get], #[post], or #[init] and registers them in the Nucleus ABI. This means when your .wasm is deployed, the blockchain runtime or the Verisense dashboard knows exactly which functions are exposed, along with their input/output types.

• Generate Glue Code: It automatically generates the necessary export functions (such as _invoke) that the blockchain’s Wasm executor will call. This abstracts away low-level host bindings, so you only need to focus on your Rust functions.

• Provide a Clean Namespace: By wrapping your interfaces inside the #[nucleus] macro, you avoid polluting the global scope. All public functions intended to be callable externally are neatly contained and registered.

In short:

#[nucleus] transforms your Rust module into a deployable AVS, automatically exporting its ABI and wiring up the execution glue so it can run inside the Verisense runtime.

Add a New User with an ID

#![allow(unused)]
fn main() {
#[post]
pub fn add_user(user: User) -> Result<u64, String> {
    // Construct the user's key
    let key = [&b"user:"[..], &user.id.to_be_bytes()[..]].concat();
    // Write data to storage
    storage::put(&key, &user.encode()).map_err(|e| e.to_string())?;
    Ok(user.id)
}
}

Retrieve User by ID

#![allow(unused)]
fn main() {
#[get]
pub fn get_user(id: u64) -> Result<Option<User>, String> {
    // Construct the user's key
    let key = [&b"user:"[..], &id.to_be_bytes()[..]].concat();
    // Retrieve data from storage
    let result = storage::get(&key).map_err(|e| e.to_string())?;
    // Decode the data into a User struct
    let user = result.map(|data| User::decode(&mut &data[..]).unwrap());
    Ok(user)
}
}

How to Deploy a Nucleus

The previous chapter, Creating a Simple Nucleus, introduced the steps for creating a basic Nucleus. In step 4, we compiled a Rust project into WebAssembly, resulting in a file named hello_avs.wasm. This chapter covers the deployment process for this hello_avs.wasm file on the Verisense network.

Preparing Your Environment

First, install the Verisense command-line tools. Execute the following command in any directory:

cargo install --git https://github.com/verisense-network/vrs-cli.git

If vrx --version runs successfully, the installation is complete.

Creating a Verisense Account

Run the following command to generate an account and save the private key:

vrx account generate --save

This command generates an account and stores the private key in ~/.vrx/default-key. Example output:

Phrase: exercise pipe nerve daring census inflict cousin exhaust valve legend ancient gather
Seed: 0x35929b4e23d26c5ba94d22d32222128e56f5a7dce35f9b36b467ac2be2b4d29b
Public key: 0x9cdaa67b771a2ae3b5e93b3a5463fc00e6811ed4f2bd31a745aa32f29541150d
Account Id: kGj5epfCkuae7DJpezu5Qx6mp96gHmLv2kDPHHTdJaEVNptRt

.vrx Directory Structure

The ~/.vrx directory stores multiple keys, typically named after their respective public keys. The default-key file points to the current seed in use. You can verify if the seed you're using matches the one stored in default-key.

Obtaining Test Tokens

Interact with the Verisense Faucet Bot on Telegram. Provide your account ID to request free $VRS tokens for testing purposes.

Deploying the Nucleus

Step 1: Create a Nucleus

Execute the command:

vrx nucleus create hello_avs --rpc wss://rpc.beta.verisense.network --capacity 1

This will return a unique Nucleus ID within the Verisense network. Example output:

Nucleus created.
  ID: kGgGtCimpkywYrQ7yULt3pEZYwetW35NrupEfSyTavTPULXbV
  Name: hello_avs
  Capacity: 1

Step 2: Install the Nucleus Executable

Deploy the WebAssembly file with the following command:

vrx nucleus install --id kGgGtCimpkywYrQ7yULt3pEZYwetW35NrupEfSyTavTPULXbV --wasm hello_avs.wasm --rpc wss://rpc.beta.verisense.network

Example output:

Transaction submitted: "0xa93f13635f1e3e9ee1a774cd920792f414a41c21d02464919db75010b6763ae6"

Creating a Nucleus and installing its executable file are two distinct operations. After creating the Nucleus, the Verisense network assigns a unique Nucleus ID, which will be used for subsequent deployments. Although the Nucleus code is upgradeable, the Nucleus ID remains fixed.

Interacting with Nucleus

In the previous chapter, we deployed a Nucleus with two interfaces:

#![allow(unused)]
fn main() {
#[post]
pub fn add_user(user: User) -> Result<u64, String> {
    // Construct the user's key
    let key = [&b"user:"[..], &user.id.to_be_bytes()[..]].concat();
    // Write data to storage
    storage::put(&key, &user.encode()).map_err(|e| e.to_string())?;
    Ok(user.id)
}
}

#![allow(unused)]
fn main() {
#[get]
pub fn get_user(id: u64) -> Result<Option<User>, String> {
    // Construct the user's key
    let key = [&b"user:"[..], &id.to_be_bytes()[..]].concat();
    // Retrieve data from storage
    let result = storage::get(&key).map_err(|e| e.to_string())?;
    // Decode the data into a User struct
    let user = result.map(|data| User::decode(&mut &data[..]).unwrap());
    Ok(user)
}
}

This chapter explains how to interact with this Nucleus.

Encoding and Decoding

We use Polkadot's Codec crate to encode and decode data within the Nucleus.

For different programming languages, the following libraries can be used for encoding:

• AssemblyScript - LimeChain/as-scale-codec
• C - MatthewDarnell/cScale
• C++ - qdrvm/scale-codec-cpp
• JavaScript - polkadot-js/api
• Dart - leonardocustodio/polkadart
• Haskell - airalab/hs-web3
• Golang - itering/scale.go
• Java - splix/polkaj
• Python - polkascan/py-scale-codec
• Ruby - wuminzhe/scale_rb
• TypeScript - parity-scale-codec-ts, scale-ts, soramitsu/scale-codec-js-library, subsquid/scale-codec

For instance, consider the following structure:

#![allow(unused)]
fn main() {
pub struct User {
    pub id: u64,
    pub name: String,
}
}

With id = 123456 and name = "nucleus_1", the encoded data is:

40e2010000000000246e75636c6575735f31

To invoke the add_user interface via JSON-RPC:

curl --location 'https://rpc.beta.verisense.network' \
--header 'Content-Type: application/json' \
--data '
{
    "jsonrpc": "2.0",
    "method": "nucleus_post",
    "params": [
        "kGgGtCimpkywYrQ7yULt3pEZYwetW35NrupEfSyTavTPULXbV", // Nucleus ID
        "add_user", // Function name
        "40e2010000000000246e75636c6575735f31" // Encoded parameters
    ],
    "id": 1
}

Example response:

{"jsonrpc":"2.0","result":"0040e2010000000000","id":1}

To invoke the get_user interface via JSON-RPC:

curl --location 'https://rpc.beta.verisense.network' \
--header 'Content-Type: application/json' \
--data '
{
    "jsonrpc": "2.0",
    "method": "nucleus_get",
    "params": ["kGgGtCimpkywYrQ7yULt3pEZYwetW35NrupEfSyTavTPULXbV", "get_user", "40e2010000000000"],
    "id": 1
}'

Example response:

{"jsonrpc":"2.0","result":"000140e2010000000000246e75636c6575735f31","id":1}

Decoding the result yields:

#![allow(unused)]
fn main() {
Ok(Some(User { id: 123456, name: "nucleus_1" }))
}

Starting a Local Verisense Node

First, we need to clone the Verisense node repository:

git clone https://github.com/verisense-network/verisense

Then, navigate into the project directory:

cd verisense

Next, we build the node binary in release mode:

cargo build --release

Once the build is complete, we can start a local Verisense node. Here, we start an Alice development node with RPC enabled on port 9944:

target/release/verisense --alice --dev --unsafe-rpc-external --rpc-port 9944

After running this command, you will see that the local node has started successfully and is running as an Alice node.

This local node will allow us to deploy and interact with our Nucleus for development and testing purposes.

Debugging on Beta Network

To access logs for debugging purposes on the beta network, visit: https://rpc.beta.verisense.network/<NUCLEUS_ID>/logs

Advanced guides

This chapter introduces several advanced features, including:

• KV Storage
• Setting a timer
• Making http requests
• Threshold Signature Scheme

Key Value Storage

Verisense has a full set of API on KV storage. Let's look at it.

APIs

put

Put a value into database via a key.

pub fn put(key: impl AsRef<[u8]>, value: impl AsRef<[u8]>) -> CallResult<()> 

Example:

use vrs_core_sdk::{get, post, storage};

#[post]
pub fn add_user(mut u: User) -> Result<(), String> {
    let key = b"user:001";
    let val: Vec<u8> = u.encode();     
    storage::put(&key, &val).map_err(|e| e.to_string())?;

    Ok(())
}

Note: storage::put() can only be used in the function decorated by #[post].

del

Delete a value from database via a key.

pub fn del(key: impl AsRef<[u8]>) -> CallResult<()>

Example:

use vrs_core_sdk::{get, post, storage};

#[post]
pub fn delete_user() -> Result<(), String> {
    let key = b"user:001";

    storage::del(&key).map_err(|e| e.to_string())?;

    Ok(())
}

Note: storage::del() can only be used in the function decorated by #[post].

get

Get a value from database via a key.

pub fn get(key: impl AsRef<[u8]>) -> CallResult<Option<Vec<u8>>> {

Example:

#[get]
pub fn get_user() -> Result<Option<User>, String> {
    let key = b"user:001";
    let r = storage::get(&key).map_err(|e| e.to_string())?;
    let instance = r.map(|d| User::decode(&mut &d[..]).unwrap());
    Ok(instance)
}

get_range

Get a batch of entries from the database with "start_key" and direction, the limit maximum is 1000

pub fn get_range(
    start_key: impl AsRef<[u8]>,
    direction: Direction,
    limit: usize,
) -> CallResult<Vec<(Vec<u8>, Vec<u8>)>> 

Example:

#[get]
pub fn get_user_range() -> Result<(), String>  {
    let prefix_key = b"user:";
    let r = storage::get_range(&key, Direction::Forward, 100).map_err(|e| e.to_string())?;
    ...
}

delete_range

Removes the database entries in the range [start_key, end_key)

pub fn delete_range(start_key: impl AsRef<[u8]>, end_key: impl AsRef<[u8]>) -> CallResult<()> 

Example:

#[post]
pub fn delete_user_range() -> Result<(), String>  {
    let start_key = b"user:001";
    let end_key = b"user:100";
    let r = storage::delete_range(&start_key, &end_key).map_err(|e| e.to_string())?;
    ...
}

Note: storage::delete_range() can only be used in the function decorated by #[post].

search

Search a value with a key prefix and direction.

pub fn search(
    key_prefix: impl AsRef<[u8]>,
    direction: Direction,
) -> CallResult<Option<(Vec<u8>, Vec<u8>)>> 

Example:

use vrs_core_sdk::storage::Direction;

pub fn search_blog_id() {
   let key = [&b"blog:"[..], &0u64.to_be_bytes()[..]].concat();
   let first_blog = storage::search(&key, Direction::Forward).unwrap();
   let key = [&b"blog:"[..], &u64::MAX.to_be_bytes()[..]].concat();
   let last_blog = storage::search(&key, Direction::Reverse).unwrap();
   assert!(first_blog.is_some());
   assert!(last_blog.is_some());
}

Timer

Verisense provides a powerful timer module that enables developers to schedule delayed or recurring function executions. The module consists of:

• #[init]
• #[timer]
• set_timer!()

#[init]: Initialization Hook

A Rust function decorated with the #[init] attribute macro serves as a special initialization handler. This function is automatically invoked when a new version of the WASM module is deployed or upgraded.

Example:

#![allow(unused)]
fn main() {
#[init]
pub fn timer_init() {
    storage::put(b"delay", format!("init").as_bytes());
}
}

In this example, timer_init() will be called automatically upon deployment of a new AVS WASM version, allowing you to perform any necessary initialization tasks.

set_timer! and #[timer]: Scheduling Timers

The set_timer! macro is used to schedule a new timer that triggers a handler function after a specified delay. Its syntax is:

#![allow(unused)]
fn main() {
set_timer!(Duration, timer_handler(params));
}

Basic Usage

#![allow(unused)]
fn main() {
#[post]
pub fn test_set_timer() {
    storage::put(b"delay", format!("init").as_bytes());

    let a = "abc".to_string();
    let b = 123;

    set_timer!(std::time::Duration::from_secs(4), test_delay(a, b));
}

#[timer]
pub fn test_delay(a: String, b: i32) {
    storage::put(b"delay", format!("delay_complete {} {}", a, b).as_bytes()).unwrap();
}
}

In this example:

• The test_set_timer function sets a timer that will trigger after 4 seconds.
• When the timer fires, the test_delay function is executed with the provided arguments.
• All timer handler functions must be decorated with the #[timer] attribute.

The set_timer! macro allows you to directly pass arguments to the timer handler, which are safely serialized and deserialized by the runtime.

Implementing Intervals (Recurring Timers)

By default, set_timer! schedules one-shot timers. To implement periodic execution (intervals), you can schedule the next timer within the timer handler itself, effectively creating a recursive loop.

Example:

#![allow(unused)]
fn main() {
#[post]
pub fn test_set_timer() {
    set_timer!(std::time::Duration::from_secs(2), run_interval());
}

#[timer]
pub fn run_interval() {
    // Business logic executed on each interval
    storage::put(b"interval", b"running");

    // Schedule the next execution
    set_timer!(std::time::Duration::from_secs(1), run_interval());
}
}

In this pattern:

1. An initial timer is set to trigger after 2 seconds.
2. Inside run_interval, your business logic is executed.
3. At the end of each execution, a new timer is scheduled to run after 1 second.
4. This creates a continuous periodic execution loop.

This recursive approach allows you to implement interval-like behavior without native interval support.

Summary

Making a Request

To make a http request in Verisense nucleus, you have to split the process into two parts:

1. make request: making a http request and return the request_id immediately;
2. get the callback: a #[callback] function will be called with the request_id when the response is ready.

For example, let's request the https://www.google.com.

use vrs_core_sdk::{CallResult, http::{*, self}, callback, post};

#[post]
pub fn request_google() {
    let id = http::request(HttpRequest {
        head: RequestHead {
            method: HttpMethod::Get,
            uri: "https://www.google.com".to_string(),
            headers: Default::default(),
        },
        body: vec![],
    })
    .unwrap();
    vrs_core_sdk::println!("http request {} enqueued", id);
}

#[callback]
pub fn on_response(id: u64, response: CallResult<HttpResponse>) {
    match response {
        Ok(response) => {
            let body = String::from_utf8_lossy(&response.body);
            vrs_core_sdk::println!("id = {}, response: {}", id, body);
        }
        Err(e) => {
            vrs_core_sdk::eprintln!("id = {}, error: {:?}", id, e);
        }
    }
}

You have to maintain the request ids by a global structure such as a Hashmap.

Threshold Signature Scheme (TSS)

What is Threshold Signature Scheme?

In traditional signature schemes, the private signing key is usually held by a single entity. Once this private key is compromised, the entire system's security is broken. In Threshold Signature Scheme (TSS), the private key is split into multiple shares and distributed among multiple participants. No single participant can reconstruct the full private key alone.

TSS allows us to set a threshold. For example:

• In a 2-of-3 TSS, three participants hold key shares. Any two participants can jointly generate a valid signature, but no single participant can sign alone.

This greatly improves security and eliminates single points of failure.

TSS Use Cases in Verisense

On the Verisense platform, TSS is mainly used for:

• Cross-chain bridge custody: ensuring secure multi-party control over cross-chain assets.
• Vault locking: for example, in multi-party governance or multi-signature wallets, ensuring that sensitive operations require multiple parties to jointly authorize.
• Monadring Consensus Algorithm.

Code Examples

The Verisense SDK provides out-of-the-box support for TSS. Below are examples of how to obtain TSS public keys and initiate signing:

Retrieve TSS Public Key

Obtaining a public key is usually for generating transfer addresses or on-chain address binding:

#![allow(unused)]
fn main() {
use hex;
use vrs_core_sdk::{get, tss::tss_get_public_key, tss::CryptoType};

#[get]
pub fn get_public_key(crypto_type: u8, tweak: String) -> Result<String, String> {
    let result =
        tss_get_public_key(CryptoType::try_from(crypto_type)?, tweak).map_err(|e| e.to_string())?;
    Ok(hex::encode(result))
}
}

• crypto_type specifies the signature algorithm type.
• tweak is used to derive a child public key based on the master key share. Different tweaks generate different deterministic child keys under the same master key share.

Generate TSS Signature

In actual transfer or authorization scenarios, the system can initiate a TSS signing request:

#![allow(unused)]
fn main() {
use hex;
use vrs_core_sdk::{get, tss::tss_sign, tss::CryptoType};

#[get]
pub fn sign(crypto_type: u8, tweak: String, message: String) -> Result<String, String> {
    let result =
        tss_sign(CryptoType::try_from(crypto_type)?, tweak, message).map_err(|e| e.to_string())?;
    Ok(hex::encode(result))
}
}

• message is the content to be signed (usually a hash value).
• The return value is the signature result encoded in hex.

Supported Signature Algorithms

Verisense currently supports the following signature algorithms:

#![allow(unused)]
fn main() {
#[repr(u8)]
#[derive(Encode, Decode)]
pub enum CryptoType {
    P256 = 0,
    Ed25519 = 1,
    Secp256k1 = 2,
    Secp256k1Tr = 3,
    Ed448 = 4,
    Ristretto255 = 5,
    EcdsaSecp256k1 = 6,
}
}

• EcdsaSecp256k1 is used for ETH/BSC.
• The rest without the Ecdsa prefix (Ed25519, Ristretto255, Secp256k1, Secp256k1Tr, P256, Ed448) use Schnorr signatures.

Schnorr signature schemes provide better aggregation properties and security in multi-party signature (MPC/TSS) scenarios, making them ideal for high-performance and decentralized use cases.

Example: 2-of-3 Signing Process

Suppose we have Alice, Bob, and Charlie forming a 2-of-3 TSS group:

1. During system initialization, each of the three participants receives a private key share.
2. When a signature is needed, Alice and Bob collaborate through secure channels to generate a valid signature.
3. Even if Charlie is offline, Alice and Bob can still successfully generate the signature.
4. No single participant (e.g., only Alice) can generate the signature alone.

This mechanism ensures both the security and flexibility of asset control, making it very suitable for decentralized custody, cross-chain bridges, DAO governance, and other multi-party control scenarios.

Building Agents on the Verisense Network

What is an Agent?

On the Verisense Network, an Agent is an autonomous, on-chain entity designed to perform complex tasks by reasoning, interacting with its environment, and coordinating with other systems. It is not just a static smart contract but a dynamic, intelligent program defined by a powerful core formula:

Agent = Context + Tools + LLM

This architecture allows for the creation of sophisticated agents that can manage digital assets, interact with off-chain data, and collaborate in a decentralized manner. Let's break down each component in detail.

1. Context: The Agent's State and Memory

The Context is the agent's memory and operational awareness. It provides the stateful foundation that allows an agent to go beyond simple, one-off transactions and engage in meaningful, multi-step tasks. This includes:

• Goals & Objectives: The primary mission the agent is programmed to achieve (e.g., "maximize staking rewards across three protocols" or "execute a trade when market volatility exceeds a 5% threshold").
• Knowledge Base: A repository of specialized information or historical data the agent can draw upon to make more informed decisions.
• Session Data: The real-time, short-term memory of its current task, including conversation history, user preferences, and the status of ongoing operations.
• Configuration: The agent's unique settings, such as its risk tolerance, security parameters, and credentials for accessing specific tools.

Verisense provides a flexible, hybrid approach to storing this context, balancing the trade-offs between security, cost, and accessibility:

• Off-Chain Storage: For large volumes of non-critical data, context can be stored in traditional off-chain databases or decentralized storage networks (like IPFS). This is ideal for knowledge bases or extensive logs where on-chain immutability is not required.
• On-Chain Storage via Nucleus: For critical state information—such as goals, configurations, or the final outcome of a task—agents can leverage Verisense Nucleus. Nucleus acts as a secure, on-chain storage and messaging layer, ensuring that the agent's core context is immutable, transparent, and auditable.

2. Tools: The Agent's Arms and Hands

Tools (or functions) are what allow an agent to break out of the blockchain's sandbox and interact with the wider digital world. They are the practical capabilities the agent can call upon to execute the steps of its plan. Verisense supports a rich ecosystem of both on-chain and off-chain tools:

• Off-Chain Tools (The MCP Model): Agents can securely access any external resource via off-chain tools, similar to the Multi-Party Computation (MCP) model. This includes:

  • HTTP APIs: For querying web services, fetching market data from exchanges, or interacting with social media platforms.
  • Database Access: Connecting to private or public databases to retrieve or store information.
  • Executing Code: Running scripts in various languages (e.g., Python, JavaScript) for complex data analysis or computation.

• On-Chain Tools (The Nucleus Model): Verisense Nucleus provides a suite of powerful on-chain tools that enable secure and decentralized operations:

  • Threshold Signature Scheme (TSS): This is a cornerstone feature for cross-chain operations. TSS allows a group of network nodes to collectively generate a signature to authorize a transaction on another blockchain (like Bitcoin or Ethereum) without ever forming a single private key. An agent can use this tool to manage assets or interact with dApps across different ecosystems seamlessly.
  • http: This tool is a built-in decentralized oracle that allows an agent to make secure HTTP requests and retrieve data from the off-chain world. An agent can submit a URL to the Nucleus layer, and the Verisense network validators will fetch the data, come to a consensus on the result, and deliver it back to the agent on-chain. This is critical for agents that need to react to real-world information, such as fetching current asset prices, weather data, or sports scores to trigger an on-chain action.
  • timer: This tool functions as a decentralized and reliable on-chain scheduler, often called a "cron service" for smart contracts. An agent can use the timer tool to register a function to be executed at a specific future time, block number, or on a recurring interval. This enables time-based strategies and automation, such as automatically harvesting staking rewards every 24 hours, executing a series of trades at set intervals (TWAP), or managing subscriptions.

3. LLM: The Reasoning Engine

The LLM is the agent's brain. It provides the cognitive power for reasoning, language comprehension, and, most importantly, dynamic planning. Within the Verisense framework, the LLM is responsible for:

• Instruction Interpretation: Understanding a user's high-level goals, even if they are ambiguous or complex.
• Response Formulation: Communicating its status, results, and actions in a clear, human-understandable manner.
• Dynamic Interaction Planning: This is where the agent's intelligence truly shines. Based on the user's goal, the LLM creates a step-by-step plan. It selects the right tool for each step, processes the output, and adjusts the plan based on the results. For example, if a web API call fails, the LLM can decide to try an alternative data source or notify the user.

Fast Deploy an Agent

1. Create an agent with the A2A protocol.
2. Register the agent in the Verisense Dashboard.
3. @ your agent in Sensespace.

AItonomy developer guide

This document helps you use the API to operate AItonomy in a Node.js environment

Prerequisites

• Node.js
• npm

Setting up an RPC client

Install @polkadot/rpc-provider:

npm install @polkadot/rpc-provider

Create an rpc.ts file to connect to the AItonomy RPC server:

import { HttpProvider } from "@polkadot/rpc-provider";

const provider = new HttpProvider(
  `${process.env.AITONOMY_RPC_HOST}:${process.env.AITONOMY_RPC_PORT}`
);

export async function getRpcClient() {
  if (!provider.isConnected) {
    await provider.connect();
    console.log("provider reconnected");
    if (!provider.isConnected) {
      throw new Error("provider not connected");
    }
  }
  return provider;
}

Using @polkadot/types-codec to encode parameters

Install @polkadot/types-codec

For a quick start, you can install the @verisense-network/vemodel-types library provided by Verisense to encode the parameters needed by AItonomy:

npm install @polkadot/types
npm install @polkadot/types-codec
npm install @verisense-network/vemodel-types

For example, PostThreadArg:

import { PostThreadArg, registry } from "@verisense-network/vemodel-types";

export interface CreateThreadPayload {
  community: string;
  title: string;
  content: Array<number>;
  images: string[];
  mention: Uint8Array[];
}

const args: CreateThreadPayload = {
  community: "Test",
  title: "Test",
  content: compressString("Test"),
  images: [],
  mention: [],
};

const payloadHex = new PostThreadArg(registry, args).toHex();

You can import types from polkadot/codec from @verisense-network/vemodel-types/dist/codec:

import { Struct, u64 } from "@verisense-network/vemodel-types/dist/codec";

Signing the parameter content (Payload)

import { PostThreadPayload, registry } from "@verisense-network/vemodel-types";

const { data: account } = await getAccountInfo({
  accountId: user.address,
});
const nonce = account.nonce;

const nonceEncoded = new u64(registry, nonce).toU8a();

const payload = {};

const payloadEncoded = new PostThreadPayload(registry as any, payload).toU8a();

const messageBuf = new Uint8Array(nonceEncoded.length + payloadEncoded.length);
messageBuf.set(nonceEncoded, 0);
messageBuf.set(payloadEncoded, nonceEncoded.length);

const message = Buffer.from(messageBuf).toString("hex");

// In this example, we call the wallet signature in the browser. If you have a private key, you can use libraries like ethers to sign
const signature = await signMessage(wagmiConfig, { message });

const signer = new Uint8Array(Object.values(user.publicKey));

return {
  signature: hexToBytes(signature),
  signer,
  nonce,
};

Complete code: aitonomy/sign.ts#L16

If you need to understand more about Nucleus signature verification logic, you can visit veforum/lib.rs#L361

Using RPC to request AItonomy RPC API

For example, a complete example of creating a Thread:

import pako from "pako";
import { PostThreadArg, registry } from "@verisense-network/vemodel-types";

// pako is a gzip library that can compress strings into binary
export function compressString(str: string): Uint8Array {
  const uint8Array = new TextEncoder().encode(str);
  const compressed = pako.gzip(uint8Array);
  return compressed;
}

const args: CreateThreadPayload = {
  community: "Test",
  title: "Test",
  content: compressString("Test"),
  images: [],
  mention: [],
};

const signature = {};

const rpcArgs = {
  ...signature,
  payload: args,
};

const payload = new PostThreadArg(registry, rpcArgs).toHex();

try {
  const provider = await getRpcClient();
  const response = await provider.send<any>("nucleus_post", [
    nucleusId,
    "post_thread",
    payload,
  ]);

  const responseBytes = Buffer.from(response, "hex");

  /**
   * Result<ContentId, String>
   */
  const ResultStruct = Result.with({
    Ok: ContentId,
    Err: Text,
  });

  const decoded = new ResultStruct(registry, responseBytes);

  if (decoded.isErr) {
    throw new Error(decoded.asErr.toString());
  }
  const idHex = decoded.asOk.toHex();
  return idHex;
} catch (e) {
  throw e;
}

After successful creation, the id is the created thread id.

Complete code: thread/Create.tsx#L101

If you need to understand more about the logic of Nucleus creating a Thread, you can refer to src/nucleus.rs#L219