Blockchain and AI: where they fit and what to build first

TL;DR: Blockchain and AI help each other in one narrow way. The chain gives an AI agent a record nobody can quietly edit, and spend rules the model can't override. It won't make the AI right, and most AI products don't need one. If your agent will touch money, keep the model away from the keys, check each action with fixed code outside the model, and start read-only before you give it a budget.

Blockchain and AI help each other in one narrow way. Blockchain gives an AI system a record nobody can quietly edit, and rules it can't talk its way around. AI gives a blockchain app something that can read the data and suggest the next move.

That's the whole deal. A chain won't make your AI smarter. It won't make it right. And most AI products don't need one.

So here's where the two fit, where they don't, and what to build first if your AI agent is going to touch money.

The short answer

Think of it as two jobs.

The AI does the thinking. It reads, sorts, drafts and suggests. It's fast, and it's wrong now and then.

The blockchain keeps the record and keeps the rules. A smart contract runs the same way each time. Once a transaction lands, it stays there for anyone to check.

Put them together and you get an AI that can act, with a hard limit on what it can do and a trail of what it did.

New to agents? Start with our plain guide to what an AI agent is. AI-Led's plain-English guide to AI agents breaks one down into four parts: the model, the tools, the memory and the loop.

Where blockchain and AI help each other

A chain earns its place when more than one party needs to trust the record, and no one party should own it. Here's how that plays out.

AI helps the chain side too. A survey of agents on blockchains went through 317 papers and sorted the work into five patterns. They run from read-only analytics and drafting intents, through delegated execution, up to agents that sign on their own and multi-agent workflows.

The first two are the safe end. The agent reads on-chain data, or drafts a transaction for a person to sign. No keys. No spend.

We've covered blockchain uses outside crypto before, so I won't repeat that list here.

Where they don't help

Here's the thing. A ledger records what happened. It can't tell you if it should have happened.

The team behind the Authority-Inference Separation paper tested that on a public chain. They checked 1,700 recent transactions on Base. The ledger showed the payment and some of the sign-off details. It couldn't show who held the mandate, who was legally on the hook, or if the service ever got delivered.

Their point is simple. A chain can enforce and record authority that someone granted. It can't make that authority legitimate. People and process do that, off-chain.

Four more limits to plan for.

• Cost. Each on-chain write costs gas. The PACE team measured 29,826 to 31,822 gas to check one signed approval on-chain. That's fine for a payment. It's silly for every chat message. So keep the thinking off-chain and only write what needs a permanent record.
• Privacy. A public chain is public. Keep customer data off it. One black box design for agents puts only a fingerprint of each record on-chain and keeps the sensitive content off it. Its author is clear that this doesn't stop an agent from misbehaving. It gives you better evidence later.
• Bad inputs. Feed an agent a poisoned web page and the chain will record the bad call faithfully. Our post on prompt injection defence covers how those attacks work.
• New ways to get hurt. The same survey lists the risks that come with agents on a chain. Prompt injection is one. Stolen keys are another. So are agents that team up against you.

Split the thinking from the authority

This is the practical core. If your agent can sign transactions, don't let the model hold the pen.

The Authority-Inference Separation design works like this. The model proposes an action. A separate control plane checks it. That control plane is fixed code, not a model. Is this agent registered? Who owns it? Is the action inside its mandate? Do the amounts match? Only then does the action get a short-lived pass to run.

The authors ran 36 made-up attacks against three setups.

All three let the 8 valid requests through.

Now here's the important bit. The authors say these results show tested mechanisms, not how it holds up in production. The prototype had no live model and no production keys. The prompt setup was one research build, not a verdict on every prompt control. So treat it as a design pattern, not a promise.

Still, the lesson travels. A rule in a prompt is a request. A check outside the model is a rule.

And plan for failure. For agents that sign on their own, the survey says to assume any one part can break, the agent included. So stack checks that don't share a weak point.

It's the same thinking as our LLM guardrails architecture. AI Orchestrators makes the same call: guard the tool call itself, because that's where a bad decision turns into a real payment.

Three terms worth knowing

Policy Decision Record (PDR)

A PDR is a signed receipt for a decision. It says this exact transaction was checked against this policy, and it passed.

In the PACE paper, the PDR ties the approved intent, the policy and a simulation report to the exact bytes that get executed. It expires, and it can't be replayed.

In PACE's sandbox, the unsafe execution rate was 0.00. The agent with no guard scored 0.80. The authors are careful about it. They claim safety inside a benchmark, not proof that it's ready for live DeFi.

One more thing. A PDR doesn't have to live on-chain. The survey makes the point that even an off-chain PDR gives you a trail of why a transaction got approved. That helps a lot when you're piecing things together after an incident.

Signing guardrails

A signing guardrail is a spend rule that lives where the key lives, not in the prompt. The signer checks the rule before it signs a thing.

