Juno is undergoing a complete restructuring. Since its inception, Juno has served as the hub for passionate individuals and believers in true network decentralization. Over the last four months, Juno has undergone significant changes at its core with the introduction of the Charter. The essence of this restructuring is to enable as many community members as possible to contribute significantly to the network’s future.

A great example of the new ideals can be seen in Juno’s Development Department’s recent Request-for-Proposal: the introduction of support roles! This will allow more individuals or even whole teams to efficiently support the ecosystem, while getting a compensation for their much-needed contributions! Let’s see the latest RFP of the Dev Department step-by-step!

Validator Set Support

Validators are crucial for the network; without them, there would be no Juno. With 150 active validators, and Juno set to pioneer cutting-edge technology in Cosmos, it’s common for validator operators to seek help to adjust to changes. In this role, qualified and knowledgeable individuals will provide technical support to validators and triage requests from the validator set concerning daily technical operations.

It’s important for anyone to be able to spin up their own validator and overcome common issues with ease. For this reason, the second part of the validator set supporters’ role will be to maintain, enhance, and develop technical documentation pertaining to validator operations.

👉 Read the detailed RFP here.

Chain Upgrade Support

Juno, currently at V21, is a Cosmos chain that has undergone numerous upgrades throughout its short history and introduced many new features in the interchain. This demanded extensive experimentation in the testnet environment, as well as effective coordination among validators. This role seeks individuals who can:

• Coordinate upgrades in both testnet and mainnet environments
• Ensure that an adequate number of validators are always prepared for the next upgrades by providing them with any necessary information
• Develop policies and procedures for chain upgrades

👉 Read the detailed RFP here.

Relayers Activity Support

It’s evident that Juno’s interoperability relies entirely on IBC. Validators have been diligently relaying packets across the interchain for a long time establishing more than 350 IBC channels (one of the highest stats in cosmos) and it’s the community’s responsibility to assist them in their work as conveniently as possible. Therefore, having a specific role for this crucial aspect was necessary. The responsibilities of relayers activity supporters will include:

• Providing technical support
• Monitoring IBC activity and identifying potential new connections
• Documenting relayers operations activity

👉 Read the detailed RFP here.

dApp Development Support

Juno is a smart contract platform, and dApps have always been its core focus. Over the years, Juno has introduced some amazing infrastructure for developers, such as the Burn, Clock, and Fee-share modules, to build competitive and performant projects with ease. However, the introduction of new, exciting modules and features, along with CosmWasm’s rapid development, has led and continues to lead to numerous help requests from builders. As a result, the introduction of this support role was inevitable. Its responsibilities will be as follows:

• Receiving and triaging requests from builders
• Collecting information regarding new features and modules
• Creating technical documentation related to dApp building

👉 Read the detailed RFP here.

Are you feeling up to the task? 🤔

Juno Network and the Development Department need you. Check the links provided with the detailed RFPs published from the Development Department and contact them on dev.dept@juno.zone!

Would you like to learn more about the department’s works and contributions? Make sure to follow them on DaoDao and their public and transparent channels on Discord!

✍️ This article was authored by Juno’s Community Relations Department

Rhea, the first Juno software upgrade of 2024, is coming to the mainnet! Packed with exciting features, this upgrade is a game-changer for Juno’s future. Get ready for a smoother and more powerful experience as Juno takes a leap forward, bringing new tools and connecting to the Polkadot-Kusama ecosystem.

Major Changes

• The x/Clock Module is now permissionless
• Wasm Light Client (Polkadot)
• Migrate Core-1 Multisig to Charter Council
• Enforce Validator’s Max 24 Hour Change Rate To 5%

Notable changes

• Updated to wasmvm 1.5.2
• Wasm memory leaks fixes

x/Clock Module is now permissionless

The Clock Module is a feature that was firstly introduced by Juno in the v17 — Vesta upgrade. With x/Clock Module, developers can register their contracts to ‘tick’ (be called upon) every single block with a significant amount of computation. This enables teams to cease running additional infrastructure and instead utilize the chain functions for their contracts. However, developers previously required governance permission to register their contracts for per-block execution. With the latest upgrade, the x/Clock Module will now be entirely permissionless and available for everyone to use!

Wasm Light Client (Polkadot)

A significant milestone in Rhea is Juno establishing IBC connection with the Polkadot ecosystem. By adding the WasmClient, Juno will be able to interact with Polkadot Parachains like Composable finance via IBC. This deployment (developed by the Strangelove team) signifies a pivotal development. Not only does it mark the opening of pathways to numerous possibilities but also lays the foundation for potential partnerships and alliances with various Polkadot communities and projects. With this upgrade, Juno leads the way as the first Cosmos chain to establish a connection with the Polkadot ecosystem, other than Composable Finance which Juno can connect through, or other Parachains that adopt the Wasm Client in the future.

