The human.tech Wallet Protocol for Multi-chain Apps and Agent Payments

One account, one set of rules, and every settlement network those rules can reach. Squid Mode on the WaaP SDK and agent CLI is live on EVM, Sui and Solana.

Why we built a wallet protocol

To own your digital presence, you must be able to custody your own keys. We built the human.tech Wallet Protocol to make onboarding to cryptographic key custody as easy as possible. Protected self-custody is our answer to Wallet-as-a-Service and embedded wallet landlords that rent out keys to devs and their users.

The human.tech Wallet Protocol was built to solve the security dilemma of self-custody and onboarding via embedded wallets. Protected self-custody allows developers to grant users keys that are universal across apps, simple onboarding with social accounts, recovery with biometrics and passkeys and granular security policies that limits the blast radius of active attacks on a user’s account.

Human.tech was built to accelerate humanistic technology. We believe freedom begins with protected self-custody.

What is Protected Self-Custody?

Protected Self-Custody means your wallet is protected against malware, malicious apps, phishing, and user error or key loss. It means that no single party can move user funds, including the infrastructure the wallet runs on. Self-custody on its own makes the user solely responsible for keeping their wallet safe.

Non-custodial wallets like Privy, Turnkey, or Fireblocks handle the responsibility for the user but also have the final say on how a wallet can be used and will charge a fee for a person’s access to a wallet. Protected Self-Custody is the third other option. The human holds the authority, the key doesn’t exist, but rather is sharded into pieces, and you set the policy that runs before anything can be signed.

What shipped

There are two account types, and they are both the human.tech Wallet Protocol.

• Standard human.tech Wallet Protocol. The signature is completed by our secure enclave. One network per account. Nothing to fund, no network fee for the signature itself.
• human.tech Wallet Protocol Squid Mode. The signature is completed by our enclave together with Ika's validator network. One account reaches EVM, Sui and Solana. Every Squid signature settles on Sui, so Squid Mode requires SUI for Sui gas and IKA for the network's fee.

Both run the same policy gate, so the rules you write do not change when you change modes. Squid Mode is the one this release is about.

Every chain is coordinated on Sui. One account now signs on EVM, Sui and Solana, and the signature is completed by an independent network coordinated by a move contract on Sui rather than by one company’s server. Developers can now orchestrate complex computation across every supported chain in a single transaction without needing to deploy a contract or hold gas fee tokens on that chain.

A human.tech Wallet private key does not exist in the way traditional keys exist. Instead key shares from independent parties are mathematically combined to authenticate and authorize actions.

One share sits in our enclave infrastructure and the other sits with Ika’s validator network, and neither side can produce a signature alone. This form of threshold computation between a single party and a network is called 2 party computation with Multi-Party-Computation (2PC-MPC).

2PC-MPC ensures that a decentralized network co-signs a pre-defined policy, such as do not spend >$200 without my faceID. Signatures are only produced if the network comes to consensus that the requested signature is valid.

This architecture is more resilient to censorship and vendor lock-in since a network of independent nodes secure a signing capability anchored on the Sui network as a Move contract.

What you can build this week that you could not build last week

Three new recipes ship with this release. Each one runs on a single account signing across more than one settlement network.

Cross-chain portfolio rebalancer. No more cross-chain liquidity fragmentation. An agent holds positions on an EVM network and on Solana, reads both, and rebalances across them from one balance. One account, one login, one set of limits.

Scoped trading agent. Set the limits once, then let it run. A prediction-market agent gets a grant instead of the account: one origin, one chain, an address allowlist, a dollar ceiling and a two-hour clock. Inside those bounds it trades without prompting you to sign anything, which is the difference between an agent that works and one that pages you every few minutes. Outside them it stops.

Multi-chain payouts. Pay people on whichever chain they asked to be paid on, from one balance and one budget, without running three payout systems.

Start with whichever is closest to what you already have. Swapping out how an existing project handles keys is usually under an hour.

Three surfaces

