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 and deployed on Nosana's decentralized GPU network. 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:

// 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. 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:

1. Writes an emergency memo to Solana documenting the crisis
2. Generates a crisis briefing using the LLM (Qwen3.5-27B on Nosana's GPU)
3. 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 <your-token>
nosana secret create SOLANA_PRIVATE_KEY <base58-keypair>
nosana secret create ALCHEMY_RPC_URL <your-rpc-url>

Then your job definition references them at runtime. This is the right pattern. Don't skip it.

The Full Stack at a Glance

What I Learned (And Would Do Differently)

What worked well:

• 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."
• 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.
• 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.

What I'd do differently in V2:

• 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.
• In-memory keypair signing works for a challenge submission. For production, hardware wallet signing (Ledger via @solana/hw-wallet-adapter) 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.

Go Build Something

The full project is open-source: github.com/Zolldyk/Nostra (branch: elizaos-challenge)

If 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.

The 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.