Architecting a Self Governing De-Fi Agent - Here's How It Ranked 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. What if your AI trading agent couldn't execute a single trade unless you had explicitly told it that it was allowed to? Not "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. I 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. I 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. Let's walk through how it works. Including the parts that didn't. The Core Idea: Your Agent Has a Constitution Most AI agents have a skillset that directs them regarding what they do. Nostra has rules. A Nostra constitution is a structured document you write once during onboarding. It gets parsed into typed ConstitutionRule objects and stored in SQLite: // src/types/constitution.ts export interface ConstitutionRule { id: number; // Rule N — matches on-chain memo references type: 'allocation limit' | 'yield threshold' | 'action gate' | 'compute budget' | 'custom'; description: "string; // Plain-English — used verbatim in Lamport memos" condition: { metric: string; // e.g. "sol concentration", "yield delta" operator: '<' | ' ' | '<=' | ' =' | '==' | ' ='; value: number; unit: string; // e.g. "percent", "apy points" }; action: 'block' | 'alert' | 'require approval' | 'reduce frequency'; } The key insight here: the rule's description field 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. The Architecture: Three Gates Before Any Trade Here's the flow every action has to survive before Nostra will touch your money: All three gates live in a single higher-order function called withComplianceGate . It wraps any ElizaOS Action like this: // src/index.ts — action registration actions: HandleStartCommand, ParseConstitutionAction, LogDecisionOnChain, withComplianceGate ExecuteRotation , // ← only execution actions get gated TriggerCrisisProtocol, AmendConstitution, // ...18+ total actions , Notice ExecuteRotation is 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. Here's the gate itself abridged : // src/gates/with-compliance-gate.ts function withComplianceGateHandler handler: ActionHandler : ActionHandler { return async runtime, message, state, options, callback = { const agentState = AgentStateService.getState ; // Gate 1: Crisis Protocol — block if frozen or resolving if agentState.crisisStatus == 'active' { await sendCallback callback, All actions are frozen. Crisis Protocol status: ${agentState.crisisStatus}. ; return; } // Gate 2: Constitutional compliance — live DB read every time const constitution = ConstitutionService.getActive db ; if constitution && constitution.rules.length 0 { const proposed = extractProposedAction message ; if proposed { const result = checkConstitutionalCompliance constitution.rules, proposed ; if result.passed { // Write a NON ACTION memo to Solana — even the block is recorded const memoText = buildMemoText { actionDescription: NON ACTION: ${result.violation} , ruleReference: Rule ${result.ruleRef} , complianceStatus: 'Constitutional compliance: BLOCKED.', } ; await WalletService.writeMemo memoText ; await sendCallback callback, Action blocked: ${result.violation} ; return; } } } // Gate 3: Trust Ladder — block if still in Advisor Mode if agentState.trustLadder === 'advisor' { await sendCallback callback, Advisory Mode. Current accuracy: ${agentState.accuracyScore.toFixed 1 }% ; return; } return handler runtime, message, state, options, callback ; }; } There's one detail in Gate 2 I want to highlight: ConstitutionService.getActive db is 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. The Trust Ladder: Earning the Right to Execute So 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 . In 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 tracks your scores: js // src/evaluators/trust-ladder-evaluator.ts const MIN SAMPLE FOR PROMOTION = 5; // Threshold: = 80% accuracy with at least 5 graded entries if accuracyScore = 80 && total = MIN SAMPLE FOR PROMOTION { const state = AgentStateService.getState ; if state.promotionPending { update 'promotionPending' = true; // triggers promotion flow } } Once 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. This 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. The Lamport Conscience: On-Chain Proof of Every Decision This is my favorite part of the project, and also the part that required the most care. Every 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? . // src/actions/log-decision-on-chain.ts export function buildMemoText params: MemoParams : string { const timestamp = new Date .toISOString ; const { ruleReference, complianceStatus } = params; const fixedPart = ${timestamp} — ; const suffix = ${ruleReference}. ${complianceStatus} ; const maxDescriptionLength = MEMO MAX CHARS - fixedPart.length - suffix.length; let desc = params.actionDescription; if desc.length maxDescriptionLength { desc = desc.slice 0, maxDescriptionLength - 1 + '…'; } return ${fixedPart}${desc}${suffix} ; } A real memo looks like this: 2026-04-12T14:32:11.204Z — Rotate 15% SOL → USDC via Jupiter. Rule 2. Constitutional compliance: 100%. And a blocked one: 2026-04-12T14:35:02.871Z — NON ACTION: sol concentration 72% exceeds max 60%. Rule 3. Constitutional compliance: BLOCKED. Both 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. The Crisis Protocol: When Things Go Sideways Here'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? It freezes itself. Completely. No new actions can pass Gate 1. Then it does three things: - Writes an emergency memo to Solana documenting the crisis - Generates a crisis briefing using the LLM Qwen3.5-27B on Nosana's GPU - Sends you three resolution options on Telegram with explicit tradeoffs — A lowest risk , B medium , C highest risk You 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. Deploying on Nosana: The amd64 Trap Right. Here's the honest moment. I 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. Nosana runs on x86 64 nodes. My dev machine is Apple Silicon. When you run docker build on an M-series Mac without specifying the platform, you get an arm64 image. Nosana can't run it. The fix is one flag, but you have to know to look for it: This is the command that actually works on Nosana docker buildx build --platform linux/amd64 -t yourusername/nostra:latest --push . And secrets — never bake them into the image. Nosana has a secrets manager for this: nosana secret create TELEGRAM BOT TOKEN