One of the keys to understanding the strength of Kadena is to understand how transactions are made. Let’s dive into it.

This is not a technical article. We won’t go into details. This article is intended for all readers, from devs to simple users. I encourage everyone to read this article until the end.

Note that, unlike EVM transactions, there is no obscure binary data (call data). Everything is plain, human-readable documents.

The payload

The payload is the core of a transaction. The payload is a sealed JSON document containing several sections.

MetaData

This section contains several fields required to handle the transaction properly (chain, build date, time-to-live, gas settings, …).

One of the most important fields is sender. This concept is different from the EVM sender (btw, there are various proposals to revamp it). Here, the sender is the account that wants to pay for gas. It can be the main user himself, or a third party, a gas station, …

Code

This is the central part of the transaction… The “Pact” code…

Did you know that every transaction is always a piece of executed code?

Even a simple KDA transfer is code calling the KDA (coin) contract.

But no worries… The code is not complex JS or Rust code understandable only by developer-trained brains.

The code is Pact. And good news: most of the time it’s relatively short and easy to understand, even for normal people. For example:

(coin.transfer “bob” “alice” 3.0)

This calls the transfer function of the coin contract (KDA) to transfer 3.0 KDA from “bob” to “alice”.

Of course, a single transaction can do several things and call several contracts or functions.

Data

This is an optional section. It allows attaching a JSON document to the transaction containing data. This data will then be handled by the Pact code. This helps maintain a better and cleaner separation between code and data…

Unlike an EVM transaction, where everything is mixed together and binary encoded.

Signers

The signers section is probably the most important part of the payload. It contains the list of public keys that signed the transaction.

Did you know that multi-signing is naturally handled by Kadena? Not a hack like in EVM transactions.

But it becomes even more interesting when you see that each public key is associated with a capability. In plain English, we could call them roles. In short, each signer (user) can scope their signature to a list of allowed usages.

In the context of blockchain, this is very valuable. Usually, looking at the signers section is enough to understand what the transaction is doing…

And before signing, a user, even if they don’t understand the code, is able to know exactly what they are signing for. No blind signing, no blank checks with Kadena.

