DEV Community: Ubong Ntekim

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

Ubong Ntekim — Mon, 12 Oct 2026 12:27:16 +0000

Sentinel — AI Policy Assistant, built for the Monad Metropolis hackathon (Alibaba Cloud / Qwen 3.8 Max bounty)

The problem: nobody knows how to configure a guardrail

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 integration

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.

What Qwen does for us

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

Graceful degradation

Production engineering matters in a hackathon demo. The assistant has a two-layer fallback:

If the DashScope call fails (network, key, rate limit), a local regex parser extracts MON amounts, time-locks, and whitelist names from the same sentence.
If 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.

Why Qwen specifically

Structured-output discipline. qwen-max follows the JSON-schema instruction reliably at temperature: 0.3 — we get parseable policy objects, not prose.
The compatible-mode endpoint means no bespoke SDK: one fetch, standard OpenAI-style payloads, trivially portable.
Value per token is the right shape for this task. Policy parsing is short-context, high-precision work — exactly what a flagship model should be spent on.

Try it

Open https://sentinel-monad.vercel.app
Go to the Create Policy page and open the AI Policy Assistant
Type: "Strict mode: 0.5 MON per tx, whitelist only Uniswap, auto-pause at 2 MON"
Watch the form fill itself in — then submit to create a real on-chain policy on Monad Testnet

Repo: https://github.com/ubongn/sentinel
Bounty: Alibaba Cloud — Best Builds with Qwen 3.8 Max

Gasless on Soroban — How We Made Joining an On-Chain Savings Circle Cost Nothing

Ubong Ntekim — Thu, 10 Sep 2026 11:17:22 +0000

A technical walkthrough of fee-bump sponsorship for Soroban dApps — shipped in production on Nova Esusu, a rotating savings circles app on Stellar.

If you're building a Soroban dApp for people who have never held crypto, you will hit the same wall I did: the first transaction is the hardest one. A new user has to acquire XLM, create an account, pay a base reserve, and fund a transaction fee — all before they experience a single feature of your product.

For my first 51 testnet testers this was friction-free (thanks, friendbot). But mainnet has no faucet. So before launching Nova Esusu — on-chain rotating savings circles (the West African Esusu tradition) — on mainnet, I needed an answer to one question:

Can a new user join a savings circle without ever owning a fee?

The answer is yes, and it's built into Stellar itself: fee-bump transactions.

The pattern: user signs, sponsor pays

Stellar's transaction model separates two things that most chains conflate:

source — the account whose sequence number the transaction consumes, and whose signature authorizes the operations
fee source — the account that pays the network fee

A fee-bump envelope (ENVELOPE_TYPE_TX_FEE_BUMP) wraps a fully-signed inner transaction with a second payer:

const feeBump = TransactionBuilder.buildFeeBumpTransaction(
  sponsorKeypair.publicKey(),        // feeSource — pays everything
  (innerFee * 2).toString(),         // declared fee, capped
  innerTransaction,                  // signed by the user only
  networkPassphrase
);
feeBump.sign(sponsorKeypair);

The magic: the user's signature only ever authorizes the inner operations. The sponsor's signature only authorizes paying. Neither can spend the other's funds. This is the safest possible trust boundary — the sponsor is not a custodian, not a co-signer, and cannot move the user's money.

The architecture

Browser                      Serverless API                 Stellar
   |                              |                           |
   | 1. sign inner tx (user)      |                           |
   |------------------------------->                           |
   | 2. POST { xdr, network }     |                           |
   |----------------------------->|                           |
   |                              | 3. validate rails         |
   |                              | 4. wrap + sign fee-bump   |
   |                              | 5. submit ----------------->|
   |                              |                           |
   | <------ 6. { hash } ---------|---------- chain ---------- |

Three pieces, ~150 lines total:

1. The shared builder (shared/feebump.ts) — wraps any user-signed XDR in a fee-bump envelope. This module typechecks under both the Vite toolchain and the serverless toolchain, which matters more than it sounds (ask me how I know).

2. The sponsor endpoint (api/sponsor.ts, Vercel serverless) — receives the signed inner transaction, validates it, wraps, signs, submits. When the sponsor key is absent it returns 503, and the frontend silently falls back to normal submission — the user never sees an error, the feature just gracefully disappears.

3. The frontend opt-in — a "Gasless" checkbox on the join/create flows. Opt-in, never default-hidden, so reviewers can see exactly what's happening.

The abuse rails (read this before you ship one)

An open "someone else pays my fees" endpoint is a generous gift to the internet. Mine has four rails, all enforced server-side:

Fee cap — the inner transaction's declared fee is capped (5 XLM). A malicious client can't submit MAX_INT and drain the sponsor.
Sponsor ≠ source — the endpoint refuses to sponsor a transaction whose inner source is the sponsor itself (prevents using the endpoint as a weird signing oracle).
Already-bumped envelopes rejected — only raw inner transactions are accepted, one wrap only.
Network pinned per environment — testnet and mainnet sponsor keys are separate env vars; a mainnet request can never be signed by the testnet wallet.

The cap matters most. Soroban fees are based on declared resource limits — an adversarial client could declare enormous instructions. Cap early, cap server-side.

Proof it works: a fresh user, zero fees, on-chain

I verified the full path in production: created a brand-new keypair, funded it with the minimum, had it sign a create_circle call, POSTed to the live endpoint, and confirmed on-chain:

Transaction: 912b64619d39e2f6800894685a37adee77711bb5f58af1957da388df1b24b94a
Envelope type: ENVELOPE_TYPE_TX_FEE_BUMP
Fee source: the sponsor wallet
The user account's balance: unchanged except for the operation itself

Things that cost me an afternoon (so they don't cost you one)

The SDK wants class instances. server.sendTransaction() accepts Transaction | FeeBumpTransaction, not a raw XDR object — a base64 string serialized as an object gets rejected by the RPC with a wonderfully unhelpful invalid parameters.
Vercel functions are Express-style. A web-standard Request/Response handler doesn't hang on import — it hangs on invocation: the runtime waits for res.end() forever and you get FUNCTION_INVOCATION_TIMEOUT. Write (req, res) handlers.
Soroban rejects classic operations. bumpSequence, manageData et al. fail simulation (unsupported operation type). Your inner transaction must be contract calls.
Fee-bump signing order is irrelevant but presence isn't. The inner signature must exist before wrapping — you're signing the hash of the inner tx, and the sponsor signs the hash of the wrapped envelope.

Why this matters for adoption

Every chain ecosystem says it wants "the next billion users." Most wallets in the markets that actually need savings circles (West Africa, Southeast Asia, Latin America) start empty. Fee sponsorship turns a four-step onboarding (get an exchange account → buy XLM → withdraw → fund transactions) into a one-step one (connect wallet, join).

The Esusu circle my testers joined cost them exactly zero in fees on testnet, and on mainnet the sponsor pool will carry the fees for the first wave of members. The people who need savings infrastructure the most are the ones least able to pay friction costs to try it. Fee sponsorship is how a protocol says "the first round is on me."

Nova Esusu is open source: github.com/ubongn/stellar-nova-esusu. Contracts: SavingsPool (escrow + payouts) and MemberManager (reputation + eligibility), with the payout order locked on-chain at circle activation. Questions or feedback — find me on X @ubongn.