Trigslink

Demo

About

The problem it solves # Trigslink Trigslink is a decentralized Model Context Protocol network. ### The Problem It Solves Today, AI assistants and agents are powerful but isolated. They're often trapped behind siloed platforms, with limited access to live data or actionable external context. Accessing high-value context (like real-time analytics, wallet data, or DeFi intelligence) usually means building your own backend or trusting centralized platforms. This limits innovation, especially for: - Defi users seeking onchain access to tools like yield optimizers, trading agents, research assistants, all whilst retaining custody of their subscriptions onchain - The unbanked, who can’t participate in AI-powered systems due to banking restrictions, KYC barriers, or fiat-only access models - DeFi protocols that require trusted offchain interpretation or LLM-enriched data to operate securely and contextually - Autonomous Economic Agents, which rely on persistent context delivery and require five-nines availability to maintain uninterrupted operation and autonomy # What Trigslink Does Trigslink makes permissionless access to context-aware AI services possible, not through credit cards, API keys, or SaaS plans, but with onchain wallets and decentralized infrastructure. A permissionless layer where anyone can run an MCP locally, register it onchain, and offer AI-enriched context as a service, with subscriptions priced in USD and settled in $AVAX. Consumers can then subscribe to these MCPs and query them directly, with no API keys, no SaaS lock-ins, and no central authority. Trigslink is the discovery, billing, and access layer for onchain MCPs. # Services Used ### Chainlink Price Feeds Used to convert USD-denominated registration & subscription prices into $AVAX at payment time. https://github.com/trigslink/blockend/blob/main/contracts/McpConsumer.sol#L75 https://github.com/trigslink/blockend/blob/main/contracts/McpProvider.sol#L58 > Enables fair, decentralized pricing without relying on offchain conversions. ### Chainlink Automation Once an MCP is subscribed to, Automation automatically ends the subscription after 30 days. https://github.com/trigslink/blockend/blob/main/contracts/McpConsumer.sol#L143 https://github.com/trigslink/blockend/blob/main/contracts/McpConsumer.sol#L166 > Ensures clean, hands-free subscription lifecycle management. ### Avalanche Chosen for its fast, low-cost EVM execution and native Chainlink support. https://github.com/trigslink/blockend/blob/main/hardhat.config.ts#L16 > Ideal environment for rapid iteration, testing of onchain agent infrastructure and upgradability with subnets. Check out our YouTube channel for more content! https://www.youtube.com/@trigslink

How it's made

Challenges we ran into # Brainstorming We originally explored a binary prediction market powered by LLMs and Chainlink Functions for resolution management. One prompt might be: “Has there been a magnitude 7 earthquake in India between July 1st, 2025, and December 1st, 2025?” Uncomfortable to ask, but that's the basis of insurance contracts, which are themselves predictions. With dynamic prompt submission, the range of possible binary markets becomes virtually limitless. Unfortunately, the complexity and uncertain legal framing led us to pivot toward a more foundational protocol: Model Context Protocols (MCPs), which could still power such markets in the future. # Frontend We initially began building a React frontend for better styling, state management, and web3-native libraries. However, time constraints prevented us from completing it to a shippable level. As a result, we deployed a simpler HTML/CSS/JS version as a failover, functional but limited. # Lack of Chainlink Functions Integration A power move we missed was using a Chainlink Function on an Automation CRON to periodically call each MCP’s deployed URL, and trigger penalizeProvider() if it fails to respond: https://github.com/trigslink/blockend/blob/main/contracts/McpConsumer.sol#L113 This is crucial for enforcing uptime SLAs and will be a priority moving forward. # Team Availability Not all members were available to collaborate at set times, which made syncing difficult and slowed progress. Async work helped, but real-time problem solving was limited.