Skip to main content

Tools Concept

The Birth of JunoTools​

JunoTools started its journey as JunoDrop, as an idea to generalize cheap airdrops and make them accessible to everyone that's required to spin a project or a DAO.

The change to the concept of a more generalized tool started when our team realized that JunoDrop became a website that wraps cosmos messages and passes them to Keplr for you to sign. Actually, that's what a dApp is, easy and shiny UIs to wrap transactions for you to sign.

This realization quickly revolved our ideas and raised the following question:

What if we approach smart contracts UIs like protocols?​

Be it CW20, CW721, CW1, or CW-DAO, all of these are protocol specifications. These protocols define what to expect as input messages and specify the methods you can execute on them.

For example, CW20 on Juno and Osmosis expect the same inputs and are capable of doing the same actions given they use the same CW20 version.

Thanks to the protocol specifications, we can have a generalization here.

RAW is a CW20, SSCRT is a CW20, sLuna is a CW20. They accept the same inputs, so then why not have a generalized contract UI standard across different networks so that the overhead of learning and using a new UX vanishes.

JunoTools, OsmosisTools, StargazeTools, or xTools. You can interact with CosmWasm chains through a common UX with just different chain-based UI themes.

Smart Contract Dashboard​

Smart contracts dashboards are intentionally named CW1 and CW20, not Token or Mint.

That's because interacting with a CW20 token is like operating a car. The car is engineered and built to run, you don't need to know every detail of the machine to drive it but you need to read the manual shipped alongside the car. The interface is the steering wheel and the dashboard.

Smart contract dashboards are just HTML data input forms for you to build the pieces together and start the execution.

Use Cases​

Let's explore the idea with a use case example.

Your organization structure runs on a blockchain using smart contracts.

You have a sub-team of a DAO, with the rights to execute the payments.

You want to make a streaming payment from the DAO treasury to a third party. Since the treasury owner is the DAO, you need to form a JSON formatted smart contract message and put it into the proposal. In case the proposal passes, the transaction will be executed.

Either the DAO app can handle the CosmJS integration to the payment contract, but this UX design is not scalable.

Creating and operating a smart contract process includes several steps and its complexity is best handled by an external tool.

With such a tool, you can open up a category called CW-20 and select Streaming Payment from a drop-down then fill in the inputs you want to execute through the contract. At the end you will be given an option to copy the transaction without broadcasting, you will simply pass the copied transaction to the DAO app and open a proposal.

The process above executes a single message, with further development there could be a Transaction Builder sidebar where you drag and drop to be executed messages to a sidebar to run batches operations.

Roadmap​

The possibilities we see for the tool's future are the following:

  • Move web2 infrastructure to Akash
  • Support Snapshots
  • Implement a UI kit for easily launching the same tools experience for other Cosmos chains. Currently, we are exploring the idea of a port to stargaze or more chains.
  • Explore the setting up of a standard for chain-wide pinned code governance.
  • Transaction Builder, a simplified and no-code transaction builder based on drag and drop boxes.
  • JunoTools DAO, as we don't want to be the gate holders to what contract dashboards must be on the UI. The community, through the DAO, should be included. The DAO voting could be a token distribution or technical lead teams of the network.