How Qwen 3.8 Max Turns Plain English Into On-Chain Guardrails

A developer built Sentinel, an AI policy assistant for the Monad Metropolis hackathon that uses Alibaba's Qwen 3.8 Max (qwen-max via the DashScope OpenAI-compatible API) to translate plain-English intent into on-chain guardrail parameters such as spending limits, recipient whitelists, time-locks, and circuit breaks. The assistant returns strict JSON matching a fixed PolicyParams schema at temperature 0.3, prefills the policy-creation form, and submits a real transaction to the SentinelRegistry/SentinelGuard contracts on Monad Testnet, with a local parser fallback when no API key is set.

Sentinel — AI Policy Assistant, built for the Monad Metropolis hackathon Alibaba Cloud / Qwen 3.8 Max bounty Sentinel puts hard limits on AI agents before they can move money on-chain: spending limits, recipient whitelists, time-locks, and circuit breaks. The contracts enforce them. But there was a UX gap — the people who most need guardrails solo developers running trading agents know what they want "don't let my agent lose more than X" , but not how to translate that intent into smart-contract parameters. What does "1 MON per transaction" become? What's a sane daily limit? How long should a time-lock be? Before Qwen, users had to hand-fill six numeric fields and hope. Qwen 3.8 Max closes that gap. We integrated it as the AI Policy Assistant : you type your intent in plain language, Qwen parses it into exact on-chain policy parameters, and the policy is created — a real transaction on Monad Testnet. The assistant lives in frontend/src/components/AiAssistant.tsx and calls the DashScope API OpenAI-compatible mode with the qwen-max model: POST https://dashscope.aliyuncs.com/compatible-mode/v1/chat/completions model: "qwen-max" temperature: 0.3 The system prompt tells Qwen it is a policy-configuration assistant for an on-chain guardrail system, and constrains it to respond only with valid JSON matching a fixed schema: { "maxSpendPerTx": "<number in MON ", "maxSpendPerPeriod": "<number in MON ", "periodDuration": "<seconds ", "timeLockDuration": "<seconds ", "timeLockThreshold": "<number in MON ", "circuitBreakThreshold": "<number in MON ", "whitelist": "<contract names or addresses " , "explanation": "<brief explanation of what was configured " } The response is parsed, mapped to a PolicyParams object, and pushed straight into the policy-creation form. The user reviews the prefilled numbers and submits — the result is a real on-chain policy in the SentinelRegistry/SentinelGuard contracts. Natural language → policy parameters. "Limit my agent to 1 MON per transaction, whitelist only Uniswap, circuit-break if it loses 50 MON in an hour" comes back as exact numbers: maxSpendPerTx: 1 , whitelist: ... , circuitBreakThreshold: 50 , plus a human-readable explanation. Smart defaults from intent. "I want my agent to trade safely on DeFi" yields a conservative configuration rather than forcing the user to invent numbers. Plain-English explanations. Every generated policy ships with an explanation field so users understand what each parameter does — without reading Solidity. Monad-aware context. The system prompt anchors defaults in MON amounts and typical DeFi transaction sizes on Monad's fast blocks 1 MON/tx, 10 MON/day, 1-hour time-lock above 5 MON, circuit break at 50 MON . Production engineering matters in a hackathon demo. The assistant has a two-layer fallback: VITE QWEN API KEY isn't set at all, the local parser runs directly. The UI never breaks, and the user always gets a working policy — Qwen makes it intelligent , the fallback makes it reliable . qwen-max follows the JSON-schema instruction reliably at temperature: 0.3 — we get parseable policy objects, not prose. fetch , standard OpenAI-style payloads, trivially portable. Repo: https://github.com/ubongn/sentinel https://github.com/ubongn/sentinel Bounty: Alibaba Cloud — Best Builds with Qwen 3.8 Max