An agent that can move funds needs a leash, not a login. zkCross gives every agent a scoped key. It can call the functions it was built for and nothing else. No single key controls the vault it touches. Three independent signers still have to agree before anything moves. The agent gets exactly enough power to do its job and no more. zkcross.network

26,290 unique wallets have moved funds through zkCross Network so far. That is not a testnet number. It is $111.8M in real volume, settled across live chains. The signer set has held under that load without a single incident. Proof scales differently than a pitch deck. See the numbers at zkcross.network

No single key moves funds on zkCross. Every transfer needs multiple independent signers before it settles. That is not a policy. It is the multisig design underneath $111.8M in volume and 197K+ transactions. One compromised key cannot touch any of it. See how the signer set works.

Our 4 MPC signers are not one team with four laptops. They run on separate infrastructure, held by separate operators. No shared cloud account can leak all four keys at once. A release still needs 3 of them to agree. One operator going dark does not stop the network. Read how the signer set is built at zkcross.network

A signing setup has two jobs. It has to stop a thief. It also has to keep working when a machine goes down. A single key fails both. Lose it and nothing moves. Leak it and anything can move. zkCross Network signs releases with 3-of-4 MPC. One signer can be offline and routes still settle. One compromised signer cannot release anything alone. The architecture is written up at zkcross.network

An AI agent should never hold a key that can move everything. On zkCross Network an agent asks for a route. The release still needs 3-of-4 MPC signers to agree. The agent never holds the signing keys itself. So a buggy agent can ask for a wrong transfer. It cannot sign one on its own. Building an agent that moves value across chains? Start at zkcross.network

Every cross-chain route works on a quiet afternoon. The question is what it does when a chain is congested. Most bridges widen the gap between the two legs. The transfer is still moving and nobody can say where it is. zkCross Network settles the route as one transaction. Congestion makes it slower. It does not make it uncertain. Slower is something you can explain to a user. Missing is not. The routes are documented at zkcross.network

An agent working across four chains should not need four sets of permissions. Most teams land there anyway. They hold a key per chain and a bridge account per chain. Nobody has one view of what the agent is allowed to move. zkCross Network keeps one permission set and enforces it at settlement. The agent asks for a route. The layer checks the permission before anything gets signed. The routing is described at zkcross.network

A cross-chain transfer has a last step on the destination chain. That step can fail. On most bridges the tokens still arrive and the call does not. The user is left holding a wrapped asset and a support ticket. zkCross Network settles the whole route or none of it. A failed step sends the funds back to where they started. There is no half finished state for anyone to clean up. The routing is described at zkcross.network

A cross-chain transfer usually needs two signatures. Only one of them is yours. The user signs on the source chain. Something on the other side has to sign for the arrival. That something holds a key, and it sits with an operator or a validator set. zkCross Network settles the route as a single transaction. The user authorises the whole path once. Nothing else has to sign for it to finish. Docs: zkcross.network

A retry becomes dangerous the moment a transfer has a middle state. Your agent sends, gets no answer and tries again. Now the value may have moved twice. Teams handle that with idempotency keys and a reconciliation job. zkCross Network settles a route as one transaction. A retry does the whole thing or it does nothing. There is no half to clean up. Safe agent code gets much shorter. Docs: zkcross.network

Ask your support team how many tickets start with a transfer that is stuck. The answer is the number worth watching when you compare cross-chain providers. It is not throughput and it is not fees. It is the count of people writing in because their money is somewhere they cannot see. zkCross Network routes a transfer as a single transaction. Both legs happen together or neither happens at all. There is no middle state for a user to notice. The routing model is at zkcross.network

Integrating zkCross Network does not give your team a key to look after. You hold no signing material. There is nothing to store in a vault, nothing to rotate when someone leaves, and nothing your security review has to sign off. Signing sits with us, split so that no complete key exists anywhere. Integration docs: zkcross.network

There is no private key at zkCross for anyone to steal. Signing is split across four holders and any three of them can complete a signature. The full key is never assembled, not on a server and not on anyone's laptop. Each holder only ever computes with their own share. That changes what a breach means here. Someone who takes one machine takes one share, and one share signs nothing. 197,171 transfers have settled this way. zkcross.network

A standard can describe an agent. A standard cannot constrain one. ERC-8004 is the declaration layer. Identity says which agent this is, reputation carries its record, and validation covers what has been checked. Enforcement is a separate job and it is ours. Three-of-four MPC on the operator set, contracts audited by @HalbornSecurity, and atomic settlement across supported chains. An agent settling through zkCross can only act inside the envelope the execution layer allows. Declared on 8004. Enforced by zkCross, and the settlement path is public at zkcross.network.

A cross-chain transfer has to land somewhere, and that destination is the part worth checking. On zkCross the destination is not a parameter we trust. The contract decodes the recipient out of the bridge payload. It refuses the transfer unless that recipient is your own vault. There is no address book to poison. There is no operator field to overwrite. If the destination is not your vault, nothing settles. $111.4M has moved under that rule. zkcross.network

The unsolved problem is not agent identity. It is one agent deciding whether to deal with another it has never met. Today a person reads the registry and makes that call. That does not scale to a world where agents transact with each other all day. It only works when reputation and validation do the deciding themselves. Today they sit there as metadata for a person to interpret. That is the next thing we are building toward. zkcross.network

A registry entry is portable. An execution envelope is not, and that asymmetry is deliberate. An agent's description travels with it to any chain, any counterparty, any product that wants to read it. The limits on what it can actually do stay with whoever operates the infrastructure it settles through. If those two moved together an agent could carry its own permissions around. It cannot. On zkCross Network the envelope is three of four MPC and audited contracts, and it does not travel. zkcross.network