The WaaP SDK is an embedded wallet for your app with the policy layer behind it. Your users get wallets and you get the policy layer; they never see us. Social login, no seed phrases.

The WaaP CLI is for operators, agents and automation. waap-cli squid carries init, status, addresses, refill, send-tx, sign-tx, sign-message and sign-typed-data. addresses prints the EVM, Sui and Solana addresses for one account.

Users can access their wallet at top-level iframe at https://waap.xyz. Here users can manage their security settings, MFA policies, and balances across chains and applications.

What the policy gate actually does

Every signing request is checked server-side before a signature exists. Multi-factor authentication or custom policies can be wired around custom threat and security models:

• Transaction simulation. Every transaction is simulated before it is signed, giving users and developers proactive prompts against potential security exploits. The simulation engine can be swapped or self-hosted without changing your code.

• Recipient reputation. The destination address is scored for reputation and the requesting domain is checked against known-malicious lists.

• Address binding. The protector re-derives your real addresses server-side rather than trusting what the client claims. A compromised client cannot name an unrelated address to dodge the spend limit, which is a specific attack the binding exists to close.

• Escalation. Risk above your threshold suspends the signature and asks you, through whichever channel you set. One approval resumes it.

• Scoped grants. A grant is how you pre-authorise an agent instead of signing for it. It is a signed token carrying an origin, a chain, an address allowlist, a dollar ceiling and an expiry capped at two hours. You program the policy once, within limits you choose, and inside those bounds the agent transacts without a prompt. Grants lapse rather than being revoked, so anything running continuously renews often and the blast radius of any single grant stays two hours wide.

One policy record governs the whole account, set once, applying to every address it holds. Two limits on that today. Spend is accrued per address against your one limit value, so the counters are not yet pooled into a single cross-chain budget. And the dollar limit engages on mainnet, because testnet assets have no price and resolve to zero; risk, reputation and escalation checks still run on testnet.

The security model

We designed the human.tech Wallet Protocol security model with recent exploits in mind to offer a high level of confidence for developers.

In general, losses are capped through transaction limits and simulation of risky or anomalous transactions that require multiple factors of authentication.

How this compares

The embedded-wallet category is crowded and most of it is solving a different problem: getting a key into an app quickly. The axis that matters here is narrower. Who can produce a signature, and where the rule that permits it is enforced.

Competitor rows are their own published terms, checked 2026-08-24.

Read the first column first. Every other provider on this list is one party: their enclave, their infrastructure, their say. That is a reasonable trade and it is why the category works. It also means the guarantee is a promise about a company rather than a property of the system. Squid Mode splits the signature across two parties who do not share an operator, and puts the policy check in front of both of them.

The honest counterpart: one party is faster and simpler to reason about, and if you are shipping a consumer app where the wallet never leaves your product, it is very likely enough. Squid Mode is for the case where the account outlives the app, reaches more than one chain, or is going to be handed to something that acts on its own.

Reach: chains and curves

One login provisions two capabilities on two elliptic curves, sqd1 on secp256k1 and sqd2 on ed25519. This makes the human.tech Wallet Protocol compatible on:

Which mode to pick

There are two ways to complete a signature, and the right one depends on what you are protecting. Both run the same policy gate, so the rules you write do not change when you change modes.

Squid Mode carries a network cost that Standard does not. We charge nothing to integrate either one. A Squid signature settles as a transaction on Sui and is completed by Ika's validators. Both are public networks with their own fees. So a Squid account holds SUI and IKA, and spends a little of each every time it signs. That is not our fee. It is what a signature costs when no single operator can produce it alone.

Pick by what the account is for. Squid Mode is the account for value that justifies removing any single operator as a point of trust, for reaching more than one chain from one login, and for anything handed to software that acts on its own. Standard is the account for onboarding at volume, where the wallet stays inside one product and the operator is already the party the user trusts.

A developer does not have to make the user think about EVM gas at all. See the gas tank below.

Start Building Now

