Welcome to the NZRT Wiki Podcast. Today we’re looking at Agentic AI in DeFi.

So let’s start with the big question: what actually makes an AI agent in DeFi different from the trading bots you might already know about? The key distinction is reasoning. A traditional DeFi bot follows fixed rules — if price hits X, do Y. An agentic AI reasons about whether to act at all. It reads the current state of the market, thinks through the situation, and decides. That adaptability is what makes it genuinely useful in fast-moving decentralised finance environments.

Let’s walk through the main roles an agent can play. First is a yield optimizer. This agent monitors interest rates across protocols like Aave, Compound, Yearn, and Morpho, then rebalances funds to chase the best returns — with built-in circuit breakers so it won’t rebalance if the gain isn’t worth it.

Second is a liquidity manager. If you’ve used Uniswap V3, you’ll know that concentrated liquidity positions need active management. This agent watches price ranges, tracks fee income, monitors impermanent loss, and repositions when the price drifts outside the target range.

Third, a risk monitor. This one watches loan health factors in protocols like Aave — collateralisation ratios and liquidation thresholds. If a position gets too close to being liquidated, it can trigger a partial repayment before it’s too late.

The fourth role is the most immediately relevant for NZRT: the Revenue Distributor for the ITE business unit. When ETH revenue arrives, this agent reads the ITSL token holder list, calculates each holder’s pro-rata share, and calls the distribute function on the smart contract — but only after a multisig approval step. More on that shortly.

And fifth, a KYC and whitelist manager. This agent processes investor applications, validates identity documents against New Zealand’s FMCA wholesale investor criteria, and either approves addresses onto the smart contract whitelist or escalates flagged cases to a human reviewer.

Now let’s talk about how these agents actually work. The most practical setup for NZRT right now is called an off-chain agent with on-chain signing. In plain terms: the AI runs off-chain as a reasoning engine powered by the Claude API. It uses read tools to pull live data — wallet balances, on-chain events, pool figures — via a service called Alchemy. It runs a decision loop, and if action is needed, it constructs a transaction and submits it to a Gnosis Safe multisig wallet for approval. A human or group of signers reviews and approves that transaction before it ever touches the blockchain. Critically, the agent never holds private keys. It cannot move funds on its own.

The reasoning pattern these agents use is called ReAct — short for Reasoning and Acting. Here is what that looks like in practice. The agent thinks: I should check the ETH balance in the ITSL distribution contract. It reads that balance. It observes there is half an ETH available. It thinks: the threshold is point one ETH, so we are good to proceed. It calculates the distribution across twelve holders. It proposes the transaction to Gnosis Safe. It observes the transaction hash. It then notifies the relevant person to approve it in the Safe interface. Think, act, observe, think again — that is the full loop.

For more complex multi-step operations — like withdrawing from one protocol, bridging to another chain, and depositing somewhere else — there is a plan-and-execute pattern. The agent builds the full plan upfront, then works through each step in sequence, verifying state at each stage before moving on.

Now, safety. This is arguably the most important part. On-chain mistakes can be irreversible, so agentic DeFi needs layered controls. There are six layers worth knowing. By default, agent tools are read-only — write access has to be explicitly enabled. Swap tools automatically reject transactions with more than half a percent slippage, protecting against MEV attacks. Each agent has daily transaction size caps hardcoded in its tool definitions, so a mistake has a ceiling on its damage. All value-transferring transactions must pass through the Gnosis Safe approval gate — that human-in-the-loop step is non-negotiable. Circuit breakers halt the agent and raise an alert if observed state moves outside expected bounds, which can signal an exploit or a compromised contract. And every single tool call is logged with a timestamp, its inputs, and its outputs — so if something goes wrong, you have a full forensic trail to work from.

For NZRT specifically, the immediate application is automating the ITSL revenue distribution process. Today that runs as a manual script. The agent version would watch for incoming ETH deposits via an event subscription, trigger when the balance clears a minimum threshold, calculate each holder’s share from live contract data, propose the distribution transaction to Gnosis Safe, and notify the finance agent and the administrator to approve it. After execution, it logs the event to Nextcloud. One important note: the agent automates execution, but it does not change the legal obligations under the FMCA. Legal review from the administrator is still required before any of this goes live on mainnet.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.

Welcome to the NZRT Wiki Podcast. Today we’re looking at Chain Fusion & Cross-Chain.

