I decided to take a brief detour from a dive into Kima’s technical features, to cover another aspect of Kima: our Compliance Module (CM).
But first, a story about a hack:
KyberSwap hack
On November 2023, someone hacked the DEX (Decentralized EXchange) KyberSwap to the tune of $46 million. This tanked the protocol, its tokens, and cost liquidity providers their funds. The team announced it would extend a grant to those who lost funds in the exploit and have not been recovered. The hack forced KyberSwap to cut half of its workforce.
While this looked like one more hack, and everyone were expecting the inevitable North Korea/Russia connection to pop up, this hacker decided to play with their prey. In a series of on-chain messages, he offered to return some of the funds, in return of being made CEO of KyberSwap, the entire C-level quitting, and a bunch of other empty promises:
Since no one was about to capitulate to these ridiculous demands, the hacker lost patience, and started bridging their ill-gotten gains from the blockchains they were on to Ethereum, from which they can cash out.
Who needs compliance?
Kima Network functions as a universal payment infrastructure, acting as a bridge to connect liquidity across different blockchains. From a more focused standpoint, it can be described as a facilitator of cross-ecosystem transactions.
But as I explained in a previous post, Kima Network is more than a bridge. It’s an infrastructure solution that settles transactions containing any type of asset, including fiat transactions that involve bank accounts (soon: credit cards…shhh!), and other financial transaction types.
Banks and financial institutions invest billions of dollars in compliance tools to make sure hackers do not trade through them (yes, there are exceptions).
They deploy KYC (Know Your Customer), KYB (Know Your Business), and KYT (Know Your Transaction) mechanisms, precisely because they’re trying to weed out the hacker/terrorist/drug lord crowds. Why would they then partner with a DeFi protocol, where every blockchain address can be a potential financial criminal, or enemy of the state?
We don’t want you around here
Introducing our compliance partner
At Kima Network we made the decision to add a Compliance Module to support clients who require compliant transactions. Each Kima Network transaction is made of 2 addresses, on 2 disparate blockchains. Both addresses are sent to our compliance & security partner, Xplorisk, for evaluation.
That evaluation includes review of statically-known addresses (e.g. OFAC lists, or lists of previously known hackers), dynamic forensic research, behavior analysis, and magic that is the IP of Xplorisk.
In the end, we get a break down of what the address is: is it an EOA? A smart contract? A mixer? An exchange address? What was the address involved with prior to using Kima? And most importantly, a risk score.
Kima can then decide to reject transactions with a high risk score, or with a behavior pattern that does not match our compliance posture.
Back to our KyberSwap hacker…
When the hacker started bridging their stolen funds to Ethereum, I asked one of my developers to send a query to our Xplorisk endpoint, and see what we’d get if that hacker tried using Kima as their bridge. We knew some of the addresses and blockchains the hacker used from several articles.
We sent this request:
{
"addresses": [
"0xc9b826bad20872eb29f9b1d8af4befe8460b50c6",
"0x50275e0b7261559ce1644014d4b78d4aa63be836",
"0x4ea83653ecea38b51730c14776698e19f5ca6e65",
"0xd3a7e3c5602f8a66b58dc17ce33f739efac33da2",
"0x441e36344706ee49ae0402727b07670fad2d2e49"
]
}
And received this response:
[
{
"name": "Kyberswap Exploiter",
"contract": "False",
"classification": [
"hacker"
],
"risk_factors": [],
"risk_score": "high",
"address": "0xc9b826bad20872eb29f9b1d8af4befe8460b50c6"
},
{
"name": "Kyberswap Exploiter",
"contract": "False",
"classification": [
"hacker"
],
"risk_factors": [
"hre_in"
],
"risk_score": "high",
"address": "0x50275e0b7261559ce1644014d4b78d4aa63be836"
},
{
"name": "Kyberswap Exploiter",
"contract": "False",
"classification": [
"hacker"
],
"risk_factors": [
"mixer_out"
],
"risk_score": "high",
"address": "0x4ea83653ecea38b51730c14776698e19f5ca6e65"
},
{
"name": "Kyberswap Exploiter",
"contract": "False",
"classification": [
"hacker"
],
"risk_factors": [],
"risk_score": "high",
"address": "0xd3a7e3c5602f8a66b58dc17ce33f739efac33da2"
},
{
"name": "Kyberswap Exploiter",
"contract": "False",
"classification": [
"hacker"
],
"risk_factors": [],
"risk_score": "high",
"address": "0x441e36344706ee49ae0402727b07670fad2d2e49"
}
]
Had the user attempted to use bridges that leverage Kima Network to bridge their funds, they’d have been rejected at both the SDK level, and the RPC level, as every one of our validators can use our CM.
But wait! Are you censoring people?
People who’ve been following me over the years know that I’m bullish on privacy, and abhor censorship. I also think ultimately censorship doesn’t work - look at the case of TornadoCash for example.
Kima Network serves a variety of entities: from 100% open dApps, to the most compliant financial institutions, banks, card issuers.
Developers can choose to use the CM for certain transaction types, or for all of them, depending on the jurisdiction, the type of funds, the transaction size, and many other factors.
In the end, we’ll ensure compliance where and when needed, and allow developers to choose a less-compliant route when they need it less.
Final words
We’ve discussed Kima’s Compliance Module, why it’s needed, and how it differentiates us from other bridges. We saw how the CM works through a sample use case. We’ve learned that compliance is desired in certain circumstances, but may be a burden in others, and how Kima navigates the demands of the market.
I truly believe that as crypto gains more momentum, and a wider audience, the call for compliance will grow louder. And that’s why I’m sure Kima Network is a ahead of the pack on this front (in addition to the other security features we discussed earlier).
I’d like to thank Snir from Xplorisk, who is not just our compliance partner, but also one of Kima’s security advisers.
Next post: things I saw at ETHDenver 2024.
Amazing