The problem Isekai solves

All current privacy protocols such as RAILGUN and Privacy Pools require depositing assets in by calling their smart contract. This publicly broadcasts exactly which addresses are depositing into the pool, which asset they are depositing and how much of it as well as the TVL in the pool. These factors wildly affect the anonymity set.

What if all of those were no longer bottlenecks? Isekai is a privacy protocol inspired by EIP-7503 that enables cross-chain zk-wormholes for any asset. Instead of the depositor interacting with the contract directly, they instead send the funds to what looks like a normal EOA address which is secretly a hash of secret values that teleport those funds into the actual recipient's private balance in the shielded pool on any chain. That user can then either unshield or transact within the shielded pool. Since zk-wormholes look like any other normal token transfer, onlookers are unable to detect exactly who is depositing in the shielded pool, which token and amounts of each are being deposited, nor from which chain. It gains vastly stronger privacy and eliminates those previous bottlenecks.

In addition, screeners are implemented to reject illicit funds from entering the shielded pool despite them not knowing which transfers are normal transfers and which are zk-wormholes. In other words, compliant privacy.

Any contract that inherits the interface can do zk-wormholes and participate in the shielded pool. This includes ERC20 tokens, NFTs, wrappers of existing assets, etc. This also means they will be cross-chain assets. Every transfer increases the anonymity set for all other assets and users.

Isekai is a modified fork of a previous project called Kamui that incorporates the following improvements:

• zk-wormholes and private transfers --> cross-chain zk-wormholes and private transfers + cross-chain private transfers
• Limited tokens to implementation whitelisting --> fully permissionless

Challenges I ran into

The biggest hurdle has been handling the cross-chain merkle tree structure in the frontend to correctly generate proofs and execute transactions. It's a complex custom tree structure that requires monitoring the status of each chain and their synced merkle root state. And then recreating the merkle tree to generate the correct zero-knowledge proof and transaction execution.

Strong event emissions and subgraph indexing helped, but frankly it was a lot of trial-and-error in debugging it until it worked.

Use of AI tools and agents

I used coding agents like opencode and cursor to help with debugging and frontend design.