Please be aware that the Juno<>Polkadot connection will not be instantly active, as there is an anticipated parachain update from Composable’s side, too.

Migrate Core-1 Multisig to Charter Council

With Rhea, the transfer of vesting and payroll contracts from Core-1 will be successfully concluded. Following the dissolution of the Core-1 SubDAO, the upgrade is designed to accomplish a dual purpose: to facilitate the transfer of funds from the Core-1 legacy multisig to the council, and notably to transform the Core-1 vesting account into a standard baseAccount. This will imply the availability of vesting cancellations and transforming other vesting accounts, a crucial step to ensure the smooth execution of the next upgrade, during which all previously vested funds of Core-1 will be transferred without any unforeseen issues.

Enforce Validator’s Max 24 Hour Commission Change Rate To 5%

This significant update is designed to safeguard the community against the potential abrupt increase in a validator’s commission overnight. An incident of this nature has already occurred in the active set of Cosmos Hub, where a validator suddenly changed its commission to 99.35% and earned profits to the detriment of its delegators. The implemented change aims to address such occurrences and protect the stability of the network.

Notable changes for developers & validators

Updated to wasmvm 1.5.2

Juno will maintain its cutting edge tech stack by upgrading to them newest version of wasmvm. Wasmvm 1.5.2 addresses an issue with growing memory usage over time introduced in 1.4.

Wasm memory leaks fixes

After the Juno v18 — Epona upgrade, certain validators experienced memory leak issues. Despite the identification of workarounds, the latest upgrade will successfully address and resolve these concerns, ensuring smooth functionality.

Closing Thoughts

Rhea will be one significant milestone in Juno’s journey as it will open a portal to an amazing ecosystem like Polkadot, unlocking countless possibilities and bringing communities together.

Even more important, it will be the first on-chain initiative to dissolve Core-1. The takeover from the Charter’s Council means the Juno ecosystem is officially stepping into a new era. Now, a group elected by Juno stakers is responsible for guiding and assisting the community and leading the ecosystem towards a better future!

Juno is a fully transparent and decentralized smart contract blockchain bringing true power to the community. Learn more and actively contribute to Juno by connecting with our official accounts.

Website | Twitter | Telegram | Discord

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 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 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 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 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.

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 and the CosmWasm changelog.

Juno’s Vesta upgrade is now live on mainnet and brings with it A LOT of new features for the network. We can not wait to see what developers come up with using our new modules for airdrops and smart contracts.

Major Changes

• Contract Clock Module
• Drip Module for Airdrops
• 3 second block times
• FeeShare for DAODAO contracts
• Free IBC limit increased to 2 million gas / transaction

Notable Changes for Developers

• TokenFactoryMsgs to interconnect with Osmosis
• CosmWasm 1.3
• Prettier globalfee errors

x/Clock Module

The clock module solves a problem many teams have built custom solutions for: internal bots to update contract state. With this new module, developers can register their contract to ‘tick’ (be called upon) every single block with a large amount of computation. This allows teams to stop running extra infrastructure and instead use the chain functions for their contracts.

Developer Integration
To integrate with this module, you will not need any custom bindings. All it requires is a SudoMsg::ClockEndBlock in your contract.rs file. Within this block you can add any logic you want for your contract. This will automatically be called every block once you are granted permission from the chain (next section). In the future, we are open to making this permissionless for all contracts.

// msg.rs
#[cw_serde]
pub enum SudoMsg {    
    ClockEndBlock { },
}

