Mudra
We review, analyze, and suggest. You take action.
About
The problem it solves Managing a DeFi portfolio today is either completely manual, driven by gut feeling and Twitter threads, or fully automated by bots that move your funds without your consent. Both approaches fail: one leads to panic decisions, the other to blind trust in opaque algorithms. Mudra sits in the middle. Three specialized AI agents work together to protect you: a Watcher that monitors real-time market conditions like volatility, sentiment, liquidity, and drawdowns; a Strategist that computes a multi-factor risk score and proposes strategies tailored to your specific goal, whether that's saving for a house or maximizing yield; and an Executor that only acts after you cryptographically sign your approval through your wallet. The AI never has custody of your funds and never makes a move without your explicit consent. Every recommendation and every action is logged immutably to Hedera Consensus Service, creating a verifiable audit trail that no one can rewrite. Mudra is built for holders who want data-driven portfolio decisions without giving up control, for DeFi users who need risk monitoring but don't have time to stare at charts, and for anyone who wants a provable on-chain record of why every trade was made. Use of AI tools and agents Mudra uses a three-agent architecture where each AI agent has a single responsibility and they operate in a strict sequential pipeline. The Watcher agent runs first, pulling live market data from CoinGecko and sentiment indicators like the Fear and Greed Index, funding rates, and ATH drawdowns, then computes a structured risk signal for the user's portfolio. That signal is passed to the Strategist agent, which uses an LLM (currently served through OpenRouter) to interpret the user's natural language goal, such as "saving for a house" or "maximize yield aggressively," and classify it into a risk profile that adjusts how the five risk components (concentration, volatility, sentiment, liquidity, drawdown) are weighted. The Strategist then generates a strategy recommendation with multiple candidate plans at different risk levels, picks the one closest to the user's stated risk tolerance, and uses the LLM again to write a plain English explanation of its reasoning. The Executor agent sits idle until the user reviews the plan and cryptographically signs their approval through their wallet using EIP-712 typed data signing. Only after that signature is verified does the Executor act, logging the approved plan and execution to Hedera Consensus Service as an immutable audit trail. Each agent also gets minted as an iNFT on Hedera with its "brain" (identity, capabilities, and session context) uploaded to 0G decentralized storage, making the agents themselves verifiable on-chain artifacts rather than just backend processes.
How it's made
Challenges we ran into The biggest challenge was getting the AI reasoning layer to work reliably on a free tier. We initially used Google's Gemini API, but the free tier has a hard limit of 20 requests per day per model, and since each session run triggers multiple AI calls (goal interpretation, risk reasoning, and strategy explanation), we'd burn through the entire daily quota in about six runs. We tried throttling, serializing requests, and adding exponential backoff, but the fundamental quota limit couldn't be engineered around. The solution was switching to OpenRouter, which provides access to multiple free models through a single API, letting us fall back gracefully if one model is overloaded. The second major hurdle was getting risk tolerance settings to actually persist. Because the app uses Next.js with server-side rendering, the standard React pattern of initializing state from localStorage silently fails since localStorage doesn't exist on the server, so the saved value would get overwritten with the default on every page load. We fixed this by hydrating from localStorage inside a useEffect after the component mounts on the client. Finally, integrating Hedera's SDK for the immutable audit trail required careful handling of different key formats (ED25519 vs ECDSA) depending on whether we were using the native SDK path or the EVM contract path,