IPOR Fusion Python SDK 4.0: Agentic Tooling, Cross-chain, Ink and Robinhood Chain Support

TL;DR

• Preflight now shows what a batch of vault actions will do before anyone signs it
• Timelocked operations can now be scheduled, executed and cancelled from the SDK
• Every IPOR Fusion contract can be looked up by name, with no hardcoded addresses
• Cross-chain and HyperCore support
• Ink and Robinhood Chain added in 4.0
• Every feature above is available in Python, the CLI and the MCP server, for operators and the AI agents assisting them

Get started

• Python SDK and CLI: pip install -U ipor-fusion
• MCP server: mcp.ipor.io
• For AI agents: llms-fusion.txt
• Release notes: SDK & CLI v4.0.0
• Migration guide from 3.x: MIGRATION_4.md

This release lets operators, and the agents working with them, see what a transaction will do before anyone signs it, manage timelocked operations from start to finish, and find any IPOR Fusion contract by name.

4.0 also follows the official cross-chain and HyperCore contracts, reads both versions of the ExternalState market, and adds Ink and Robinhood Chain, bringing the total to 11 supported chains.

What ships with SDK 4.0

1. Preflight: see the outcome before signing

Until now: operators saw the result of a transaction after signing and sending it.

With 4.0: the SDK checks a batch from the point of view of the account sending it. It confirms the account has the right permissions and that every fuse in the batch is registered with the vault, balance fuses included. It then simulates the batch and reports the result before anyone signs, including the revert reason and gas cost.

Main functions: preflight_execute (Python), fusion vault preflight (CLI), vault_preflight (MCP)

2. Timelocked operations

Until now: operations that sit behind a time delay (a timelock) were scheduled with separate tools, outside the SDK.

With 4.0: the SDK builds the schedule, execute and cancel calls, and tells you whether a call can go now, needs scheduling or is still waiting, along with the next call to send. One less thing to track by hand.

Main functions: AccessManager schedule, execute and cancel; read_call_plan

3. Contracts by name

Until now: fuse, factory and manager addresses were kept in the ipor-abi repository and referenced from there.

With 4.0: any IPOR Fusion contract can be looked up by name, straight from IPOR’s address registry. When a new fuse ships, your scripts pick it up by name, with no address hunting and no copy-pasting.

Main functions: fetch_address_registry (Python), fusion address lookup, names and list (CLI), matching MCP tools

4. Cross-chain and Hyperliquid (preview)

Until now: the SDK followed the earlier cross-chain and HyperCore test deployments.

With 4.0: the SDK follows the official cross-chain contracts deployed on 22 October, with transfers between Arbitrum and HyperEVM running over Chainlink CCIP and Stargate.

It is important to note that from now on, the SDK supports only this official deployment. The earlier pilot and test deployments are no longer supported. Developers importing cross-chain names from the top level of ipor_fusion to date should now import them from ipor_fusion.crosschain.

Cross-chain transfers also come with built-in safety checks. When a vault sends assets to another chain over CCIP, it sets a minimum on the amount that must reach the destination chain, requests for vault shares on the other chain carry a cap on fees, and vault value reports (NAV attestations) are accepted only when they are fresh and complete. Assets that don’t have a price yet on the receiving chain are flagged before they’re counted.

Additionally, the SDK now reads the HyperCore contracts released on HyperEVM and encodes their new vault limits: a cap on each perp position, guards against sudden jumps in vault value or gaps between the market price and the oracle price, and timeouts on transfers. Developers importing HyperCore names to date should now import them from ipor_fusion.hypercore.

While these features are in preview, the API may still change between minor versions.

Main functions: ipor_fusion.crosschain (lanes, discovery, encoders), ipor_fusion.hypercore (fuses, readers, substrates)

5. External positions

Until now: the SDK read the original build of the ExternalState market, which brings positions held offchain, such as assets with a custodian, into the vault’s accounting.

With 4.0: it reads both versions of the market, the earlier one still used on Ethereum, Base and HyperEVM, and the new one released on Arbitrum, where custodian updates are tracked by a confirmation count instead of a timestamp.

Developers using ExternalStateExecutor.mark_nav to date should now send propose_balance and confirm_balance from separate custodians.

Developers referring to the market as IporFusionMarkets.RWA to date should now use IporFusionMarkets.EXTERNAL_STATE (market 50).

Main functions: ExternalStateExecutor, read_external_state

6. Named errors, exact amounts

Until now: reverts showed up as a raw error code (their selector), and amount conversion was handled in each script.

With 4.0: every error defined in IPOR Fusion’s contracts now shows up by name, such as AccessManagedUnauthorized, and token amounts are converted with whole-number math, keeping every digit exact with no rounding.

Additionally, every exception the SDK defines now derives from IporFusionError and can be imported from ipor_fusion.

Main functions: named error registry; parse_amount and format_amount, parse_shares and format_shares

7. 11 chains

With 4.0: the vault tooling covers 11 chains in total, with Ink and Robinhood Chain added in this release, and runs on Python 3.11 to 3.13.

Main functions: --chain-id ink, --chain-id robinhood

8. Upgrading from 3.x

4.0 is a major release, and developers will need to update most code written for 3.x. The biggest change is to wrappers. You now create a wrapper from the contract’s address alone, then pass the chain connection (ctx) each time you call it.

Among other changes, methods that read the chain now start with read_ (for example, get_balance_fuses() becomes read_balance_fuses(ctx)), cross-chain and HyperCore imports now live in their own subpackages (see section 4), and the CLI and MCP return the same JSON format.

The migration guide walks through it step by step, starting with a short checklist of what to look for, and the release notes list every change.

These notes describe changes to the IPOR Fusion Python SDK. They are not operational or financial advice. Operators are responsible for testing changes against their own vaults and configuration before use.