# What is Chrysalis?

The objective of the IOTA Foundation was to optimize the IOTA mainnet before Coordicide and to offer an enterprise-ready solution for our ecosystem. This was achieved by an intermediate update called Chrysalis. You can read more about how Chrysalis was strategically released here.

A chrysalis is “the form a caterpillar takes before it emerges from its cocoon as a fully-formed moth or butterfly”. In the context of IOTA, Chrysalis was the mainnet’s intermediate stage before Coordicide's completion. The main purpose of Chrysalis is to improve the usability of the previous IOTA mainnet, for users and developers alike.

Why is this process of adopting major protocol improvements relatively unique to IOTA among permissionless Digital Ledger Technologies (DLTs)? The simple answer is the absence of miners. In most permissionless DLTs, the miners’ economic incentives differ from those of regular network users. Changes to throughput and network latencies can disrupt the fee market the miners rely on. This in turn makes them likely to object to network upgrades as it affects their bottom line.

In IOTA, validators and users are one and the same. There is no conflict of interests between parties with different motivations, meaning there is a much smoother path to network improvements. This is why we are able to incrementally and smoothly upgrade the network before Coordicide.

## What Are the Specific Chrysalis Upgrades?​

### White-flag Approach​

The White-flag approach, which is used for calculating balances. It is a simpler, conflict-ignoring approach that improved the speed and efficiency of tip selection, eliminated many network attacks, and significantly reduced the need for reattachments.

### New Milestone Selection Algorithm​

A new milestone selection algorithm for the Coordinator that focuses on allowing the network to support many more confirmed transactions per second (CTPS) than before, with higher computational efficiency.

### URTS Tip Selection​

A new Uniform Random Tip Selection in node software. It is significantly faster and more efficient than the previous tip selection algorithm.

### Ed25519 Signature Scheme​

The Ed25519 signature scheme has been added to the network, replacing the current Winternitz one time signature scheme (W-OTS) signature scheme. Using an EdDSA signature scheme allows the protocol and clients using the protocol to run more efficiently on established hardware. Unlike W-OTS, the Ed25519 signature scheme also allows for the re-use of private keys, and, with that, introduces reusable addresses to the protocol. This change also dramatically reduces the transaction size, saving network bandwidth and processing time.

### Atomic Transactions​

Atomic transactions that move the protocol from the current, complicated, bundle construct and use simpler atomic transactions instead. This results in much simpler development, and more adaptable and maintainable code of the core software. In addition, atomic transactions reduce network overhead, reduce transaction validation and signature verification load, and improve spam protection and congestion control.

### Switch to UTXO Model​

Switch to the UTXO model from the current account model. Every coin on an address becomes uniquely identifiable and every spend names the exact coins that it wants to move. This allows for faster and more exact conflict handling and improves resilience and security of the protocol. In addition, switching to UTXO makes other functionalities, such as colored tokens, on the protocol possible in the future.

### Internal Binary Representation​

A switch to an internal binary representation of the trinary transaction. This allows us to work on binary data for validation, IO, and other processing, without the current reliance on binary-ternary conversions as in the pre-Chrysalis node software. The switch to binary transactions further reduces transaction size, saving network bandwidth and processing time.

### New Node API and Client Libraries​

With Chrysalis, we wanted to offer a more standard API on both the node and client library level. Node implementations provide a completely redesigned RESTful and eventful API implementations.

Our client libraries provide high level abstractions that allow developers to build solutions that are easier to develop and cheaper to maintain.