JUNØ— v.13

4 min readMar 13, 2023

Juno has successfully upgraded to version 13 on main-net. Introducing many great new developer features which improve the user experience for all! Our biggest upgrade yet, kicking off a strong start for 2023.

For your convenience we have listed all the new feature additions below.

FeeShare

Proposal 51, which passed in November, has been implemented and tested extensively over the last few months. It allows Juno developers to opt-in and earn 50% of the gas fees on their contracts for any JUNO tokens paid as gas. Instructions on how to register your contract can be found here.

As a Juno delegator/staker, you have the power to change the 50% fee split and the tokens shared with developers by submitting a proposal at any time (Param change proposal).

This feature enables developers and communities to earn JUNO income passively for their contract work, without requiring additional funds from users. As usage and popularity of the application increases, so does the income.

TokenFactory

This new update included a module that enables developers to interact with native tokens directly, enhancing the user experience in several ways.

Airdropping to token holders
Displaying all tokens for an account with a single requests for frontends
Reducing the overall contract logic
Command line users can now send tokens via the standard junod tx bank sendcommand.

For developers and DAOs, we have migration and middleware contracts. You can find these in the CosmosContracts/tokenfactory-contracts repository.

Migrate (CW20 and Native)

User deposits a CW20, it is burned, and a new native token is minted to them
User deposits a native token (IBC, another TokenFactory, or JUNO) and receives the new token-factory native token.

Middleware Core (Multiple Minter)

Allows a single contract to mint multiple factory tokens on behalf of whitelisted addresses
Allows an external contract to mint tokens via a standard WasmMsg.

Further documentation can be found here including how to create a token and how to modify the metadata (name, description, exponent, and Ticker Symbol)

Packet Forward Middleware

The IBC-Router from StrangeLove is finally here! This module forwards packets from chain A to Juno to chain B without any interaction from the users initial requests. This is done by adding some extra metadata in the receiver address field.

As more new chains come online, it is simpler for them to just connect to Juno and use it as an interchain forwarding hub, possible thanks to our amazing relayer and node operators. Due to this expected demand, we have also implemented the follow to make relaying more sustainable.

Relayer IBC Fee Payment (ICS-29)

To make relayer operations more sustainable in line with packet forward middleware, the team has added IBC-Fees to Juno. As other source chains implement this specification, relayers can register their addresses on both chains and receive fees for relayed packets. Frontends lack the current capabilities for users to pay these fees, but Juno is at the cutting edge and the chain now has the ability to onboard as this become commonplace in the interchain. You can read a more in depth guide from Imperator here.

Interchain Controller

Juno now has the ability to control accounts on other chains through IBC using Interchain Accounts. This host chain account will have all the abilities of a normal account without the need for signing with a private key every time. Rather this is done over Juno’s authentication module via the IBC packet. This signals to the host chain the message(s) are ready for execution for a given account.

For our host, Juno now supports all messages just as a native account would have access too.

CosmWasm v0.30

Read all the details from Confio’s blogpost

Authz

Contracts now have access to the Authz module. This module allows an account to grant select actions to an account or contract to execute on the original accounts behalf. This protects the original accounts private key while but delegating select message task to match a developers or users requirements for some task.

This comes with finer tuned authorization access via the wasmd authorization extension. This has filters to define contract message matching for both exection and migration on select contracts.

AllowAllMessagesFilter
AcceptedMessageKeysFilter — withdraw,delegate allows {"withdraw":{}} but not {"send":{} .
AcceptedMessagesFilter — a message MUST match exactly including spaces such as — {“vote”:{“option”:”yes”}}. This way the user could never vote no on behalf of a contract.
You can also limit the number of times a contract grant can be used and the token budget for that account.

Proposals

Currently contracts are limited to ~800Kb of data for a single upload. This is fine for a majority of contracts. Now if you upload a contract via governance, you can use up to 4Mb of space on store.

Stargate Queries

Stargate queries are a powerful generic extension point to query system state via the “Stargate” generic protobuf format. With this, a contract can query data from the chain such as a users vote on a proposal. We only support a limited number of endpoints for now

ibc.core.client.v1.Query/ClientState
ibc.core.client.v1.Query/ConsensusState
ibc.core.connection.v1.Query/Connection
cosmos.gov.v1beta1.Query/Vote
osmosis.tokenfactory.v1beta1.Query/Params
osmosis.tokenfactory.v1beta1.Query/DenomsFromCreator
osmosis.tokenfactory.v1beta1.Query/DenomAuthorityMetadata

In a future update, we are also adding the ability for a contract to query the current Unbonding information for an address.

Documentation

A documentation overhaul is currently underway for Juno to bring better examples and explanations to Juno developers. This includes everything from backend to frontend with many user facing tutorials to come. Our goal is to provide the one website you need to gather resources to solve common problems developers experience.