Juno V13 Update
Juno Network is upgrading to V13, bringing exciting new features in its largest update since inception! — Read on to learn more about all the great development coming to the home of CosmWasm.
Audio: JunoCommsDao #1 — DAODAO v2 and v13 Update from the Team
Archive: link
TL;DR
- 50% of contract Fees split with contract developers
- Native Tokens for DAOs & developers with Token Factory
- DeFi Oracle price feed
- Governance set minimum fees with query for users
- Interchain Account Host + Controller
- Wasm v0.30
- IBC v4
- IBC Routing
- 20% Initial governance deposit
x/FeeShare Module
Earn your share with FeeShare! — PR #385
If you’re a smart contract developer on Juno, you can now earn a cut of all gas fees generated on your contract. No registration fees, no hidden costs, and no code changes are required.
How does it work?
If a transaction interacts with a smart contract, half of the transaction’s fees are set aside for any contract(s) a wallet has interacted with. The first 50% goes to delegators as usual (community pool), with the other 50% being split among each opted-in contract. This opt-in requirement is only for tax purposes, it is permission-less to do as shown below. You can opt-in and set the withdrawal contract to any other wallet, for example, a personal wallet, a DAO treasury, or a module account.
Given users are already required to pay fees, this mechanism will allow for a new set of business models to be built on Juno while still allowing for the economic incentive to maintain, build, and develop their protocol. This aligns developers, users, and the entire Juno Network community together to push for more growth and adoption. A large net positive for all!
Governance Defined Parameters
The FeeShare module has the following parameters which governance can change provided a passing proposal:
- Enable / Disable Fee-Sharing capabilities
- Raise or Lower the 50% split (from 1% to 100%)
- Updating allowed denominations to accept and pay developers in, for example: USDC from Axelar.
This allows delegators the choice to change how the underlying economic incentives align with developers building on the chain. At upgrade, it will be enabled, set to 50%, and only share JUNO based fees with developers in accordance with Proposal 51’s outline.
Design Considerations
It’s important to note that FeeShare requires direct contract execution from the entity/wallet. This means that sub-messages are not counted at this time. This is for security & abuse reasons. It ensures a contract developer does not rig the system by having their contract call out to many of their other own contracts. Thus artificially raising their split percent.
A bad actor example that would be possible:
- 2 Contract Execute Messages, 1 of which fires 2 sub-messages = 4 total fired messages.
- One entity would get 75% (3/4 messages) of the 50% fee. Which would give incentive to running many contracts, requiring more gas and taking advantage of our split mechanism.
In the future, we will be looking into allowing sub-message based fee sharing, but for now, we wanted to ensure the base product could be delivered for a majority of use cases.
Sign-up process
For your contract to qualify for a share of its executed fees, you must meet one of the following criteria:
- You are the admin of the contract
- If there is no admin, you must have been the contract uploader
To register your contract’s fee withdrawal address, you will just run the following command via the CLI:
junod tx feeshare register <CONTRACT> <WITHDRAW_ADDRESS>
This means natively registration has ledger support!
x/TokenFactory Module
Native tokens rule, let’s use them! — PR #368
Another great module coming for developers on Juno is the Token Factory module. This module is originally from the osmosis-labs team, which brings native token minting, query, and sending without the hassle of the CW20 spec. This is a major quality of live improvement for contract developers and user interfaces.
- Airdrops are many times easier for users holding DAO tokens from a state export, rather than slow paginated query.
- Frontends such as Keplr and Mintscan will be able to show off your DAO tokens via a single query, rather than RPC querying every CW20 contract in existence (inefficient!)
- Contract developers no longer have to add support for CW20 when all contracts already have native tokens support built in to work with Juno!
- CLI based users will be able to send any token via the standard junod tx bank send instead of wasm execute CW20 message passthroughs with base64 encoded data
Migration
DAODAO will also be migrating to use these native denoms in the near future. The Juno Core team has been building many utilities to make this migration as seamless as possible for projects currently on CW20 who would like to migrate to a native token.
You can view migration docs and scripts here from our DAO meeting. If you do not believe your DAO or CW20 token fits with any of the proposed changes, please contract us in the DAODAO or Juno discord
This module was imported from our fork of CosmWasm/token-factory, which was forked from osmosis-labs/osmosis/x/tokenfactory. This was required to add more testing and also upgrade to IBC v4.
x/Oracle Module
DeFi! Get your DeFi here! — PR #329
An exciting DeFi based module is also entering the network as per proposal 57. This module will bring up-to-date external pricing data into the chain for contract developers to query and use in their products. This can be thought of as a bridge between the blockchain and the real world data from exchanges for the prices of ATOM, OSMO, and JUNO.
This module will not cost validators anything for endpoints. A Fee Grant will be set up to cover any transaction submitting cost, and all Transactions will bypass GlobalFee (next section). Validators are required to run this extra software within the vote period. Failure to do so would lead to a soft slash, similuar to if their node is offline. On Juno this would move 0.01% of all delegated funds for said validator to the community pool (0.1JUNO per 1,000 staked).
The module was forked from umee, which was forked from Terra. So this code has been battle-tested by lots of users and many teams having worked on it.
x/GlobalFee Module
Set Fee? Yes Please — PR #411
The new GlobalFees was voted as a YES from the community with strong support on proposal 68. Originally planned for Juno v13, we were able to pull ahead and release it early for the network.
This module sets a minimum requirement for all nodes to accept defined fees to get their transactions into the network blocks. With this, it also makes it possible for users and front-ends to query what the required fees for gas are.
This means transactions must contain at least one denomination that is present in the governance-defined set of tokens, with the default 0.0025 ujuno per gas to start. In the future governance can add USDC, OSMO, and other interchain assets as desired.
Validators
In your configs, you have a min_gas_prices list of fees. Here are some considerations for how this affects you
- Only fees set in GlobalFee can and will be accepted
- Accepting Fees for transactions under the limit will default to the global set limit (excluding bypassed messages for IBC transactions)
- If you set a denom for higher than is in GlobalFee, the transaction must submit with enough gas in accordance with min_gas_prices for your proposed block.
After the upgrade, it will be safe to set your config to zero ujuno. This way relayers can submit fee-less IBC and Oracle transactions.
Provided a network spam attack occurs, validators can raise their minimum gas prices greater than the global minimum fee. This makes it economically unviable to continue the attack for a short period of time.
Relayers
For our relayers, IBC transfer packets will bypass the GlobalFee minimum to reduce cost of relaying for Juno network! This includes
- ibc.core.channel.v1.MsgRecvPacket
- ibc.core.channel.v1.MsgAcknowlegement
- ibc.core.channel.v1.MsgTransfer
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 recommend node operators to change their configs to 0 ujuno gas after upgrade.
Interchain Accounts Host
Controlling accounts at a chain near you — PR #215 & #436
Juno is going to now be an Interchain host and controller (previously just a controller). This means the chain will now listen for IBC packets from a controller chain which will give instructions (standard messages) that the interchain account wishes to execute.
This host chain account will have all the abilities of a normal account without the need for signing with a private key. Rather this is done over the controller’s chain authentication module via the sent IBC packet which signals to the host chain the message(s) are ready for execution.
You can read more from the cosmos network tutorials page for a deep dive into the technicals
With this, we have also added more messages for execution including TokenFactory, Wasm IBC, and FeeShare messages (PR 436). Allowing for cross-chain minting, burning, and IBC sending of tokens.
Minimum Governance Deposit Fees
Spam be gone — PR #398
With governance spam on the rise, we will now require 20% of the proposal deposit to be set on submission (200 JUNO at time of writing). These spam proposals offer fake airdrops and are phishing for users’ wallet addresses by creating a mock up wallet interface. This will deter malicious actors from clogging up the proposal system and ensures only quality proposals are submitted on chain.
Should you wish to make a proposal, but don’t have 200 Juno, reach out to a member of the core team or Sub-DAOs for assistance. The minimum deposit is meant to deter spam, not participation!
Latest CosmWasm (v0.30)
Authzzzzzzz — PR #387
This version includes the following features (as outlined from their article)
- Authz module integration
- Store and instantiate gov proposal
- Allow gov votes to upload larger wasm bytecode
- Stargate Queries
- Get Contracts by Creator Address
- Support instantiation permission > chain permission for gov store
Packet Forward Middleware
Ware? Middleware — PR #387
Along with our upgrade to IBC v4 (from v3), we are also implementing multi-hop packet routing for ICS-20 transfers. This is done by appending an intermediate address, and the port/channel identifiers for the final destination. Allowing clients to outline more than 1 transfer at a time.
IBC Wasm Hooks
❤ from osmosis — PR #473
The osmosis team brought in their x/ibc-hooks module to allow for the transfer of tokens, and contract execution in the same IBC message (via IBC Memos in the v3.4.0 upgrade). This now improves user experience for cross chain applications in the cosmos.
IBC-Fees (ICS-29)
Relayers Rejoice! — PR #432
Relaying is permission-less, but does come with some operational costs such as infrastructure, time, and fee costs. This addition of the ICS-29 spec (IBC-Fees middleware) is added to incentivize relaying packets from other chains to Juno and distribute those fees to relayer operators.
You can read more about the details from the ibc-go team’s documentation
A lot of great additions are coming to Juno in v13, starting off the new year strong! We look forward to seeing new dApp products being built on Juno which leverage FeeShare and the Oracle.
Don’t miss out on future cutting-edge developments! Twitter: Juno Network