Let’s start by unpacking what chain fusion actually means, because the term gets used in a couple of different ways. At its most specific, Chain Fusion is a concept from a platform called the Internet Computer Protocol, or ICP. ICP’s version of chain fusion lets smart contracts running on its network directly read and write to other blockchains — like Bitcoin, Ethereum, or Base — without relying on external bridges or trusted third parties. More broadly though, you can think of chain fusion as the idea of weaving multiple independent blockchains into a single piece of smart contract logic. One contract, multiple chains, all coordinated simultaneously.

So how does ICP actually pull this off? There are two key technologies at play. The first is called Threshold ECDSA, or tECDSA. What this means in practice is that an ICP smart contract — called a canister — can hold and control cryptographic keys in a distributed way. No single node holds the complete private key. Instead, it’s split across many nodes using threshold cryptography, and they cooperate to sign transactions. The result is that an ICP canister can own and operate an Ethereum wallet natively — signing and broadcasting Ethereum transactions — without any centralised custodian or external bridge involved.

The second technology is HTTP Outcalls. This lets ICP canisters reach out to external web services directly from within the smart contract environment. That includes Ethereum and Base node endpoints. So a canister can check token balances, read contract events, and react to on-chain activity happening on those other networks.

If you picture the architecture, an ICP canister sits in the middle. On one side it’s reading state from Base or Ethereum through a service like Alchemy. On the other side it’s signing and broadcasting transactions back to those networks via the distributed key scheme. For NZRT, this is technically exciting because it could allow autonomous token operations without a centralised server or private key holder — but it’s pre-mainnet for our use case, so it stays on the radar rather than the immediate roadmap.

Now let’s talk about something more immediately relevant — the bridge between Base and Ethereum mainnet. NZRT currently deploys the ITSL token on Base, which is Coinbase’s Layer 2 network built on the OP Stack. Understanding how assets move between these two networks matters for things like migrating liquidity or accepting revenue payments from mainnet wallets.

The native connection is called the OP Stack Canonical Bridge. Moving assets from Ethereum mainnet down to Base takes roughly one to three minutes. Moving assets the other way — from Base back up to mainnet — takes seven days. That delay exists because OP Stack uses an optimistic rollup model, where transactions are assumed valid but anyone can challenge them during a fraud proof window. It is the core security model of the system.

If you need faster movement from Base back to mainnet, third-party bridges can help. There are three worth knowing about. Across Protocol uses an intent-based model and is known for being fast and low cost. Stargate, built on LayerZero, uses unified liquidity pools and supports many chains. Hop Protocol is purpose-built for OP Stack Layer 2 networks. The trade-off with any of these is that you’re accepting additional trust assumptions beyond the canonical bridge — the canonical bridge has no extra counterparty risk, while third-party bridges introduce their own smart contract risk.

For cross-chain messaging more broadly, there are three major protocols to understand. The first is Chainlink CCIP, the Cross-Chain Interoperability Protocol. It uses Chainlink’s oracle network to validate and relay messages across chains. It’s enterprise-grade and well-suited to regulated environments and high-value transfers, though it comes at a higher cost and requires paying fees in Chainlink’s own token.

The second is LayerZero. It supports over seventy chains and uses what are called Decentralised Verifier Networks to attest messages. One of its standout features is the Omnichain Fungible Token standard — OFT — which lets an ERC-20 token like ITSL exist natively on multiple chains at the same time rather than being wrapped or bridged. That makes it a compelling option if ITSL ever needs to expand beyond Base.

The third is Wormhole. It uses a network of nineteen validators and is particularly strong for projects that need to reach non-EVM chains like Solana, Sui, or Aptos. It had a significant exploit in 2022, though the funds were fully repaid.

So where does all of this leave NZRT? For ITSL, the current recommendation is to stay single-chain on Base until the mainnet launch is complete. If investor demand grows to the point where wholesale investors want to buy ITSL without bridging from Ethereum mainnet, LayerZero’s OFT standard is the leading candidate to evaluate after launch. On the consulting side, cross-chain architecture is a genuine billable advisory area for ICS — helping clients choose between these protocols, integrate CCIP for regulated token transfers, or design multi-chain token architectures from the ground up.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.

Welcome to the NZRT Wiki Podcast. Today we’re looking at Decentralized AI Overview.

