Nortik

Case Study · Kite Network

Permissionless token transfer,chain to chain.

Kite Network is a permissionless bridging layer for moving tokens between blockchains. We built the transfer solution end to end: a plug and play bridge that carries a token from one chain to another over Axelar, with wallet connection, route and token selection, an up front relayer gas quote, and delivery to the sender's own wallet or to any address they name.

Chains in the transfer picker
5+Chains in the transfer picker
Tokens per route
5Tokens per route
Wallet connectors
3Wallet connectors

Engagement Overview

Kite Network set out to make moving a token between blockchains an ordinary thing to do. Chains do not read each other’s state, so value does not cross between them on its own: it has to be locked on one side, attested by something both sides trust, and released on the other. Kite wanted that whole round trip behind a single form, and wanted it permissionless, so that using it needed no account, no listing and nobody’s approval.

We built the transfer solution alongside their own engineers. It is plug and play by design rather than one integration per pair of chains: the same interface picks a source network, a destination network, a token and an amount, quotes the relayer gas before anything is signed, and hands the routing to Axelar underneath. A route the product did not ship with is a configuration rather than a rebuild.

The interesting problem was never the happy path. A bridge transfer is irreversible, it crosses a trust boundary halfway through, and it can strand value in a way an ordinary payment cannot. Everything below is about the work that goes in front of the Approve button, so that by the time somebody presses it there is nothing left to get wrong.

5+
Chains in the transfer picker
5
Tokens per route
3
Wallet connectors
Engagement
Cross-chain product engineering
Team
Two dedicated engineers
Focus
Permissionless token transfer across EVM chains
Working model
Embedded with the client's team, time and materials
A bundle of lit optical fibres fanning out of the dark, each strand carrying its own point of light

The Challenge

Blockchains are deliberately sealed. A chain can prove what happened inside itself and nothing at all about what happened anywhere else, which is exactly the property that makes it worth trusting and exactly the property that strands value on it. Anything that carries a token across that gap has to lock it on one side and mint or release it on the other, and hold the two halves in agreement while they are apart.

That makes a bridge unlike almost anything else with a form in front of it. There is no settlement window and no chargeback: once a transfer is signed it is final. The sender pays gas in the source chain’s own currency and receives on a chain where their balance may be zero. A destination address typed one character wrong is not a failed payment, it is a permanent one. And because it is permissionless, there is no support desk in the loop to catch any of it.

The second constraint was reach. A bridge wired one pair of chains at a time is a bridge that needs an engineer for every new network, and Kite wanted the opposite: one surface that treats the route as data, so that adding a chain is a matter of configuration rather than another integration. Which meant the interface had to be honest about a route it had never carried before, and safe on the first attempt rather than the tenth.

The Solution

A transfer that cannot be undone puts all of the design work before the button rather than after it. So the whole product is one form that refuses to be ambiguous: about the route, about the cost, and about where the tokens land.

The Kite transfer form with a wallet connected, sending 345.0 USDC from Avalanche to Polygon, with the relayer gas fee quoted above the Approve button

One form, and the whole transfer inside it

A bridge transfer has four decisions in it and the interface asks for exactly those: the chain the token leaves, the chain it arrives on, which token, and how much. Everything else is derived. The connected wallet's balance for the chosen token is read back into the field, MAX fills it, and the relayer gas is quoted in the sender's own currency above the button rather than discovered in a wallet popup after the decision is made. The button stays Approve until every one of those is answered, so there is no state in which it can be pressed too early.

  • Route And Amount
  • Live Balance
  • MAX
  • Up Front Gas Quote
The Kite Select Network modal, listing Ethereum, Avalanche, Fantom, BNB and Polygon above a scrollable list, over the blurred transfer form

Any route, because the route is data

Source and destination are the same searchable picker rather than two hard-wired lists, and the control between them swaps the direction in one press instead of making somebody re-pick both. Ethereum, Avalanche, Fantom, BNB and Polygon are in it, and the list scrolls past them. This is what plug and play actually means on a bridge: a chain is a row in that picker and a configuration underneath, so reach grows without a new integration and without the interface learning a special case for the pair somebody happens to want.

  • Searchable Chain Picker
  • Direction Swap
  • EVM Chains
  • Axelar Routing
The Kite transfer form with Send to another wallet enabled, showing a full destination address validated with a green check beside it

Delivery to an address it checked first

By default a transfer lands back in the wallet that signed it, which is the safe case and the common one. Send to another wallet opens the case that is neither: paying somebody else, or moving to a wallet that only exists on the destination chain. The full address is shown rather than truncated, because a truncated address is unverifiable by eye, and it is validated in the field with the result stated next to it. On a transfer that cannot be reversed or refunded, the check has to happen before the signature, not after it.

  • Third Party Payout
  • Full Address
  • Inline Validation
  • Irreversible By Design

And the three steps before any of it

Permissionless means the product cannot lean on an account to know who it is talking to. Everything it needs arrives in the first three interactions, and it asks for nothing else.

  • The Kite transfer form in its disconnected state, with Select Network in both fields, a zero amount and a Connect Wallet button

    Nothing before a wallet

    With no wallet attached the form is inert and says so: both networks unset, no token, a zero amount, and one action. There is no sign-up in front of it and no account to make, because there is nothing for the product to know about somebody who has not connected.

  • The Kite Connect Wallet modal, offering Metamask, Wallet Connect and Coinbase Wallet above a link to learn more about wallets

    Three ways in, and no fourth

    Metamask, Wallet Connect and Coinbase Wallet, which between them cover browser extensions, mobile wallets over a scanned session and a custodial wallet, and a link out for anybody who has none of the three. Connection is the only identity the product ever asks for.

  • The Kite Select Token modal, listing ETH, DAI, USDC, BTC and USTD with balances beside each, over the blurred transfer form

    The token, and what you actually hold

    ETH, DAI, USDC, BTC and USTD, each row carrying the connected wallet's own balance rather than a bare symbol list, and a search field above them. Picking a token and reading what is available to send are the same glance rather than two.

A Nortik engineer's hands on a keyboard, working through code on screen

Business Impact

Kite ended the engagement with a working bridge rather than a proof of concept: connect a wallet, pick two chains and a token, read the cost, approve once, and the tokens arrive on the other side, either back to the sender or at an address they chose.

The part that mattered commercially was the shape underneath. Because the route is data and the routing sits on Axelar rather than on a hand-rolled integration per pair, the chains and tokens on offer are a configuration rather than a release. That is the difference between a bridge that supports the networks somebody had time to wire and one that can follow its users onto the next chain they care about.

Two engineers took it from the client’s designs to a functioning cross-chain product, embedded in their team and working to their direction throughout. For a category where most of the engineering is spent making an irreversible action safe to take, that is the result we would point at.

Your AI team is ready.Are you?

Let's shape the future of AI, together.