BNB Chain's draft Agent Lifecycle Protocol lists four of them: a balance threshold, a refill amount, a daily spend cap and an allowlist of who can be paid. Trick the model into paying a stranger, and the signer still says no.

One caveat. It's a v0.4 draft from a chain vendor with skin in the game. It may change.

Zero-knowledge vs optimistic proofs

Both answer one question. How do you trust work that was done off-chain?

A zero-knowledge proof proves a statement is true without showing the statement. That's how Ethereum's docs define it. The data stays hidden. But building the proof takes heavy compute, often on specialist machines.

An optimistic setup assumes the work is right, then gives anyone a window to challenge it. On Ethereum's optimistic rollups, a withdrawal waits out a challenge period of about seven days. You skip the heavy proof. You pay in time.

The same trade shows up with AI. A survey of decentralised AI says zero-knowledge proofs for model outputs get slower as the model grows. Optimistic checks run faster, but they lean on trust assumptions.

So pick by need. If secrecy matters most, look at zero-knowledge. If you can live with a dispute window, optimistic is lighter.

What about lots of agents?

Same idea, more moving parts. The DART paper scores each agent's reputation and logs who did what through smart contracts. The authors planted three bad agents in a test run. DART blocked 99.3% of their corrupted outputs.

That's one lab result. Get one agent right before you run five.

What Australian law says, and what it doesn't

Australia passed the Corporations Amendment (Digital Assets Framework) Act 2026. It became law in April 2026. Check the Act's commencement table for when each part starts.

Here's what the text does.

• It amends the Corporations Act 2001.
• It defines a digital token, a digital asset platform and a tokenised custody platform.
• It lets ASIC make asset-holding standards. Those can cover safeguarding, recordkeeping, reconciliation and reporting.
• It lets ASIC make transactional and settlement standards.
• It has transitional rules for the changeover.

And here's what it doesn't do. It doesn't mention AI. It's a law about platforms that hold digital tokens, or the assets behind them, for clients.

So don't read it as an AI rulebook. If your product holds tokens or tokenised assets for other people, with or without an agent, ask a lawyer where you stand. This post isn't legal advice.

What to build first

The tempting move is to hand the agent a wallet on day one. Don't. Go in steps.

1. Ask if you need a chain at all. One company, one record? Use an append-only log in your database.
2. Start read-only. Let the agent read on-chain data and report. No keys.
3. Then let it draft. The agent writes the transaction. A person checks it and signs. Our guide to human in the loop covers when that review is worth the wait.
4. Put the rules outside the model. Run the policy check as fixed code. Save each decision as a signed record.
5. Put spend limits at the signer. A daily cap and an allowlist, set by a person.
6. Test with fake money. Run attack cases in a sandbox before anything touches real value.
7. Give it a small budget. Watch it. Widen the limits slowly.

Digiocial's four-stage model for agent rollout makes the same case. Prove each stage before you grant the next one.

If smart contracts are part of the build, read our post on smart contract security. It covers threat models, fuzzing and audits.

Where Devwiz fits

AI is our main work. We build AI platforms as production software. We've shipped Web3 work too. Start with NFTs is an NFT education platform with live tools that read on-chain data straight in the browser. It's a content and tools build, not an agent that signs transactions.

So to be straight with you, this post leans on published research and primary docs, not a Devwiz case file. The patterns are young. Most of the numbers above come from sandboxes.

If you're scoping a chain build, our blockchain development in Sydney page covers that side.

Which chain to use is the wrong first question. Ask what your agent is allowed to do, and who checks it. Get that right in plain code, then decide if a chain adds anything.

*James*

Devwiz has shipped 200+ apps, including work for NSW Government (Justice and Corrective Services), Briometrix, Vivid and Huskee.

Building an AI agent that will move money, and not sure where the guardrails go? Start with AI app development. Worth a chat.

Frequently asked questions

How are blockchain and AI used together?

The AI reads data and suggests actions. The blockchain enforces the rules and keeps a record that can't be quietly edited. The pattern in the research is simple: an agent proposes a transaction, a separate check approves it, and the chain records what happened.

Does my AI product need a blockchain?

Mostly no. If one company owns the record, an append-only log in your database does the job. A chain earns its place when more than one party needs to trust the record, or when the money your agent moves already lives on-chain.

What is a Policy Decision Record (PDR)?

It's a signed receipt for a decision. In the PACE research, it ties the approved intent, the policy and a simulation report to the exact transaction bytes. It also expires and can't be replayed, so an old approval can't be reused.

What is the difference between zero-knowledge and optimistic proofs?

A zero-knowledge proof shows a statement is true without showing the statement, but it takes heavy compute to build. An optimistic setup assumes the work is right and gives anyone a window to challenge it. One costs compute. The other costs time.

Does Australia's digital assets law cover AI agents?

The Corporations Amendment (Digital Assets Framework) Act 2026 doesn't mention AI. It deals with digital asset platforms and tokenised custody platforms. If your product holds tokens or tokenised assets for clients, ask a lawyer where you stand. This isn't legal advice.