So let’s start with the basics. What actually is Decentralized AI? You might have heard it called DeAI for short. The idea is that AI model inference, training, and governance happens outside the infrastructure of any single centralized provider — companies like OpenAI, Anthropic, or Google. Instead of your application calling one company’s API, decentralized AI spreads that computation across a whole network of independent nodes. Those nodes are economically incentivized through tokens to participate honestly, and their outputs can be verified using cryptographic proofs.

To understand why that matters, it helps to compare it with what you’re probably already familiar with — centralized LLM APIs. Think about six key dimensions. First, control: with a centralized provider, one company is in charge; with a decentralized network, control is spread across many nodes. Second, pricing: centralized systems charge in USD based on usage, while decentralized networks use token-based incentives. Third, censorship: centralized providers enforce their terms of service, meaning some requests can be blocked, whereas decentralized networks are generally permissionless — though that varies. Fourth, verifiability: with a centralized provider you’re trusting them to run the model correctly, whereas decentralized systems can use cryptographic or zero-knowledge proofs to verify outputs. Fifth, latency: centralized APIs are highly optimized and fast; distributed networks tend to be slower. And sixth, model selection: centralized providers curate the models available, while decentralized networks are more open.

For most NZRT agent tasks, centralized APIs remain the right default. Lower latency, higher quality, simpler integration. DeAI becomes relevant for specific situations: censorship-resistant inference, on-chain verifiable AI decisions, or client workloads that require decentralization as a compliance or trust property.

Now let’s walk through the key decentralized AI networks worth knowing about. The first is Bittensor, which runs on its TAO token. Think of it as a decentralized machine learning marketplace. Validators score miners who run AI models, and the best-performing models earn TAO rewards. It’s organized into subnets — specialized networks for things like text generation, image processing, or even protein folding. For NZRT’s ICS consulting arm, this is relevant when clients want permissionless LLM access without being locked into a single provider, or when TAO itself is part of an investment thesis.

Next is Ritual, which runs an inference layer called Infernet. Ritual connects on-chain smart contracts to off-chain machine learning models — so a smart contract can actually call an AI model as a native operation, through Ritual’s oracle network. For NZRT, the interesting future architecture here would be an ITSL smart contract that calls an AI model to decide things like revenue distribution timing or investor eligibility.

Then there’s Giza, which focuses on Zero-Knowledge Machine Learning, or ZKML. This is about proving that a model ran correctly without revealing the inputs or the model weights. A smart contract can accept a zero-knowledge proof confirming that a specific model produced a specific output. The NZRT use case is around the ITE business unit — specifically, auditable ITSL revenue distribution, where you could prove the allocation algorithm ran correctly before the Gnosis Safe approves a transaction.

Similarly, Modulus Labs focuses on ZK-ML proofs for on-chain verifiable neural network inference, with a particular focus on gaming, DeFi, and prediction markets where outcomes have to be provably fair. And finally, Ocean Protocol is a decentralized data marketplace where data providers earn tokens and AI models can train on licensed data. For NZRT this is lower relevance — noted mainly as a knowledge reference.

Now let’s dig into that ZK-ML concept a little deeper, because it’s the most architecturally interesting one. The flow works like this: off-chain, an AI model runs its inference and generates a zero-knowledge proof of correct execution. That proof is then passed on-chain, where a smart contract verifies it and accepts the result as a trusted input — without ever having to recompute the inference itself. This creates what’s called trustless AI decisions on-chain. The practical implication for NZRT is that an ITSL distribution agent could prove it applied the correct allocation algorithm, and only then would the Gnosis Safe approve the transaction. Worth noting though: ZK-ML is still computationally expensive. Proof generation can take anywhere from seconds to minutes even for small models. It’s production-ready for simple models but still research-stage for anything at the scale of a large language model.

There’s also the concept of AI DAOs — Decentralized Autonomous Organizations that govern AI model parameters. A DAO can vote on which model version is used, what system prompts are applied, and how outputs are acted on. Bittensor subnets already do this, with TAO stakers voting on validator quality and model standards. For NZRT’s ITE unit, this could eventually mean ITSL token holders voting on which model drives distribution decisions — but that’s firmly a post-mainnet consideration.

So to bring it all together: across NZRT’s business units, the DeAI opportunities are real but all currently low priority. ZK-ML for ITSL distribution, AI DAO governance, and Ritual-style oracle integration are all on the radar for ITE — but flagged as post-mainnet. For current operations, keep using Claude via the existing AI agents stack. DeAI is a consulting knowledge domain and a future architecture option, not an immediate infrastructure change.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.