{"slug": "architecting-a-self-governing-de-fi-agent-here-s-how-it-ranked", "title": "Architecting a Self Governing De-Fi Agent - Here's How It Ranked", "summary": "Creation of Nostra, a constitutional DeFi agent built on ElizaOS v2 and deployed on Nosana's decentralized GPU network, which ranked #6 out of 105 submissions in Nosana's Fourth Builders' Challenge. Nostra enforces hard, synchronous blocks on trades unless explicitly permitted by a user-defined \"constitution\" of rules, with all violations recorded verbatim on the Solana blockchain. The system uses a three-gate compliance check—crisis protocol, constitutional compliance, and compute budget—to ensure the agent cannot execute unauthorized actions.", "body_md": "What if your AI trading agent couldn't execute a single trade unless you had explicitly told it that it was allowed to?\n\nNot \"the AI will try its best to follow your preferences.\" Not \"there's a risk limit slider somewhere in the settings.\" I mean a hard, synchronous block. As long as the rule doesn't exist in the constitution? No execution. That's it.\n\nI pondered on the initial question for a while. Every DeFi agent content I'd seen seemed to majorly focus on *capability* — what the agent *can* do. Almost none of them addressed *constraint* — what it categorically *cannot* do, and more importantly, how you prove it held the line.\n\nI recently built **Nostra**: a constitutional DeFi agent running on [ElizaOS v2](https://elizaos.ai/) and deployed on [Nosana's decentralized GPU network](https://nosana.com). It just ranked **#6 out of 105 submissions across 32 countries** in Nosana's Fourth Builders' Challenge. The judges called it \"a thoughtful approach to trust, compliance, and agent responsibility\" — which, honestly, felt great to read after two weeks of late-night debugging.\n\nLet's walk through how it works. Including the parts that didn't.\n\n## The Core Idea: Your Agent Has a Constitution\n\nMost AI agents have a skillset that directs them regarding what they do. Nostra has rules.\n\nA Nostra constitution is a structured document you write once during onboarding. It gets parsed into typed `ConstitutionRule`\n\nobjects and stored in SQLite:\n\n```\n// src/types/constitution.ts\nexport interface ConstitutionRule {\n  id: number;          // Rule #N — matches on-chain memo references\n  type: 'allocation_limit' | 'yield_threshold' | 'action_gate' | 'compute_budget' | 'custom';\n  description: \"string; // Plain-English — used verbatim in Lamport memos\"\n  condition: {\n    metric: string;    // e.g. \"sol_concentration\", \"yield_delta\"\n    operator: '<' | '>' | '<=' | '>=' | '==' | '!=';\n    value: number;\n    unit: string;      // e.g. \"percent\", \"apy_points\"\n  };\n  action: 'block' | 'alert' | 'require_approval' | 'reduce_frequency';\n}\n```\n\nThe key insight here: the rule's `description`\n\nfield is the *exact string* that gets written to the Solana blockchain when the rule fires. It is retained in its exact form without translation or paraphrasing. What you wrote is what gets logged. We'll come back to why that matters.\n\n## The Architecture: Three Gates Before Any Trade\n\nHere's the flow every action has to survive before Nostra will touch your money:\n\nAll three gates live in a single higher-order function called `withComplianceGate`\n\n. It wraps any ElizaOS `Action`\n\nlike this:\n\n```\n// src/index.ts — action registration\nactions: [\n  HandleStartCommand,\n  ParseConstitutionAction,\n  LogDecisionOnChain,\n  withComplianceGate(ExecuteRotation),  // ← only execution actions get gated\n  TriggerCrisisProtocol,\n  AmendConstitution,\n  // ...18+ total actions\n],\n```\n\nNotice `ExecuteRotation`\n\nis the only action wrapped. Informational commands, constitution management, and crisis handling are all deliberately *outside* the gate — you always need to be able to talk to your agent, even when it's frozen.\n\nHere's the gate itself (abridged):\n\n```\n// src/gates/with-compliance-gate.ts\nfunction withComplianceGateHandler(handler: ActionHandler): ActionHandler {\n  return async (runtime, message, state, options, callback) => {\n    const agentState = AgentStateService.getState();\n\n    // Gate 1: Crisis Protocol — block if frozen or resolving\n    if (agentState.crisisStatus !== 'active') {\n      await sendCallback(callback,\n        `All actions are frozen. Crisis Protocol status: ${agentState.crisisStatus}.`\n      );\n      return;\n    }\n\n    // Gate 2: Constitutional compliance — live DB read every time\n    const constitution = ConstitutionService.getActive(db);\n    if (constitution && constitution.rules.length > 0) {\n      const proposed = extractProposedAction(message);\n      if (proposed) {\n        const result = checkConstitutionalCompliance(constitution.rules, proposed);\n        if (!result.passed) {\n          // Write a NON_ACTION memo to Solana — even the block is recorded\n          const memoText = buildMemoText({\n            actionDescription: `NON_ACTION: ${result.violation}`,\n            ruleReference: `Rule #${result.ruleRef}`,\n            complianceStatus: 'Constitutional compliance: BLOCKED.',\n          });\n          await WalletService.writeMemo(memoText);\n          await sendCallback(callback, `Action blocked: ${result.violation}`);\n          return;\n        }\n      }\n    }\n\n    // Gate 3: Trust Ladder — block if still in Advisor Mode\n    if (agentState.trustLadder === 'advisor') {\n      await sendCallback(callback,\n        `Advisory Mode. Current accuracy: ${agentState.accuracyScore.toFixed(1)}%`\n      );\n      return;\n    }\n\n    return handler(runtime, message, state, options, callback);\n  };\n}\n```\n\nThere's one detail in Gate 2 I want to highlight: `ConstitutionService.getActive(db)`\n\nis a fresh database read on *every action*. No caching. This was intentional — if you amend your constitution mid-session, the very next proposed action sees the updated rules. Eventual consistency in governance is not a vibe I wanted to ship.\n\n## The Trust Ladder: Earning the Right to Execute\n\nSo here's the thing. Even if your constitution is perfectly configured, Nostra doesn't just start executing trades on day one. It starts in **Advisor Mode**.\n\nIn Advisor Mode, the agent observes, analyzes, and *suggests* what it would do, but every suggestion goes to you for grading. Thumbs up, thumbs down. The `TrustLadderEvaluator`\n\ntracks your scores:\n\n``` js\n// src/evaluators/trust-ladder-evaluator.ts\nconst MIN_SAMPLE_FOR_PROMOTION = 5;\n\n// Threshold: >= 80% accuracy with at least 5 graded entries\nif (accuracyScore >= 80 && total >= MIN_SAMPLE_FOR_PROMOTION) {\n  const state = AgentStateService.getState();\n  if (!state.promotionPending) {\n    update['promotionPending'] = true;  // triggers promotion flow\n  }\n}\n```\n\nOnce the agent hits 80% accuracy across at least 5 graded suggestions, it flags for promotion. You review and explicitly approve the upgrade to **Executor Mode**. Only then can it touch your actual funds.\n\nThis felt like a small detail at design time. In practice, it's the whole point since it forces a natural calibration period and means you've seen the agent's decision-making style before you hand it real authority.\n\n## The Lamport Conscience: On-Chain Proof of Every Decision\n\nThis is my favorite part of the project, and also the part that required the most care.\n\nEvery action — and every *blocked* action — gets written to the [Solana Memo Program](https://spl.solana.com/memo). It was an intentional move not to use a log file or a database entry. Instead, it felt just right to use an immutable, on-chain record you own forever. I called it the **Lamport Conscience** (because Lamports are the smallest unit of SOL, and conscience is… the smallest unit of accountability, maybe?).\n\n```\n// src/actions/log-decision-on-chain.ts\nexport function buildMemoText(params: MemoParams): string {\n  const timestamp = new Date().toISOString();\n  const { ruleReference, complianceStatus } = params;\n\n  const fixedPart = `${timestamp} — `;\n  const suffix = ` ${ruleReference}. ${complianceStatus}`;\n  const maxDescriptionLength = MEMO_MAX_CHARS - fixedPart.length - suffix.length;\n\n  let desc = params.actionDescription;\n  if (desc.length > maxDescriptionLength) {\n    desc = desc.slice(0, maxDescriptionLength - 1) + '…';\n  }\n\n  return `${fixedPart}${desc}${suffix}`;\n}\n```\n\nA real memo looks like this:\n\n```\n2026-04-12T14:32:11.204Z — Rotate 15% SOL → USDC via Jupiter. Rule #2. Constitutional compliance: 100%.\n```\n\nAnd a blocked one:\n\n```\n2026-04-12T14:35:02.871Z — NON_ACTION: sol_concentration 72% exceeds max 60%. Rule #3. Constitutional compliance: BLOCKED.\n```\n\nBoth get broadcast to the chain. The agent proves what it did *and* what it refused to do. That's the audit trail that makes \"your rules\" actually mean something.\n\n## The Crisis Protocol: When Things Go Sideways\n\nHere's where it gets fun. What happens when the agent detects a catastrophic market condition, such as a cascade liquidation, a de-peg, or a flash crash?\n\nIt freezes itself. Completely. No new actions can pass Gate 1. Then it does three things:\n\n- Writes an emergency memo to Solana documenting the crisis\n- Generates a crisis briefing using the LLM (Qwen3.5-27B on Nosana's GPU)\n- Sends you three resolution options on Telegram with explicit tradeoffs — A (lowest risk), B (medium), C (highest risk)\n\nYou vote. The agent executes your choice. This was genuinely tricky to implement because the LLM response has to be structured JSON, and LLMs are famously bad at being told \"output ONLY valid JSON, no other text.\" The prompt engineering to make that reliable took more iterations than I'd like to admit.\n\n## Deploying on Nosana: The amd64 Trap\n\nRight. Here's the honest moment.\n\nI spent almost half a day confused about why my Docker image was failing on Nosana nodes. Everything worked locally. The image built fine. The job would post, and then... nothing. Silent failure.\n\nNosana runs on x86_64 nodes. My dev machine is Apple Silicon. When you run `docker build`\n\non an M-series Mac without specifying the platform, you get an `arm64`\n\nimage. Nosana can't run it.\n\nThe fix is one flag, but you have to know to look for it:\n\n```\n# This is the command that actually works on Nosana\ndocker buildx build --platform linux/amd64 -t yourusername/nostra:latest --push .\n```\n\nAnd secrets — never bake them into the image. Nosana has a secrets manager for this:\n\n```\nnosana secret create TELEGRAM_BOT_TOKEN <your-token>\nnosana secret create SOLANA_PRIVATE_KEY <base58-keypair>\nnosana secret create ALCHEMY_RPC_URL <your-rpc-url>\n```\n\nThen your job definition references them at runtime. This is the right pattern. Don't skip it.\n\n## The Full Stack at a Glance\n\n## What I Learned (And Would Do Differently)\n\n**What worked well:**\n\n- ElizaOS v2's Provider/Action/Evaluator pattern is genuinely well-designed for this kind of layered architecture. The separation of concerns maps cleanly to \"observe → decide → act.\"\n- Socratic onboarding — where the agent asks you 6 probing questions about your risk tolerance and investment philosophy before generating your constitution — turned out to be the highest-value UX decision. Users who go through it understand their own rules better.\n- The Lamport Conscience felt \"extra\" when I was designing it. But when you go into the details, it's consistently one of the things people find most interesting.\n\n**What I'd do differently in V2:**\n\n- SQLite is fine for a single Nosana node. The moment you want multi-node deployment (and you will), you need PostgreSQL. The Crisis Protocol freeze needs row-level locking across nodes, which SQLite can't give you.\n- In-memory keypair signing works for a challenge submission. For production, hardware wallet signing (Ledger via\n`@solana/hw-wallet-adapter`\n\n) is the only honest answer for a non-custodial agent. - I'd write more integration tests earlier. The action tests I have are good, but the gates-under-load path wasn't tested until it was already in the Nosana job.\n\n## Go Build Something\n\nThe full project is open-source: [github.com/Zolldyk/Nostra](https://github.com/Zolldyk/Nostra) (branch: `elizaos-challenge`\n\n)\n\nIf you're building anything in the AI agent x DeFi space, especially if you're thinking about governance, accountability, or trust models for autonomous agents, I'd genuinely love to compare notes. Drop a comment, open an issue, or just fork it and see where you can take it.\n\nThe question I started with — *what if an agent couldn't break its own rules?* — has a lot more surface area than I initially thought. There are entire research fields pointing at this problem (corrigibility, value alignment, Constitutional AI). I didn't solve any of them. But I did build something that makes them concrete and tangible in a DeFi context, and I think that's worth exploring further.", "url": "https://wpnews.pro/news/architecting-a-self-governing-de-fi-agent-here-s-how-it-ranked", "canonical_source": "https://dev.to/ola-zoll/architecting-a-self-governing-de-fi-agent-heres-how-it-ranked-ljo", "published_at": "2026-05-21 07:47:20+00:00", "updated_at": "2026-05-21 08:01:07.618423+00:00", "lang": "en", "topics": ["artificial-intelligence", "web3", "open-source", "developer-tools", "startups"], "entities": ["Nostra", "ElizaOS", "Nosana", "DeFi"], "alternates": {"html": "https://wpnews.pro/news/architecting-a-self-governing-de-fi-agent-here-s-how-it-ranked", "markdown": "https://wpnews.pro/news/architecting-a-self-governing-de-fi-agent-here-s-how-it-ranked.md", "text": "https://wpnews.pro/news/architecting-a-self-governing-de-fi-agent-here-s-how-it-ranked.txt", "jsonld": "https://wpnews.pro/news/architecting-a-self-governing-de-fi-agent-here-s-how-it-ranked.jsonld"}}