# Juno Epona Software Upgrade (v18)

Epona marks our 6th software upgrade of the year. We have added 11 new modules to the chain in 2023, proactively found and patched 4 security issues, and increased our internal testing coverage.

In our final upgrade for the year, we bring you 3 new modules for developers to leverage in their smart contract applications. One of the core themes you will discover is our unwavering commitment to providing the best user and developer experience. Our solutions avoid chain lock-in so your applications can be deployed on many networks without multiple forks and developer overhead. Lowering the barrier of entry for contract deployment is a major consideration in how we add protocol features to Juno.

## FeePay Module

One of the biggest user experience pitfalls of the interchain is gas and fees. These topics while seemingly straightforward are confusing to users and developers with both the command line and website UIs. [FeePay](https://github.com/CosmosContracts/juno/tree/main/x/feepay) provides the functionality for smart contract developers to cover the execution cost of a transaction with their contract.

Privacy is a human right. For v2 of the FeePay module, we are working to provide new accounts the ability to interact with a smart contract without any tokens or previous chain interactions. The developer of the smart contract can leverage FeeShare to pay for half of the transaction, and the other half out of their own funds.

Why? It will enable protocols like [Juicer](https://twitter.com/juicerprotocol) to function without being dependent on a user facing faucet UI (which could scrape IP addresses and link to your wallet). On-chain faucet interactions with smart contracts that can pay your fees is a necessity to make the onboarding experience easier and add privacy to the chain.

## CW-Hooks Module

A large problem with developing smart contracts in CosmWasm is the lack of ways to get data from the chain to the contract. The new [CW-Hooks](https://github.com/CosmosContracts/juno/tree/main/x/cw-hooks) module improves this to give smart contract developers the freedom to design around core SDK components.

Starting today, developers can now subscribe (via the SudoMsg endpoint) to the following events within their smart contracts:

**Staking:**
- Validator Created
- Validator BeginUnbonding
- Validator Removed
- Validator Slashed
- Validator Modified (commission, name, etc.)
- Delegation Added
- Delegation Removed

**Governance Proposals:**
- Submitted
- Deposited
- User Vote
- Voting Period End

Application wise, you can now build ‘pay to vote’ contracts, automate vesting (slashing), and follow delegations to update contract state (i.e. internal liquid staking derivatives).

## Burn Module

**Background**
Juno’s staking rewards decrease over a 12 year period until a max supply of 185,562,269 JUNO is reached. To reach this maximum supply, fixed yearly incentives are allocated to delegators to secure the network. After this 12 year period, the JUNO token becomes deflationary where incentives would come from only transaction fees, IBC, and airdrops. We currently reside in the phase 3 schedule, a fixed inflation of 10%.

To accomplish these tokenomic goals the SDK’s x/mint module (required for minting new tokens to circulation every block) was modified to use hardcoded schedules based on the total supply. Every start of the block the logic:
Gets the total supply
Checks what phase this total supply is (i.e. 109m JUNO is phase 2, 110m is phase 3)
If the token supply has reached the next phase, update to the next phase. This updates the new inflation rate, phase, and target supply (unless it is year 12 and inflation is 0).

**Resolution**
This unique Cosmos minting module brought with it some interesting challenges for developers looking to utilize the chain’s burn coins feature. Since the x/mint module requires a set total supply, any tokens burned would be re-minted later to reach the target for the next phase. This has affected the burning of JUNO tokens to not function as expected. The need for actually burning tokens is a core part of [BalanceDAO](https://twitter.com/BALANCEDAO_) being built on Juno and kicking us into overdrive to patch this previous oversight.

Juno now burns JUNO tokens as expected from the network. This was accomplished by overriding the default BurnCoins behavior. It now burns the tokens then reduces the target supply by the amount burned from the x/mint module.

## New CosmWasm Features

Juno is now running the Wasmer 4 engine with CosmWasm 1.5, giving the chain better performance from the previous Wasmer 2 iteration. This leads to a ~50% decrease in memory consumption for fast contract storage per [Confio’s findings](https://medium.com/cosmwasm/cosmwasm-1-4-de9bbbe5cabc).

CosmWasm operates on Key-Value pairs to store and gather data for developers. There are many times where it is required to iterate every single pair to find the data you are looking for. This is computationally expensive even if only one value was needed for the search i.e. just give me all values not the keys. It is now possible to use the Store::range_keys and Store::range_values functions to be more efficient and gather only the data you require. This has an added benefit of reducing transaction prices for Juno’s users.

Juno contracts also now have added support for floating point numbers. Previously floating point operations were denied due to non deterministic behavior (different function outputs for the same input). This now allows for use cases such as bonding curves, non linear voting power, and generative art. Other math additions were also added to the standard library (abs / unsigned_abs, checked_multiply_ratio, full_mul, is_negative, and also more ::From and ::TryFrom implementations for different integer types.

You can read more from [Confio’s blog post](https://medium.com/cosmwasm/cosmwasm-1-5-946fd3024f1d) and the [CosmWasm changelog](https://github.com/CosmWasm/cosmwasm/blob/v1.5.0/CHANGELOG.md).