(You can refer to this article: https://medium.com/@crypto-pac/kadena-and-pact-in-regard-to-the-bybit-hack-6b6e93c1ee65?sharedUserId=crypto-pac)

The transaction

Before being submitted to a node, the payload must be packaged into a full transaction: a new higher-level JSON document.

Payload

The payload itself

Hash

This is the hash of the payload. In fact, this is the technical way to seal the payload, make it immutable, and guarantee that the accompanying data is related to this payload.

Signatures

While the payload contains the list of public keys (and associated capabilities), this section contains the digital signatures themselves (exactly one per signer). The network will verify that the signatures match the original sealed payload.

Proof and Verifiers

These sections are used only for special cases (cross-chain Pacts, Hyperlane).

Agent to Agent AI

After the recent AI boom, many actors are now looking ahead and trying to anticipate the next step.
Several major players, such as Google, are moving toward Agent-to-Agent (A2A) AI. The idea behind this concept is to provide more advanced services by allowing AI agents to cooperate and to offer (and charge for) services to one another.

However, AI agents will eventually need a registry where they can expose to the rest of the world:

• Their capabilities
• - Their reputation-
• Third-party verification
• …

Why blockchains ?

Because, ideally, these registries should be decentralized:

• Avoid a single operator (censorship, reliability issues, single point of failure)
• Trustless (verifiable, immutable, no need to trust a single party)
  Open interoperability
• Political and economic resilience (avoid regulatory and multi-jurisdictional issues, manipulation as a consequence of electronic warfare, …)

This is why Ethereum has proposed a new standard: ERC-8004: Trustless Agents.

Why not Ethereum ?

Many believe that in the future, the A2A AI market could skyrocket, leading to thousands — perhaps millions — of transactions.

Even though Vitalik Buterin recently announced continued work to further improve Ethereum’s scalability, at some point it may not be sufficient…

Remember what happened during the NFT frenzy in 2021. People were constantly complaining that DeFi had become unusable, as a simple token swap could sometimes cost more than $100 in gas fees.

Even if Ethereum were to double or triple its throughput, a future A2A AI frenzy could be a hundred times more intense than the NFT boom.

Why not Base, or other L2s?

“Base is the solution… for everything related to crypto…” — lol — that’s what I’ve been reading every day for the past few months.

But perhaps some overlook what Base actually is. It is fully centralized: everything goes through the sequencer operated by Coinbase. That is precisely the opposite of the requirements for a universal A2A registry.

Other L2s are not much better. Vitalik Buterin recently pointed out that no L2 has yet achieved true decentralization.

Why Kadena ?

Kadena, using its X-chain architecture, is fully decentralized, and its scalability model aligns particularly well with AI requirements. Let me explain.

Horizontal scalability

Many have pointed out that Kadena’s multi-chain design is not ideally suited for multi-chain DApps (for example, sharing liquidity is not very straightforward). That’s true. But Kadena’s greatest strength lies in horizontal scalability.

• In practice, this means orthogonal DApps can run independently without interfering with one another, each living on its own chain.
• At the same time, the braided chain design ensures that all chains are secured by the same PoW hash power. The strongest chains protect the weakest. In short, performing a 51% attack on a single chain would effectively require attacking the entire network.

In the context of A2A AI — with potentially hundreds of transactions per second — it makes a lot of sense to dedicate an AI “side-chain,” secured by the PoW of the entire network, without disturbing other applications.

Multi-Chain registries

I mentioned hundreds of transactions per second — but what happens in the case of thousands, or tens of thousands? The answer is simple: add new AI chains.

By nature, A2A AI interactions can be split across multiple databases. As such, they can scale on Kadena while preserving global security properties.

Multi-Chain registries — with a scalable payment layer

While the Ethereum standard is very lightweight and only handles minimal use cases, a Kadena-based standard could include many more features, supported by Pact.

One such feature could be a scalable payment layer. Since payment for a completed AI job does not require strict real-time settlement, it would make sense to use Pact proofs to process payments on general-purpose chains with liquidity. This would limit the need to maintain liquidity on AI-dedicated chains.

And now, what are the next steps?

Have you looked at the ERC-8004 standard? It’s quite minimal. I believe that with relatively little effort, it could be significantly enhanced on Kadena (including a connected orthogonal payment layer, on-chain JSON storage, …).

• The key is to clearly identify industry needs and determine how Pact can address them.
• And define a sustainable business model for AI on Kadena, ensuring it benefits miners and token holders alike.
• Who wants to take up the challenge ?

This article is aimed at beginners. It presents the Kadena blockchain architecture from a user’s point of view. In my opinion, understanding it is not only necessary for all Kadena developers but also for regular users.

From my experience, too many people don’t fully understand what Pact Namespaces, Keysets, Modules, etc., mean in the context of Kadena. Even though, it’s relatively simple.

While EVM-based blockchains provide raw addressing spaces where you can only store words at a given address, Kadena, being a high-level and user-oriented blockchain, offers a more sophisticated architecture.

Note to readers: To keep this article accessible, I have intentionally omitted most technical details.

Who said multi-chains ?

Let’s start from the beginning: Kadena is a multi-chain blockchain.

In short, this means that multiple chains run concurrently, each with its own set of data.

Although short messages (proofs) can be exchanged between chains, their data remain mostly independent. Each chain has its own life.

How is single chain organized?

Each chain is based on a “file-system like” architecture, as shown below:

Namespaces

Namespaces can be seen as folders with “write-access restrictions” where you can store various data.

Depending on the access rules, namespaces can be classified as follows:

• Public namespaces (e.g., free, user) → Everyone can write to them. Using theses is not recommended.
• Kadena team-owned namespaces (e.g., kip, util, …) → The Kadena team has restricted access using their own keys.
• Privately owned namespaces, usually in the form of n_xxxxxxxxxx → These are called "principal namespaces." Anyone or any project can create their own and store data in them.

Note about the root namespace: Writing in the root namespace is always forbidden. Only essential modules required for bootstrapping and the proper functioning of the chain are located here. Among them: the coin module (i.e., KDA token, necessary for paying gas), the ns module (necessary for managing namespaces).

What can contain a namespace ?

• Named keysets
• Modules

So let’s go deeper…

Named (defined) Keysets

What is Keyset in Kadena?

• A keyset is a single public key
• Or a set of several keys with associated rules for multi-sigs purpose.

And a named keyset ?

Kadena allows you to register / publish / write a keyset with a user-friendly name in a namespace where you have write permission.

Then you can refer to it in later time for use in module code, guards, account management using its Fully Qualified Name: __namespace__.__keyset-name__ .

For example, the Brothers community keyset is: "n_582fed11af00dc626812cd7890bb88e72067f28c.community"

Even if this feature is not mandatory, it’s a nice and convenient to have this kind of mechanism embedded directly in the blockchain.

Modules

A module is a piece of code. This is what we call the Smart Contract itself.

The code is written using Pact, the language of the blockchain.. Without entering into the details, the code describes all operations and rules of the Smart Contract. A module can refer to others modules, or keysets.

How does a module store data ?

Unlike EVM blockchains where contracts store their data in a giant addressing space (like an unformatted hard disk), and requires a compiler to make things a little easier, a Pact module stores their data in an organized way: tables.

Tables

In Kadena and Pact, tables are a kind of “document oriented” databases, and are owned by a module. A module can own zero, one or several tables.

Tables are private, and it’s the job of the module code to define and bound read / write access and the associated conditions.

What contain tables ?

Tables contains structured data, similar to JSON documents.

Each document is called a Record and is referenced by a unique key.
Like JSON documents, Records can contain sub-objects, arrays , ….

It’s the role of the module to define records structure, create, update and read them..

And now, what more ?

Nothing…

You now know all the concept to explore, use, and work with Kadena.

After taking over the chain with a small team, we spent several weeks conducting a thorough review of Kadena: its past achievements, its current state, and its future prospects.

Kadena in October 2025

From a Financial perspective

Since Kadena LLC’s business was conducted on-chain, tracking the money is straightforward. One only needs the LLC’s Ethereum addresses and to follow USDC/T redemptions (addresses and transaction IDs can be provided on request).

USD redemptions by Kadena LLC show that over the previous two years, Kadena LLC withdrew more than $32 million from KDA emission sales alone. This figure does not include USD loans or fees paid to market makers.

With the current community-led team, we estimate that the cost to keep the chain running is between $300k and $1M per year. Based on the revenue generated during those two years, Kadena could have been funded for at least 30 years.

In short: the chain was financially sustainable. Without any doubt.

(Note: the situation is now very different, as the token price has collapsed from $0.30–0.40 to around $0.01. At that price, selling emissions via platforms makes no sense.)

From a Technical perspective

Over the past weeks, I spent countless hours diving into the codebase, both in Haskell and JavaScript.

The result is clear: the codebase is massive, representing thousands — if not millions — of hours of work. More importantly, it is high quality, with remarkably low technical debt. Anyone familiar with large-scale software development knows how rare this is.

Both the Haskell and JavaScript components were built with reliability in mind, using state-of-the-art development practices.

This is a testament to the skill of the Kadena developers.

And we all know it: Kadena’s technology remains excellent, and in several areas it is still ahead of most competitors.

The documentation is also relatively clean and well maintained (thanks in particular to Carl and Lisa)

From a human perspective

Kadena had an outstanding development team: skilled, committed, and deeply invested in the project.

Albert, Chessai, Doug, Edmund, Emily, Javad, Jose, Lars, Robert…

(I’ll add: if any of you want to join the community initiative, you are more than welcome.)

I know each of them personally or through their GitHub contributions. Building such a team was one of Kadena’s greatest achievements — and then firing everyone is simply incomprehensible.

From an Eco-system perspective

The ecosystem has always been Kadena’s weak point.

Yet recently, things were finally moving in the right direction:
Kinesis Bridge, Bro Finance, SushiSwap, and more.

Momentum was building.

So what happened

The management team — namely Will Marino, Stuart Popejoy, and Anastasia Bez (personal wallets addresses provided on request)

managed to destroy in 24 hours what took years to build:

• They pushed exchanges to delist KDA.
• They instructed the Kinesis operator to shut down the bridge, freezing more than $60k of user assets, while ordering the operator not to reveal the keys or the source code.
• They did everything possible to obstruct any takeover or recovery effort.

Given everything described above, their decision to abandon the project is, frankly, baffling.

And now

Until early December, I remained in contact with the three managers, attempting to secure for the new Kadena Foundation:

• A way to bring the bridge back online (source code and private keys).
• A way to recover part of the Kadena treasury on Ethereum and Kadena.

According to blockchain explorers (addresses available on request), the on-chain treasury amounts to approximately:

• $1.46M in USDC/T and kB-USDC
• 1.63M KDA

Most of these funds were refunded by market makers — and therefore belong to the chain and to KDA holders.

Since early December, however, there has been radio silence. Emails go unanswered. Telegram DMs are ignored.

Meanwhile:

• Market makers are waiting for funds to restart operations.
• Users are waiting for their assets to be released from the bridge.
• The ecosystem is waiting for the Kinesis bridge to be revived.
• Core development and infrastructure urgently need funding.

Are You Kidding?

After all the money you made, you are willing to let the chain die ?

Do you truly not care about holders, users, and the dedicated people who are still trying — against all odds — to keep Kadena alive ?

Until now, DIA (diadata.org) was providing price information to the chain through an Oracle contract.

There was a commercial agreement between DIA and Kadena LLC: probably for a lot of money. Now DIA halted. As such, some Wallets and Dapps got broken. Maybe some notice that Linx balance in USD wasn’t updated correctly.

What is KIA ?

From Smart contract Point of view, KIA is inspired by former DIA Smart Contract…

The Smart contract can be accessed:

• n_40c883decc192e1e3214898f04656b2e9ea7b74e.kia-oracle

With an API similar to DIA:

(kia-oracle get-value symbol:string) -> decimal

Then the Smart contract is fed by newly developed a Python script.

Important note: The reliability and accuracy is not guaranteed. KIA should be only used for information purpose.

What data are available ?

After launch, the following data will be supported:

But in the future, many other data source could be added, depending on needs and requests. Feel free to submit an Issue on GitHub.

When ?

Right now. KIA is already working.

• https://github.com/kda-community/kadena-info-access

Usually, I only speak only about tech, but for once, let’s talk with my heart.

When we decided to fork, we estimated our success chances to 0.1% –5 %. We were supposed to break everything.

But unexpectedly, it worked… After things calmed down, and after going through every emotional state and moods over the last three weeks, I’m starting to understand how and why we made it …

Thank you

• Thank you to the core team… Especially Edmund, this guy is incredible ! We just start to build together.
• Thank you to Dan Keller and the Flux team, who did and continue to provide a great help. Flux and Kadena are together building the future.
• Thank you to Amir, and Jumbo, my two partners-in-crime since a long time.
• Thank you to mining pools: PoolFlare and F2Pool
• Thank you to the solo-miners who lend us their Hashrate
• Thank you centralized exchanges: CoinMetro, Gate, and CoinEx. They never stopped to support us.
• Thanks to all Dapps, that continued to operate in the storm, Mercatus, KdSwap, Bro-DEX, etc …
• Thank you to the wallet who supported us: EckoWallet and Linx.
• Thank you to the close community of Brothers, for continuous support and all provided help.. Some of them will probably take part of future team, and foundation.
• Thank you to all the Kadena community.. You are awesome. I received so much support. Without it, I would have given up.

Thank you to my family. My daughter and my wife (she didn’t ask for divorce)… And thank you to the all others community member’s family.

If the fork project is successful, this is because all those people never failed, and always gave support, like a continuous chain.

I would like to honor those who are no longer with us: Yusuf and Julia. We did that for you too.

Not Thank you

Not thank you to all the haters, who threats to sue the future foundation, and made complaints to exchanges and X just for the pleasure to make it fail.

Not thank you to actors who abandoned ship like rats. I hope you enjoy the blood-stained money from Kadena LLC (note you have the right of reply in comments) :

• Hackachain who closed the explorer service invoking high running costs (while an individual of the community restored it for 40$ / month)
• SushiSwap, who just closed their Kadena services… for an unknown reason
• 4PtO, who closed the Kinesis bridge, without announcement (locking more than 60 k$ of funds belonging to users)

And now ?

Everything settled down, network is stabilized, price is starting to recover (showing the trust of the community).

The foundation will be created and announced in the following days. We need to start to create a strong team. Everybody is welcome. All help will be appreciated.

Of course, all investors, and possible private funding opportunities are welcome too.

A new part of Kadena story just started for freedom, community, business, and more ..

PoW with Bitcoin => Decentralization doesn’t work

The first chain to use Proof of Work for minting blocks was Bitcoin. The idea behind PoW was to decentralize the mining process and to have dozens or even hundreds of miners who would “collectively secure the network.”

What is the situation on BTC today? For small miners (and even many large ones), it’s almost impossible. A miner has to pay their electricity bill and needs a constant and predictable income. The variance is too high No miner wants to play the lottery and hope they might mine a single block over the course of a year.

That’s why, given the low number of blocks per day (144), it is almost impossible for many miners to participate without joining a mining pool.

And the consequence is clear: three mining pools control more than 50% of the Hashrate — and thus the network. How can that be called decentralization?

PoW with Kadena => Is it better ?

With 57,600 blocks per day, the situation should be much better. A solo miner with only 0.1% of the hashrate could expect to mine around 58 blocks per day on average — a steady income with limited variance. Solo-mining is definitively doable on Kadena for most.

Most miners should therefore avoid mining pools and everything that comes with them:

• Fees
• Lack of transparency

But surprisingly, this is not what we observe. Most miners (if not all) still use mining pools… And there are only four pools mining KDA, with two of them having already announced that they are leaving the chain. As a result, Kadena’s hashrate is even more centralized than Bitcoin’s.

The Kadena network is effectively in the hands of no more than one or two people. This is a major issue !— and it becomes even more serious considering that, with the new on-chain voting system, miners will soon have significant decision-making power.

What the reasons, and what could we do ?

What’s wrong with Kadena?
Yes, I know — using a mining pool is convenient. It’s plug-and-play. For small miners, it can be justified, and in that case mining pools make sense.

But for large miners? I recently met people who had 5–10 PH/s of hardware and were still using a mining pool! And when I asked why, they answered that nobody ever told them how to mine on their own.

For some strange reason, over the past 2–3 years, the old LLC team did not encourage people to mine independently:

• No promotion of the compacting system, which reduces a node’s SSD requirements by a factor of 10.
• No promotion of the self-mining tool (chainweb-mining-client). The binary isn’t even provided, meaning you need at least some familiarity with the Haskell ecosystem to get it running.
• No documentation or tutorials explaining how to set up a mining node.
• And no encouragement for self-mining at all — seriously, WTF?

With the right documentation, setting up a mining node isn’t very complicated if you have basic Linux skills, and it carries no security drawbacks. Even a small mini-PC — the kind you can buy for $100 (plus Trump’s tariff for our friends in the US) — can do the job.

So what should we do with the new community fork?

• Provide clear, with public exposure, beginner-friendly documentation (“explain it to me like I’m 5”) for setting up a self-mining node.
• Provide a free, well-supported service offering pre-compacted chain snapshots for download.
• Provide a pinned, easy-to-find, pre-compiled (and possibly Dockerized) version of chainweb-mining-client.

My objective would be to reach at least 50% of Solo-Mining … At this point, we could definitively call Kadena is decentralized chain.

Introduction

In the first part of this article, the concept of Bro-DEX was introduced, and readers are encouraged to read it.

Here, I will show how Pact and well-chosen data structures allowed us to successfully address the challenge of scalability. Then, we will move from theory to practice by examining and explaining a real Bro-DEX transaction.

https://dex.bro.pink

Scalability and lists management

A DEX should be able to handle millions of transactions, and the order book should support thousands of simultaneous live orders. Scalability is not just a performance concern; it is also a security issue. A non-scalable contract is vulnerable to Denial-of-Service (DoS) attacks.

Most EVM-based smart contracts and Kadena contracts require some form of backend or indexer for auxiliary functions like transaction history.

However, as we believe in fully decentralized and 100% available contracts, we implemented a fully on-chain architecture in Pact to achieve our scalability goals. Using multi-row Pact commands or storing data in Pact arrays being strictly avoided.

To meet the required functionality, the smart contract must manage several lists:

• Order books (bids and asks): Active orders.
• Global and per-user swap history.
• Per-user active orders.

History lists

The two history lists are the easiest to handle because they:

• Elements are never removed.
• Require only push (append) insertions and are sorted in chronological order.
• Can be retrieved in parts, as users generally need only the most recent entries.

For these reasons, we implemented them using a linked list. They are relatively easy to manage in Pact, as traversing the list can be efficiently done using the built-in (fold) and (read) functions.

“Per user” active orders lists

This data is essential, as it allows users to clearly track their current positions and locked funds. It has the following properties:

• Read/Write: Quick removal (e.g., when canceling an order) must be supported.
• Push-only insertions (from the top).

The requirement for quick removals led us to adopt a double-linked list. Similar to basic linked lists, Pact allows us to implement them seamlessly.

The Order books lists

This is the most complex part. An order book stores active orders on the DEX and must meet these requirements:

• Read/Write (Insertion & Removal).
• Maintain ordering.

The ordering property is critical because a taker must be able to quickly find the cheapest available order at mining time.

— The Double Linked list solution

Some well-known Ethereum smart contracts solve this issue by combining:

1. Double-linked lists.
2. Off-chain pre-calculation.
3. A transaction “hint” to guide the insertion.
4. Final verification at mining time.

While this approach works and is relatively easy to implement, it has major drawbacks:

• Requires a “smart frontend,” introducing scalability risks.
• Prevents direct contract-to-contract calls (e.g., aggregators).
• Opens the door to DoS attacks, including sandwich attacks.

— The Self-balancing Binary Search Tree solution

To overcome the limitations of the linked list approach, we opted for a standard, well-known solution used in DBMSs and filesystems:
A self-balancing binary search tree (BST) provides log(N) complexity for insertions and removals in an ordered list.

https://en.wikipedia.org/wiki/Self-balancing_binary_search_tree

After experimentation, we found that a Red-Black Tree was the best choice. The challenge was to implement it in Pact:

• The algorithm itself is complex, and even the sharpest students may struggle to implement it.
• However, Pact’s LISP-like functional paradigm makes things easier.
• But since Pact does not support recursion, making tree-based algorithms work can be tricky.
• Pact being non Turing complete, some adaptations are required, like strictly limiting the tree depth.

Finally, we achieved an optimized Red-Black Tree implementation, with relatively good gas efficiency (thanks to Pact 5). Extensive testing was conducted using a Monte Carlo and white-box testing approach, giving us high confidence in the implementation’s safety and correctness.

GH repos: https://github.com/CryptoPascal31/pact_RB_tree/

An example: Anatomy of a real GTC transaction

A Bro-DEX transaction may initially seem complicated, with potentially many transfers and atomic actions.

When it comes to transparency, any user should be able to decode and verify that a transaction worked as intended.

That’s why I propose to decode an example transaction, helping people better understand how it works. We will mainly focus on what matters for most users: funds transfer events.

Note: Amounts have been rounded to improve readability.

Transaction: https://explorer.chainweb.com/testnet/txdetail/udlPBTJ7VNhT7Olsjqg4p3XH2MdVIGjbjSxXJWR5dwc

For this example, the user wanted to buy 0.1 $BRO at a max price of 99.0 KDA / $BRO (GTC). On the orderbook, 2 previously posted orders could match its request:

• One at 0.982 KDA / $BRO for 0.01 $BRO
• One at 0.983 KDA / $BRO for 0.01 $BRO

Step 1: The user calls the wrapper module and transfers the worst case amount to the wrapper, including worst case fee of 0.1% (0.1 * 99 ) * 1.001 = 99.099 $KDA

The wrapper contract decides to take the two available orders.

Step 2: The wrapper module calls the core module to take order A (id 182…67) at 0.982KDA /$BRO. It transfers the amount + Fees (0.01 * 982) * 1.001 = 0.983 KDA

Steps 3 / 4 : The core module pays the maker, and the fees

Step 5: The core module pays the amount of the order: 0.1 $BRO to the user.

Step 6: The wrapper module calls the core module to take order A (id 409…07) at 0.983KDA /$BRO. It transfers the amount + Fees (0.01 * 983) * 1.001 = 0.984 KDA

Steps 7 / 8: The core module pays the maker, and the fees

Step 9: The core module pays the amount of the order: 0.1 $BRO to the user.

No orders are available on the shelf. The wrapper contract decides to post Bid order on the orderbook.

Step 10: The wrapper module calls the core-module to create an order (id 252…92). It transfers the amount in KDA without fee 0.99 * 0.8 = 7.92 KDA. The order is now ready to be taken by a seller at a later time.

Step 11: For 2 reasons, money have been saved:

• 0.2 $BRO have been bought at a lower price than expected
• an order of 0.8 $BRO has been published as a maker with 0 fee.

As a consequence, the wrapper module refunds 0.023 KDA to the user in the same transactions.

Conclusion

This article and Bro-DEX demonstrate that valuable and scalable smart contracts can be brought to Kadena.

While being strongly smart contract-oriented, Pact is versatile enough to enable the creation of distinctive and outstanding dApps. By carefully designing the architecture and data structures, writing clean, concise, and secure contracts becomes relatively straightforward… Especially in contrast to the EVM/Solidity nightmare…

So let’s trade on Bro-DeX !

What is Bro-DEX ?

Brother’s DAO has always aimed to innovate and showcase how Kadena and its smart contract language, Pact, are ideal for developing high-quality smart contracts.

The goal of Bro-DEX is to bring all the features of a traditional order book-based exchange (like those found on most CEXs) fully on-chain — 100% decentralized — while prioritizing scalability, security, and transparency.

Another key objective is to make the smart contract autonomous, ensuring that:

• It can be easily integrated with any “thin” frontend without requiring special off-chain processing.
• It can be seamlessly called by other on-chain contracts (e.g., on-chain aggregators, etc.).

Bro-DEX is organized into trading pairs.
For each pair, you can:

1. Publish orders at a given price (for buying or selling).
2. Take published orders.
3. Cancel orders.
4. At any moment, view an overview of the pair’s state, including:

• The order book.
• Past orders (per account and per pair).
• Active orders per account.

5. Use common limit trading strategies:

• GTC (Good ’Til Canceled) → Executes all available “on-the-shelf” orders at a better price than your limit, then places any remaining amount as a new order.
• IOC (Immediate Or Cancel) → Executes all available “on-the-shelf” orders at a better price than your limit. Any unfilled portion is canceled.
• FOK (Fill or Kill) → Executes all available “on-the-shelf” orders at a better price than your limit. If the order can’t be fully executed, it is canceled entirely.
• Post-Only → Only places the order on the order book without executing it immediately.

To incentive market makers, the fees are:

• 0 % for makers
• 0.1% for takers

The initial frontend is designed to be clear and uncluttered. Note that Bro-DEX is currently in a final phase on Testnet, and will be released very soon on Mainnet as a part of the BRO ecosystem: https://dex.bro.pink

Let’s see how Pact allows us to bring this to reality, and how we overcame the challenge.

Global architecture

Each trading pair consists of three distinct modules, each playing a specific role in ensuring the system’s security.

The core module

This is the main module — and the only one — that guarantees the security, integrity, and consistency of the pair’s order book. All critical but fundamental actions are centralized here. The idea is to exclude all “helpers” (i.e., non-critical) features from this module.

The wrapper module

Its purpose is to convert high-level actions, such as “Buy X tokens at price Y with a GTC scheme,” into low-level calls to the core module (e.g., take order A, then order C, then order D, then create a new order in the order book).

Beyond that, it protects the user by ensuring that the best possible choices are made at execution time, mitigating risks of inconsistency (or last-second changes) between the frontend and the actual contract state.

Examples:

• Ensuring that the cheapest order is taken first.
• Preventing the creation of a new order when a cheaper order already exists.

The viewer module

A read-only module designed to facilitate easier access to the core module’s internal data. Its purpose is to be used by the frontend to retrieve data solely through local calls.

Security and bugs mitigation

Bro-DEX has been built with a strong focus on security, or at the very least, to mitigate the consequences of potential bugs.

Pairs segregation

While Pact provides the powerful “modrefs” feature and dynamic calls, we believe that modrefs are one of the main sources of bugs. That’s why, following an approach similar to Uniswap, each trading pair is implemented as a separate set of modules. This significantly reduces the attack surface by preventing any possibility of cross-pair re-entrancy attacks.

As a tradeoff, this makes pair creation and deployment more cumbersome — but it is well worth it.

Pair architecture

As presented in the architecture chapter, each pair is split into three contracts. This separation is driven by security requirements, with each contract having a specific responsibility:

• Core: Ensures the security of the pair, orders, and funds.
• Wrapper: Ensures user security by mitigating most MEV attacks and other exploits based on chain/frontend inconsistencies.
• Viewer: Read-only module — no security implications.

This design allows for a more efficient code review.

Orders segregation, and funds management

Pact, as a modern smart contract language, is not constrained by the outdated “one contract = one account” paradigm of EVM-based systems. Instead of having a single large bank account for a pair, each order has its own separate account, completely isolated from other orders within the same pair.

This design makes it significantly harder to launch attacks targeting the entire pair.

Technically, accounts are managed using capability guards (Caps Guards), a feature of Pact that provides fine-grained control over when, where, and how funds can be accessed.

To mitigate the impact of potential bugs, the code responsible for fund management is minimal and isolated within a small, well-defined section of the Core contract. This makes it highly unlikely that an attacker could separate order execution from payment.

Code cleanless and simplicity

Pact is a very expressive and high level language.

Even a relatively complex contract like Bro-DEX ends up in a very concise code (if correctly written), very easy to maintain, review and audit.

• Core module: 400 lines of code (1/3 being comments)
• Wrapper module: 200 lines of code (1/3 being comments)

Conclusion

In this article, after a brief introduction to Bro-DEX, we have seen that Pact is an ideal language for developing complex smart contracts and feature-rich DApps.

When properly used and combined with a well-designed architecture, Pact allows us to write smart contracts with a high level of security confidence, reducing the absolute necessity of costly audits.

In the next article, we will explore Bro-DEX’s scalability challenges in greater detail and analyze a sample transaction to demonstrate what really happens on-chain during contract execution.

Last month, Bybit cold wallet was hacked and more than 1B$ in ETH were drained from their wallet. But could this have happened on Kadena too ?

What happened with Bybit

You can find a lot of information about the hack on X or various websites.
But basically, the only thing to remember is that the Bybit team did everything right and the smart contracts did not exhibit any vulnerabilities. The hack was very difficult (if not impossible) to prevent…

It’s simply due to how the Ethereum EVM works — it is inherently unsafe or, at the very least, not well adapted to modern crypto threats.

Some facts:

• The EVM does not natively support multi-signature (MultiSig) accounts. Natively: An account === 1 single key. A basic transaction includes only a single signature (corresponding to the sender account).
• The most usual way to have a MultiSig account is to deploy Gnosis’s smart contracts at the MultiSig account address. The Gnosis smart contract is a very complex piece of code, though thoroughly audited.
• To use these complex smart contracts, it is almost mandatory to rely on the official frontend.
• When using the frontend, users perform “blind signing” — they do not know exactly what they are signing. This is very often the case when interacting with EVM smart contracts because, for non-technical users, EVM calls within transactions are extremely difficult to decode. This is even more true when dealing with ecRecover signatures. [1]

What happened with Bybit?

The frontend was hacked (which is typically less monitored and less secured than smart contracts or private keys), and Bybit’s CEO had no way of knowing that he was signing a malicious transaction.

The key takeaway for security

What truly matters is the transparency provided by the wallet (whether software or hardware) when the user presses the “Sign” button. User should be confident on what he approves or doesn’t approve.

And on Kadena ? Multi-sigs …

Pact, the smart contract language of Kadena, natively supports multi-signature (MultiSig) guards — at least the most basic (but also the most useful) ones: N-out-of-M signature schemes.
(Note: This can be extended to more complex schemes using Pact user guards.)

This means there is no need for complex smart contracts — everything is managed by the blockchain in a clean and transparent way.

MultiSig guards can be used to protect token balances, but also for many other purposes, such as smart contract governance…

Example of simple multi-sig account managed by Pact: The account w:7xw… is a 2 over 3 MultiSig account. At least 2 signatures (pred=keys-2) are required to unlock the funds.

And on Kadena, Capabilities …

But most importantly, on Kadena, each signature in a transaction is scoped and restricted.

In short, a transaction contains not only a smart contract call but also a list of capabilities attached to each signature, specifying exactly how the blockchain is allowed to use that signature during transaction execution. All other uses are prohibited.

In particular, a specific capability exists for each fungible contract called (TRANSFER …). This capability must be explicitly validated by the user before signing. Otherwise, the fungible contract refuses to debit an account, regardless of the context.

The advantage of this mechanism is that it represents a complex smart contract call as a set of explicit and simple authorized actions that can be clearly presented to the user.

In contrast to EVM transactions, Kadena Pact’s transactions are highly flexible and limpid. A single transaction can have multiple signatures (and signers), each with its own capabilities validated individually by each signer.

Transaction example (involving the multi-sig wallet above) [2]:

• Explicitly, user “980…cf” agreed (= signed for) to send 18 KDA from the multi-sig wallet
• Explicitly, user “a2d…a3” agreed (= signed for) to send 18 KDA from the multi-sig account and to pay gas from his own personal account.

Conclusion

In this specific case, the Ethereum EVM doesn’t provide the right features to hold safely and correctly funds (lack of native multi-sig, opacity of binary Smart contracts API, Blind signing …). Even with extreme care, proficient people can be fooled.

Only some next-generation smart contract languages, like Pact, offer the necessary features to handle such cases safely, transparently, and natively. The real challenge is how to create good UX that allow to use them efficiently.

And now, how to improve and leverage this, how to make it even more secure ?

To improve transparency and avoid as much as possible mistakes and/or fool playing by bad actors, here are some suggestions.

For wallets UX:

• Clearly show what capabilities are attached to the signature before signing. And if possible, show them in a human-readable format.
• Discourage unrestricted signatures [3], by showing big Warnings in this case.
• Create some good UX to manage easily and in a friendly way Multi-Sigs accounts.

For Kadena and Pact core devs :

• Implement Magic Caps [4], and progressively discourage and deprecate Unrestricted signatures
• For a better information for users, implement a new version of Cap-Guards and User-Guards with a clear and readable principal. [5]

For Smart Contracts devs:

• Try to always enclose all signature enforcements in clear and transparent capabilities, giving confidence for users and wallet.

Notes:

[1] Safe (Gnosis) after the hack provided some guidelines to check transactions data. : https://help.safe.global/en/articles/276343-how-to-perform-basic-transactions-checks-on-safe-wallet . Notice how the Step 2 is error prone as an invisible mistake (eg: Operation=1 instead of 0 for Bybit case) can lead to a complete wallet compromission.

[2] https://explorer.chainweb.com/testnet/txdetail/EuC_mq8CjDN6PIMzjGOOI547GaechZCkH575gM4NfdA

[3] Kadena allows unrestricted signature. I don’t like them, because they are dangerous. Anyway, well programmed fungible Smart Contracts (including the coin contact) don’t allow unrestricted signature (through the mechanism of managed caps).

[4] This smart PR was proposed by Stu but never got merged. https://github.com/kadena-io/pact/pull/1302

[5] I discussed many times with the Kadena team (especially with Emily), without succeeding to convince :-) … But In my point of view, this should be reconsidered.