Most AI trading agents focus on capability: what they can do. Few address constraint: what they categorically cannot do, and how you prove they held the line. When transactions are irreversible and capital is at risk, permission boundaries become critical infrastructure.
Nostra, a constitutional DeFi agent built on ElizaOS v2 and deployed on Nosana’s decentralized GPU network, ranked #6 out of 105 submissions in Nosana’s Fourth Builders’ Challenge. The architecture centers on one principle: the agent cannot execute a trade unless an explicit rule permits it. Not a risk slider. Not a best-effort prompt. A hard, synchronous block.
The Constitution Layer
Nostra uses a structured constitution document that gets parsed into typed ConstitutionRule objects and stored in SQLite. Each rule defines a constraint with an enforcement action.
// 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 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';
}Rules are evaluated synchronously before any transaction execution. If a rule blocks an action, the transaction never reaches the blockchain. If it requires approval, the agent queues the intent and waits for explicit human authorization.
Permission Architecture
The permission layer sits between the agent’s decision engine and the transaction executor. It operates in three stages:
1. Intent Classification
Every agent action is classified as read-only (market analysis, price checks) or write (swaps, liquidity provision, staking). Read operations bypass the permission layer. Write operations trigger rule evaluation.
2. Rule Evaluation
The agent loads all applicable rules from SQLite and evaluates them against current state:
- Portfolio concentration limits (e.g., “SOL cannot exceed 40% of total holdings”)
- Yield thresholds (e.g., “Block any pool with APY delta > 5 points in 24h”)
- Action gates (e.g., “Require approval for any transaction > 10 SOL”)
- Compute budgets (e.g., “Max 3 transactions per hour”)
Each rule returns block, alert, or pass. A single block aborts the transaction. An alert logs the event but allows execution. require_approval moves the transaction to a pending queue.
3. State Verification
Before submitting to the blockchain, the agent re-verifies that the transaction still satisfies all rules. This catches race conditions where portfolio state changed between intent and execution.
Approval Surface
The approval surface is the set of operations that require explicit human intervention. Nostra minimizes this surface while maintaining safety:
| Operation Type | Default Behavior | Rationale |
|---|---|---|
| Price queries | Auto-approve | Read-only, no risk |
| Small swaps (<1 SOL) | Auto-approve if within allocation limits | Low financial impact |
| Large swaps (>10 SOL) | Require approval | High capital risk |
| New pool deposits | Require approval | Unknown risk profile |
| Known pool rebalancing | Auto-approve if yield delta <5% | Established risk parameters |
| Emergency withdrawals | Always allow | Safety override |
When an operation requires approval, the agent:
- Serializes the transaction intent to JSON
- Writes it to a
pending_approvalstable with a unique ID - Sends a notification (webhook, email, or UI alert)
- Polls for approval status every 30 seconds
- Executes if approved within 10 minutes, otherwise expires
Failure Modes
Rule Conflict
If two rules contradict (e.g., one requires approval, another blocks), the most restrictive action wins. Block > require_approval > alert > pass.
Approval Timeout
If approval isn’t granted within the timeout window, the transaction expires. The agent logs the event and moves on. No retry logic to avoid approval fatigue.
State Drift
Portfolio state can change between approval and execution. The agent re-evaluates all rules immediately before signing the transaction. If any rule now blocks, the transaction aborts even with prior approval.
Constitution Update
Updating the constitution requires stopping the agent, modifying the SQLite rules, and restarting. There’s no hot-reload because rule changes affect in-flight transactions. This is intentional: governance changes should be deliberate.
Observability
Every rule evaluation writes to an audit_log table:
- Timestamp
- Rule ID
- Evaluated metric and value
- Operator and threshold
- Result (block/alert/pass)
- Transaction ID (if applicable)
This creates an immutable record of every decision. You can reconstruct why the agent executed or blocked any transaction.
On-chain, Nostra writes rule IDs to transaction memos using Lamport timestamps. This links blockchain activity to specific constitution rules, making audits possible without trusting off-chain logs.
Deployment Shape
Nostra runs on Nosana’s decentralized GPU network, which provides:
- Isolated compute environments per agent instance
- GPU access for LLM inference (ElizaOS decision engine)
- Persistent storage for SQLite constitution and audit logs
- Network-level rate limiting
The agent itself is stateless except for the constitution and audit log. Portfolio state is queried on-demand from Solana RPC nodes. This makes recovery simple: restart the agent, it loads the constitution, and resumes operation.
When to Use This Pattern
Good fit:
- Any agent handling irreversible operations (blockchain, payments, infrastructure changes)
- Scenarios where mistakes have financial or operational consequences
- Environments requiring audit trails for compliance
- Multi-agent systems where you need provable constraint enforcement
Poor fit:
- Low-stakes automation where rollback is cheap
- Scenarios requiring sub-second latency (synchronous rule evaluation adds 50-200ms)
- Exploratory agents that need to learn from mistakes
- Systems where human approval becomes a bottleneck
Technical Verdict
The constitutional agent pattern trades autonomy for safety. It’s appropriate when the cost of a mistake exceeds the cost of occasional human intervention. For DeFi specifically, where transactions are final and capital is at risk, explicit permission boundaries are infrastructure, not nice-to-have features.
The synchronous rule evaluation adds latency but prevents the class of errors where an agent “thought it was following the rules” but executed something unauthorized. The approval queue adds friction but creates a clear decision point for high-risk operations.
If you’re building agents that handle money, credentials, or infrastructure, start with constraints. Define what the agent cannot do before you define what it can do. The permission layer is your last line of defense when the LLM hallucinates or the market moves faster than your risk model.