Integration is free. A Squid account is not free to operate: fund it with SUI for Sui gas and IKA for the validator network's fee before it signs. A Standard account needs neither.

Versions. Squid Mode ships in @human.tech/waap-cli 2.1 and @human.tech/waap-sdk 2.2. Earlier versions have no squid command and no initWaaPSquid. Check the docs for the current version to install.

In an application. Squid accounts are created explicitly, so call onboard() after login and before signing:

npm install @human.tech/waap-sdk

import { initWaaPSquid, WAAP_EVENTS } from '@human.tech/waap-sdk'

const waap = initWaaPSquid({
  environment: 'production',
  chains: ['evm', 'sui']
})

await waap.session.login()
await waap.squid.onboard() // creates or restores both curves (sqd1 + sqd2)

waap.session.on(WAAP_EVENTS.squidReady, () => {
  console.log(waap.squid.getStatus()) // { state: 'active' }
})

The quickstart is a working wallet in about ten minutes. The recipes are complete running examples you can change rather than snippets you have to assemble.

From a terminal. Four commands to a multi-chain account with a spend limit on it:

npm install -g @human.tech/waap-cli

waap-cli signup
waap-cli policy set --daily-spend-limit 100
waap-cli squid init
waap-cli squid addresses

squid init provisions both curves. squid addresses prints the EVM, Sui and Solana addresses for the one account. Fund the Sui address with SUI and IKA before the first signature.

The gas tank: users should not have to buy gas first

Every on-chain transaction needs the chain's native token to pay for it. For a new user that is a cold start. They cannot do the thing they came to do until they have gone somewhere else, bought a token they have never heard of, and come back. Most of them do not come back.

The gas tank removes that step. It is first-party gas sponsorship for EVM chains, built into the Wallet Protocol, with no third-party paymaster to integrate. There are two shapes, and the developer one is what ships at launch:

A sponsor tank is how onboarding gets fixed. The developer pre-funds it, sets allowlists for which contracts, which addresses and which domains may draw on it, and the user transacts without ever holding gas. The wallet just works, and the developer pays for it in the background.

Privileges: one approval, then a session that does not interrupt

Signing every transaction by hand is correct for a large transfer and hostile for everything else. A game, a trading loop, or anything charging per action cannot ask for a confirmation each time.

A Privilege is a scoped, time-bounded pre-approval. An app calls window.waap.requestPermissionToken(...) and the user approves a specific shape once:

• allowedAddresses which recipients it may pay
• chainId which chain it is valid on
• requestedAmountUsd a cumulative dollar ceiling across every transaction under it
• requestedExpirySeconds how long it lives

After that, transactions matching the scope sign in the background with no prompt. The origin is bound server-side to the domain that asked, so a Privilege granted to one app cannot be replayed by another. Agents use the same object from the CLI by passing --permission-token to a signing command.

This is the layer the security model rests on. Policies set the hard limits, 2FA gates what is risky, and a Privilege carves out a narrow, expiring exemption inside those limits. It never widens them.

Where it sits in the stack

human.tech is a stack of software that provides safeguards for autonomous organizations, governments, and enterprises. The human.tech Wallet Protocol provides easy onboarding to cryptographic key self-custody and a control plane over autonomous processes and applications acting on the user’s behalf. Our Human Passport application provides identity verification and is used by over a hundred projects to secure grants, rewards distributions, and screen for bad actors.

Where this goes next

human.tech’s Wallet Protocol is still early in development and will soon expand out to include additional features and support for many chains. Expect to see more recipes and examples of what you can build with the WaaP SDK & CLI.

1. One rule binding across chains. Because the approval settles on Sui as an object, storing or wrapping that Capability object inside a Move package allows programmable Move logic to strictly govern signature approvals. A single cross-chain budget, or a condition on one network gating an action on another, an example of what is possible.

2. Pooled spend accounting, so the one limit value has one counter behind it rather than one per address.

3. A self-hosted policy webhook, for teams that already run their own risk systems and want the gate to call them.

Join us on telegram to stay in the loop with developer updates.