// contract.rs
#[cfg_attr(not(feature = "library"), entry_point)]
pub fn sudo(deps: DepsMut, _env: Env, msg: SudoMsg) -> Result<Response, ContractError> {
    match msg {        
        SudoMsg::ClockEndBlock { } => {
            if env.block.height % 10 != 0 {
                return Ok(Response::new());
            }
            // Every 10 blocks this config value increases 1
            let mut config = CONFIG.load(deps.storage)?;
            config.val += 1;
            CONFIG.save(deps.storage, &config)?;
            Ok(Response::new())
        }
    }

Getting Permission
Currently, a developer will ask governance for permission to register their contract for per block execution. (A guide for this can be found in the spec/authorization file in the x/clock module). In the future we plan on migrating this to a SubDAO or opening it up entirely for all to use.

x/Drip Module

Our new drip module now makes it easier than ever for a new project to airdrop its native tokens to all Juno stakers.

In the past, a new project must create scripts to scrape, analyse, and send out native tokens from their project (IBC and TokenFactory). Instead of this overhead, the drip module allows a developer to run a single command and deposit the tokens into the chain. Once deposited, users on their next rewards claim will receive these tokens in equal proportion of their staked Juno amount.

3 Second Block Times

We have had many teams and users ask for faster block times over the past year. With faster blocks we can create new applications and improve user experience both on and off the network through IBC.

Despite there now being two times more blocks, this will not add much overhead to the network. Blocks which remain empty take up minimal space compared to transactions. On chain, the largest transactions (storage wise) are IBC Client Update messages from relayers from IBC transactions.

As a node operator, you can also increase your query throughput via a block synced cache solution such as CosmosCache. In the future New Metric will also have an edge based cache solution, as well as DAODAO.

FeeShare for DAODAO contracts

By popular request, contracts which are uploaded via DAODAO can now register their fee payouts to their DAO, other contracts, or a standard user wallet.

If you are a smart contract developer want to earn 50% of all gas fees on your smart contracts, you can read this guide here on how to register at any time.

Bypassed IBC limit increased to 2 million gas

In the previous v13 upgrade (March 2023), Juno added the following modules:

• Packet Forward Middleware (from Strangelove) and
• IBC-Hooks (from Osmosis)

Since then, frontends have integrated these features into resources such as TFM’s IBC Swap and Skip’s ibc.fun. As these interfaces have gained adoption, the network has seen ever increasing IBC packet sizes above the previously limit. For this reason, and to keep cost low for our amazing relayers, we have doubled the bypass limit from 1 million to 2 million.

Currently any IBC transactions above 2 million gas will fail to send unless a relayer manually pushes it through. This is a limitation of the current relayer software, and we are working to get a dynamic fee structure built in soon. (Ex: 0ujuno fee up to 2 million gas, then 0.075ujuno for anything above)

Developers: TokenMsg renamed to TokenFactoryMsg

As the DAODAO team discovered the hard way, having 2 slightly different messages is a nightmare for cross chain applications. With this, we had to rename our messages to better interface with the Osmosis bindings for the same contract. This helps with execution, but more importantly testing.
You will need to update your contract’s token-bindings package to 0.11.0. Example migration

CosmWasm 1.3

The CosmWasm 1.3 feature set has now been enabled on the chain! To use them in your contract, just add cosmwasm_1_3 to your cargo features.

This adds the following features for contracts:

• Rust 1.70+ Support and Sign Extensions
• Signed Integers (Int64, Int128, Int256 and Int512)
• Coin and Coins now allows parsing inputs such as “123uatom” & math.
• BankQuery::AllDenomMetadata and ::DenomMetadata
• DistributionQuery::DelegatorWithdrawAddress
• DistributionMsg::FundCommunityPool
• Storage::range_keys and ::range_values

Prettier GlobalFee Errors

Over the past 6 months, we have had a lot of developers (both new and experienced) confused by lack of funds errors when submitting transactions. This is partially due to Juno accepting the ATOM IBC denom, which is sorted before the JUNO denom in the list. To resolve this, error messages now more properly format in a human readable way.

Juno’s Invictus upgrade will be on mainnet in the coming weeks bringing with it an entire overhaul of the code base, new features, modules, and actions for developers and users.

NOTE: This is a more developer oriented article / update.

Major Changes

• Upgrade from CosmosSDK v0.45 -> v0.47
• Upgrades ibc-go v4 -> v7
• Adds x/NFT
• Adds x/async-icq
• Adds Skip’s Mev Builder (x/POB) for ABCI++
• Users can now cancel unbonding

Notable Changes for Developers

• broadcast-mode block has been removed entirely upstream. This will break your CI/CD and scripts. This will affect ALL future chains which upgrade to SDK v0.47 as well. You are recomended to use sync + a timeout and query check.
• Governance proposals can now have multiple messages in 1 transaction. This will break governance builder tools such as interchaingov.com and may break explorers such as Mintscan & Ping for viewing.
• Using Juno on v16.0.0-alpha.1 (SDK v47) and up will migrate all your private keys to the new format on usage of the CLI binary (junod). If you update and decide to roll back, you will need to clear your ~/.juno folder and keyring, then reimport your keys

We at Juno understand that these are major changes and are sadly out of our control. We foresee broadcast-mode being the largest problem here and have already had many complaints about it. This is an upstream change and not something Juno wished to remove.

CosmosSDK v0.47

This upgrades main focus was to migrate from a legacy version of the SDK (v0.45) to the release from this year. This brings the latest features for the Juno chain including for smart contracts and IBC.

While a single number change from 0.45 to 0.47 may not sound like a lot, it required modifying 294 files (69,400 additions and 109,000 deletions) for the codebase. This further included a full rewrite of the GlobalFee module and our testing frameworks to be compatible with new requirements.

From here, we had to migrate all of Juno’s FeeShare, TokenFactory, Mint, and GlobalFee parameters from a removed storage module upstream (x/params). Then migrate all users tokenfactory tokens to comply with the Cosmos SDK’s bank module validation checks. There were and are a lot of places this upgrade’s migration could go wrong, however due to more extensive testing we were able to release faster than ever for such a large update.

Why upgrade? (Polkadot Wasm Client)

It is important for Juno to be at the cutting edge of the technology stack so developers can design and execute their protocols cross chain. By pushing to the edge we will run into problems other chains have not yet encountered — but helping those who come. We continue to remain competitive in our core technology offering to developers and the ecosystem.

With our stack now fully up to date, we have finished the code to enable the Wasm light client from the strangelove team on Juno (pending cleanup for IBC v7.3). This upgrade sets the path forward to become the first upgraded Cosmos chain to connect to the Polkadot ecosystem through Composable Finance.

Future Upgrades

Following how large this upgrade already was, many bits of code have already been completed for standalone future upgrades including:

• Polkadot 08-wasm client (next)
• Migrating Core-1 vesting contracts to be community controlled
• Faster Block times (3 seconds) + Cosmos Cache

These are ready to go other than final check testing and coordination with validators and governance to push through.

Developer Experience (Local-Interchain enviroment)

With Juno being an incubation chain, we have to also solve the developer user experience problem for more than just ourselves. We must make it easier for developers to have quick, easy iteration testing environments for complex Cosmos networks no matter your background.

Due to this limitation in the Cosmos ecosystem, a tool has been developed called Local-Interchain to make launching local chains and IBC relayers a breeze for developers. Gone are the days of managing 4 chains configurations, having 4 terminal windows open, and trying to figure out what to do. Now all you need to know is JSON configuration and you are set to run local-ic start juno_ibc!

This is a major set forward in terms of developer experience and allowing for web2 backgrounds to quickly iterate on projects without the hassle of production networks and confusing setups.

We abstract away the interchain so you can do what you do best: develop.

The Thought Process

The Juno Delegation Program (JDP) subDAO has been going back and forward on how to approach the JUNO delegations in a fair and responsible way. It turns out that it’s not as easy and straightforward as we would have desired. Either criteria is hard to measure and/or verify, criteria was not fair towards a specific group of validators or criteria was not beneficial towards the chain/community overall.

Having that said we did come to a set of criteria we had already released and shared with everyone. For the first epoch we have decided to be a little more lenient. For example the governance participation threshold of 80% to be eligible was dropped for this first round. However, next epoch this will be upheld.

We will constantly improve this program as required. Trying to balance rewarding validators for their provable added value to Juno and making sure it doesn’t affect the chain the wrong way.

The Eligibility / Criteria

We’ve set a few minimum requirements to make sure we are rewarding validators who have proven themselves to be capable validators while still taking the Nakamoto coefficient in consideration. These requirements go into the following categories:

• Submission of application
• Validator information
• Maximum commission
• Maximum rank
• Exchange validators
• Governance participation
• Uptime
• Downtime slashing
• Doublesign slashing
• Multiple validators
• White-label validators

See the full JDP to get into the details of these requirements.

Once a validator passes the above requirements, it will be able to start earning points on several criteria after base delegation has been assigned. On each criteria points can be earned and your total amount of points compared to the total amount of points gained by every eligible validator will be your share of the Foundation Delegation. In order to balance the chain shifts a little bit, we did also put a cap on the amount 1 validator can earn. The criteria to earn points on are as follows:

• Technical Criteria
• Non-technical Criteria

The Results

After evaluating all submissions, verifying eligibility and criteria scores, we came to the following conclusion of delegations. If your validator is not in this list, it means it did not meet the minimum requirements (even after being a bit more lenient this first epoch). We advise every validator to carefully read what the requirements and criteria are to be eligible next epoch. We’ve noticed that some validators give a lot of extra information on the submission form that have nothing to do with what is asked. This will be ignored, so please read carefully what the question / submission form is in regard to.

Without further ado, the results:

https://docs.google.com/spreadsheets/d/1v6TfvBlsaUqMfjPQHRk2ZJjI3bV3ykOdKlCPXJCg_lA/edit?usp=sharing

Note: this is the total amount of Foundation Delegation a validator will end up with. Compare this with your current Foundation Delegation and the difference will be applied.

The Future

Creating the JDP’s minimum requirements, criteria, evaluating all submissions, fetching data, calculating accordingly ect. all takes a lot of time. A lot more than we expected and are able to invest every 3 months. Therefore we will change the epoch period to every 6 months.

We’re also interested in a new Delegation System that has been built that can do a lot of monitoring and adjust delegations automatically based on a pre-set configuration. We are looking into this for the future where we can automate a lot of work we’ve done manually this time around. Once we are in an advanced state into using this application we’ll inform everyone of this new system, process and foreseen configuration we’d like to use.

We’d like to say thanks to all validators who are helping Juno by adding value to it in some way or another. Enjoy these delegation rewards and we’ll see everyone again in 6 months.

If you have burning questions please feel free to get in contact with the JDP subDAO in the #juno-delegations channel in the Juno Discord.

Babylon is now live on the Juno test-net.

The collaboration with Babylon, provides the Juno Network with improved transaction security as well as the option of lower un-bonding periods. With Juno’s vision to be the Interchain Incubator for decentralized interoperable applications, Babylon offers Juno Bitcoin-level security that enables it to be one of the most secure interoperable smart contract networks in existence today.

Securing Cross-Chain Smart Contracts

Babylon’s integration enhances Juno’s infrastructure and security, benefiting Juno’s community that uses and creates interoperable applications on the network.

As Juno strives to become a leader in cross-chain smart contracts, it is focused on solving common smart contract L1 bottlenecks such as scalability, security, interoperability and runtime performance. As the Interchain Incubator, Juno is exploring faster block production that increases Transactions Per Second (TPS) that speeds up the development of new application types.

Bitcoin today is the most secure global blockchain. Its mighty PoW mining power provides reliable and irreversible timestamps to Bitcoin transactions. This yields irreversible timestamps and an immutably ordered list of transactions and, thus, an immutable ledger. Babylon brings Bitcoin security to Juno by allowing Juno blocks (and the transactions therein) to be time stamped onto the Bitcoin network.

Furthermore, the Babylon integration preserves Juno’s sovereignty, fast block speed, as well as its high TPS.

Lower Un-bonding Period, Improved Flexibility

Un-bonding periods generally last weeks because they serve as a trust period where users can return to the chain and safely re-synchronize to the chain knowing any attacks that may have occurred while they were away will have already been slashed.

Un-bonding requests on many SDK based networks in the Interchain are set to between 14 and 28 days. Using Bitcoin security via Babylon, users only need to wait until the Bitcoin timestamp of the un-bonding request transaction is confirmed on Bitcoin with sufficient depth (e.g., 100 Bitcoin blocks), which only takes about one day.

The Babylon integration removes the need for a long trust period because once you have Bitcoin timestamps, users can easily discern the normal chain from the attack chain, which will have a later Bitcoin timestamp.

In addition, Babylon makes timekeeping of the unbonding process reliable by using the BTC block time.

Therefore, what the Babylon integration brings to Juno in terms of stake un-bonding is a secure and reliable un-bonding process, regardless of how long or short Juno desires it to be.

Besides secure and reliable un-bonding, the Babylon integration also enables other features for Juno users. For example, Juno users may wait for a BTC confirmation for their high value transactions, the same way you may prefer sending a large sum of capital through wire transfer that takes 3 days despite the option of an instant online transfer. Babylon gives the Juno developers and community the freedom and option to choose the latency-security tradeoff.

Ultimately, Babylon’s integration offers Juno composable and enhanced security, leveraging Bitcoin timestamping to secure transactions that take place on Juno.

About Babylon

Babylon is a blockchain platform that leverages the security of Bitcoin as a source of trust and a reliable timestamping service to enhance the security of Cosmos zones and other Proof-of-Stake chains. Babylon offers a range of protocols, including Bitcoin timestamping protocol, Bitcoin data availability protocols, Bitcoin staking protocols, as well as many use cases, such as fast stake un-bonding, bootstrapping of new zones, protection of transactions, and censorship resistance.

Stay up to date

⚪️ Web: https://www.junonetwork.io

⚪️ Twitter: https://twitter.com/JunoNetwork

⚪️ Discord: https://discord.gg/JUNO

⚪️ Telegram: https://t.me/JunoNetwork

⚪️ Github: https://github.com/CosmosContracts/Juno

⚪️ Updates: https://t.me/Juno_Updates

Introduction

Juno is the most active permission-less blockchain in the Interchain ecosystem. The Juno Evolution document outlines a strategic plan for Juno’s transformation from a basic L1 to a fully-fledged network. This vision serves as a guiding light to reach our desired destination: Juno — The Interchain Incubator.

Juno’s Vision: The Interchain Incubator

In the Interchain landscape, projects have two primary options for launch:

1. Deploy a native app-chain, which demands significant time and resources; or

2. Utilize an established L1, offering community, tooling, infrastructure, security, and a permission-less environment for the most efficient market entry.

Juno paves the way for the second option, facilitating rapid project development and iteration, enabling engagement with one of the most active communities within the Interchain, and helping projects find product-market fit before launching their own Mesh-Secured L1.

As new projects emerge in the Interchain, Juno provides the best turn-key environment for launching and iterating projects. Via its revolutionary tooling daodao.zone, Juno is equipped with cutting edge incubation tools which projects can effortlessly utilize, providing them with all the perks of a native developed L1 without concerns about independent app-chain security.

Juno Evolution is committed to refining this process, enabling users to fully leverage the radical innovations within the ecosystem and maximize the benefits that come with it.

Juno Evolution: Key Initiatives

1. Mesh Security: Designed to maximize security and align economic incentives with other L1 blockchains. This initiative will enhance Juno’s overall security while fostering collaboration and a seamless flow of economic value within the Interchain.

2. Governance Advancement: We will establish Juno as the leading Interchain DAO. By leveraging DAO DAO’s flexibility, we will enhance adaptability, collaboration and resource efficiency for Juno and projects on Juno, while enriching innovation across the entire ecosystem.

3. A Technical Roadmap: to elevate Juno’s current capabilities, this initiative will establish Juno as one of the most powerful Layer 1 platforms. Emphasizing performance, scalability, and throughput improvements; this will solidify Juno as the premier platform for project launches.

1. Mesh Security

Juno is actively leading development of Mesh Security, a key component for realizing its vision as the Interchain Incubator. Mesh Security will provide a more secure Juno and allow projects incubated on Juno’s Layer 1 to leverage Juno’s security.

For end users, this means staking Juno to earn other tokens from across the Interchain.

This initiative is made possible by the collaboration between Juno and Osmosis, with the support of some of the brightest minds in the space.

Mesh Security enables the creation of mutually beneficial economic incentives, enriching association between sovereign sister chains within the ecosystem which creates a seamless flow of economic value for Juno’s users and applications.

2. Governance Advancement

Juno Constitution

The Constitution is a crucial step towards the development of our Governance process; protecting the rights of all participants in the Juno Commonwealth, and outlining the powers, limitations, and obligations of Governance.

Utilizing DAO DAO for Core Juno Governance:

As a decentralized project and community, we are only as strong as our ability to organize. By utilizing DAO DAO to the fullest extent, we can develop more robust and agile governance tooling required for a large community like Juno to truly thrive.

We will progressively transition Juno Governance to DAO DAO.

The features, we will enable, include :-

· Gauge-based funding

· Vesting payments

· Delegation system without the requirement of operating validators

· Multiple-choice voting

· Simplified navigation and discovery of SubDAOs

· Interchain Accounts for secure, trustless control by Juno Governance over accounts on other chains

· Exceptional User Interface

These features will introduce essential improvements to Cosmos Governance, equipping the Juno Community with the vital tools to govern itself more effectively.

Legal and Business Development SubDAO

As Juno grows, it becomes increasingly important to interface with the legacy financial system. This is crucial for securing listings on centralized exchanges, agreements with market makers to establish deep liquidity, and forming partnerships that advance the interests of the Juno ecosystem.

While many legal entities participate in Juno, there is a need for an official SubDAO and a legal entity to manage agreements and relationships on behalf of the Juno Community.

3. Technical Roadmap

Top Tier Performance

Enhancing Juno’s runtime performance is a top priority.

Starting with optimizing our CometBFT configuration to explore faster block production while maintaining the overall health of our validator set and uptimes.

Besides, will contribute to both the Cosmos SDK and CometBFT, bringing their performance to new heights.

This work will result in a substantial increase in Transactions Per Second (TPS) and block speed, making Juno one of the fastest and highest throughput blockchains, and enabling the development of novel application types.

CosmWasm Modules

CosmWasm modules will allow developers to write custom blockchain modules using Rust and CosmWasm rather than Golang. By granting certain smart contracts extra permissions through governance, smart contract developers will be able to access specialized Cosmos SDK features such as BeginBlocker and EndBlocker.

This feature will open up to remarkably faster development of custom functionality on Juno, besides to the ability of applying changes without requiring to upgrade the entire blockchain software.

CosmWasm modules provide greater stability than traditional Cosmos SDK modules

Tools for Migrating Juno Projects to Mesh Secured L1:

We will simplify the process for projects to launch on Juno, discover their product-market fit, and transition to a Mesh Secured L1.

A crucial aspect of our roadmap involves developing the tools to streamline this process.

Bitcoin Security with Babylon

Babylon Chain offers a way for Proof of Stake blockchains like Juno to achieve Bitcoin-level security. We will leverage it to further solidify Juno’s security and label Juno as one of the most secure smart contract layers in existence.

Furthermore, we will build deeper integration as soon as new Babylon capabilities have been audited and tested.

Integrating with Babylon’s security opens the access to lower bonding periods for Juno, as Juno stakers can unbond their delegations sooner while the network sustains its augmented security.

Resolution

The pivotal year of 2023 will witness Juno reaching new heights, fulfilling its envisioned role of becoming the Interchain Incubator.

Executing these initiatives in various critical directions such as Governance, Runtime Performance, Security, and overall amplifying Juno’s Incubation traits, will enable Juno to stand on a higher ground for projects to launch on; and further foster mutual collaboration with sovereign chains within the Interchain.

Written by Jake Hartnell, Lobojuno, Rarma, Cameljuno, Traiano & the Communications subDAO. Feedback & improvements by Reece Williams, Maxjuno, AlexFrey, DimiAndre & Jacob Gadikian.

Stay up to date

⚪️ Web: https://www.junonetwork.io

⚪️ Twitter: https://twitter.com/JunoNetwork

⚪️ Discord: https://discord.gg/JUNO

⚪️ Github: https://github.com/CosmosContracts/Juno

⚪️ Updates: https://t.me/Juno_Updates

The most disruptive & cutting edge public good of the last decade. Developed on the Juno Network.

DAO DAO is open & free for all to use.

Enabling anyone to build products & services, applications & organize communities with no coding skill requirement. Giving builders & visionaries the most efficient tools to launch a DAO (Decentralized Autonomous Organization) underlying their application.

In an age were blockchain takes its next evolutionary leap towards an interconnected decentralized web aka. The Interchain; Innovators now have the ability to launch a DAO that interoperates with the entire Interchain world.

By utilizing the security of the Juno Network, builders don’t have to worry about costly and resource intensive security for their own application specific app-chain anymore. One can now focus on the four relevant drivers that matter most:

1. Building a successful product or service
2. Building a userbase
3. Monetization
4. Governance

Via DAO DAO, one has all turnkey tools at hand that allow both permissioned and permission-less systems to be constructed. The organizational structure can be custom adjusted to a specific use case. Not every project needs a large community run DAO. Instead builders have the option to select the type, size and structure of their DAO that fits their needs. Every application specific use-case imaginable can be tackled. Below are just some examples of DAO usecases:

• Product or services DAOs
• Investment DAOs
• Defi DAOs
• Crowdfunding DAOs
• NFT DAOs
• Social DAOs
• Metaverse DAOs
• Security DAOs

Lets now take a peak into DAO DAO and its utility.

Visit daodao to get started.

Right away, one has the option to create & customize a DAO.

Next we want to choose a structure. Either a membership DAO, token-based DAO or NFT based DAO.

For testing purposes lets create a token based venture capital DAO called Colibri Capital.

We can now customize the native asset of the DAO. This includes a custom ticker, supply and allocation specifics.

One can now set up different tiers for the asset allocation ie. how much should the DAO treasury, Foundation, etc hold at inception. Note this is highly dependent on your specific use case and structure.

In the next step we can custom set certain DAO parameters like governance voting duration, un-staking period, minimum deposit amounts, Quorum, passing threshold on proposals and more.

Next we want to create the DAO itself by instantiating the contract. Simply press “Create DAO” and sign the transaction. Note: you will need around $0.01 cents in $JUNO (Native asset of the Juno Network) to pay for the network gas.

Here are some easy options to acquire some $JUNO:

Wynd, Osmosis, Kraken or Kado.

Now that your DAO is live on the blockchain, lets look at some more DAO DAO features.

Note: The organic developer base of DAO DAO is constantly adding new features and improving the tooling. Stay up to date with all things DAO DAO here:

DAO DAO Twitter: https://twitter.com/DA0_DA0

DAO DAO Discord: https://discord.com/channels/895922260047720449

Colibri Capital now has its own DAO contract address, treasury, native asset & governance. The DAO is able to hold various Interchain assets in its treasury like for example $ATOM, $JUNO, $USDC, $BTC and more. The DAO can even stake some of those assets to earn staking rewards.

In the picture above one may also see a subDAO tab. This is an option that allows for the DAO to appoint subDAOs that are accountable to the main DAO. Essentially a way to delegate tasks & resources.

Another key element of DAO DAO is its flexible operations & governance utility.

Via on-chain proposals, one may perform the following actions:

Finally, lets look at Polytone, the latest DAO DAO addition on Juno.

Polytone is CosmWasm native, it combines ICA and ICQ into one nice standard, and will be audited and ready to use later this month. Polytone enables Cross-chain staking from your DAO.

Make sure to share this introduction to DAO DAO with your favorite builders, innovators & visionaries. Lets build the Interchain future together!

Written by Lobojuno

The Aurora upgrade v.14 will launch on the Juno main-net shortly! This upgrade comes just weeks after our previously feature packed v.13 core software release.

Aurora will include the following:

• x/GlobalFee Module
• 0 Fee IBC Relaying
• x/IBCHooks Module
• Stargate Staking Queries
• Tokenfactory: ForceTransfer, MintTo, and BurnFrom
• x/wasmd 0.31
• wasmvm 1.2.1
• Command Line quality of life improvements

New: x/GlobalFee

Passed in Juno proposal 68

Currently on cosmos based chains, validators are fully in control of the set network fees. With this new module, a minimum gas fee is set by governance as the gas pricefloor.

At the upgrade, gas fees are set to our setup documentation gas prices default:

• 0.0025ujuno
• 0.001uatom (ibc/C4CFF46FD6DE35CA4CF4CE031E643C8FDC9BA4B99AE598E9B0ED98FE3A2319F9)

At any time, governance can increase these fees across the network to help deliver more for developers (through feeshare) and stakers. It can also add new tokens to be accepted as fees such as OSMO and USDC in the future.

If an transaction attack occurs on Juno, validators are able to raise their fees ABOVE the minimum gas fee to protect the network as needed.

After this software upgrade is live, the team will work on drafting a proposal to increase governance fees. This impact will be negligible for network usage, but have a much larger impact for FeeShare based contracts. It is important the community has a say and and give valuable feedback, which is a reason this new module is so powerful for JUNO.

Fee-less IBC Relaying

For our relayers, IBC transfer packets will bypass the the fee minimum to reduce the cost of relaying for Juno network! This includes

• MsgRecvPacket
• MsgAcknowledgement
• MsgUpdateClient
• MsgTransfer
• MsgTimeout
• MsgTimeoutOnClose

Even though these do bypass GlobalFees minimums, they still must pass a Validators’ min_gas_prices config at time of submitting. This is why we have recommended node operators to update their configs to 0 ujuno gas after upgrade.

New: x/IBC-Hooks

This new module from the osmosis team allows for IBC token transfers to execute contracts on other chains with one click. Applications will be able to leverage this by putting the execute messages in the memo field of the users wallet. These can be auto generated, or the user can modify for their specific needs.

This now improves user experience across interchain applications and opens JUNO to cross chain swaps, outpost, and much more!

Cosmwasm 0.31 & CosmwasmVM 1.2.1

Wasmd 0.31 Confio Article

wasmvm 1.2.1 Confio Article

The main feature from this update which many teams have requested is the instantiate2 feature within contracts. This method allows a developer to replicate a contract with predictable addresses. You can find an example of this with this contract example.

Some other notable improvements include:

• Governance based weighted votes
• new queries from wasmvm 1.2 (add the cosmwasm_1_2 feature in your contract toml)
• Uint128/Decimal multiplication
• A new ‘Never’ type

New Token Factory Methods

From the previous upgrade, v13, we added the x/TokenFactory module to deliver a better UX for developers and users alike. As the admin of a token denomination you can now Force transfer tokens between accounts, Mint directly to an account, and burn from another account.

In a future update, we will also be adding support to disabling the sending of tokens. This will only allow minting & burning for unique application needs and business logic.

Skip MEV by default

With the passing of Juno proposal 275, Skip’s MEV CometBFT consensus is now used by default. As stated in the proposal, Juno has the highest adoption of Skip in Cosmos. At any time governance can undo this action or change to use a different MEV provider.

This is a quality of life addition for Juno validators. Validators who do not use Skip or have another MEV solution, this will not change their operations in any way. Validators can continue to use other MEV solutions if they so choose.

Command Line Quality of Life

As a developer or validator on Juno, a lot of the commands you run are very redundant. With this upgrade, you can now specify the following configurations for any transaction commands you run:

- Gas
- Gas Prices
- Gas Adjustment
- Fees
- Fee-Account
- Note (memo)

You can set these values just like any other config:
- junod config fees 5000ujuno

Once doing this, your ~/.juno/client.toml file will update with all the latest transaction configuration for these settings with comments.

Stay up to date

⚪️ Web: https://www.junonetwork.io/

⚪️ Medium: https://medium.com/@JunoNetwork

⚪️ Discord: https://discord.gg/JUNO

⚪️ Github: https://github.com/CosmosContracts/Juno

⚪️ Updates: https://t.me/Juno_Updates

⚪️ Twitter: https://twitter.com/JunoNetwork