Dev Log no.8
Disclaimer: Information as of Jul 5. For the most recent updates, dive into our comprehensive documentation here.
Welcome to the 8th edition of our dev log. Here, we bring in-depth updates from the Composable team covering, Picasso, Centauri and the XCVM.
We are working on pre-production environment deployment for the Halborn audit and setting up our internal logging and monitoring systems for Mosaic phase 2. For Picasso, our team is working on specifying the token rewards for liquidity provisioning on Pablo and providing price feeds on Apollo. Previously, we refactored the staking rewards approach for Pablo and all of our native tokens. Similarly, we are working on defining the oracle inflation approach for Apollo. Meanwhile, our cross-chain bridging team is working on the NEAR light client implementation and posted their work as a proposal for the NEAR team to review and approve. Configuring the Mosaic relayers for Substrate implementation remains the focus for the team moving forward. Ensuring this is safe and secure is the key stage before moving on to prod deployment.
Picasso
As an L1 focused on cross-chain DeFi, Picasso will host several DeFi pallets upon launch, including the Pablo DEX, the Apollo oracle, Mosaic, and in the longer term Angular, a lending/borrowing protocol. For each of them to function properly and contribute to the Picasso ecosystem, we need sound economics to encourage participation and ensure that the incentives are sustainable for Picasso. In previous dev logs, we have covered how we have specified staking rewards on Pablo. Similarly, we have also started reviewing the rewards for oracle operators on Pablo.
To recap, Apollo is implementing a staking/slashing mechanism, a first among oracles. Operators are required to stake a sufficient amount of PICA to submit prices, and they will be rewarded/slashed based on how close their price submitted is to the median. We start the design of the rewards with a set of requirements the rewards mechanism must fulfil, which are:
- An oracle provider must earn an economically viable reward for submitting a price for a given pre-configured asset type
- Picasso governance must be able to adjust the possible reward based on the economic factors such as infrastructure costs, demand/supply for oracle services, opportunity costs in staking capital
- Picasso governance must be able to budget PICA emissions allocated for the oracle. Picasso must avoid a situation where the Treasury runs out of funding for Apollo or other crucial pallets and the crucial infrastructure services are interrupted.
Based on these requirements, we are creating the inflation (or emissions) model, which caps the inflation rate at a maximum per year but also varies when there aren’t enough oracles participating in the network compared to the ideal expected. In addition to this overall model, out of the available rewards budget, portions would be allocated to each asset type based on its perceived value to the network.
In the background, the team continues to finish the latest implementation of the staking rewards pallet. The refactoring of the pallet allows for a much more effective user experience; it has added additional QA checks across most of our existing features and pallets to ensure safe and stable compatibility. We continue to progress with deployments to the staging environment and, therefore, integration testing, end-to-end QA, and external audits. The next step is to deploy the Mosaic relayer to testnets and configure APIs/subgraphs in testnets.
Trustless bridging
We are leveraging components built for the Centauri bridge (which connects DotSama to Cosmos) to develop a trustless bridge to the NEAR. It will be a key contribution to the future of cross-ecosystem communication for DeFi. We have submitted a NEAR proposal, NEP-364, to get the community’s support to make some changes to the NEAR protocol’s runtime, which will enable running a Polkadot light client, following the IBC’s standards, possible. The proposal covers three aspects:
- NEAR runtime to support more signature schemes to speed up signature verification
- NEAR realtor to include a state-proof with our IBC pallet to prove that data is shared are valid
- NEAR runtime to allow for transaction validation in batches
Response from the NEAR core team would help us validate our approach and allow us to implement the light clients once approved. While waiting for a response, we are continuing with testing and development on our side, most recently implementing a NEAR light client that can run on the Picasso parachain. The light clients on Centauri are being tested on the Picasso and Cosmos chains to ensure that they track the final states of the other chains correctly, meaning the light client on Picasso to track the finality of Cosmos chains or the light client on Cosmos chains to track finality on Picasso.
XCVM reveal at Composable Unchained
A highlight for us has been meeting with the community and industry leaders at two seminal events in Berlin, Polkadot Decoded and Composable Unchained. As you may know, Unchained is our first Composable-hosted event, and we brought together leading builders from Ethereum, Cosmos, and Polkadot to discuss the future of interoperability and composability.
We hope you found this dev log edition valuable. As always, feel free to reach out to us on Discord with any questions or feedback.
For more information about Composable and how it is architecting the unified DeFi landscape of the future, check out our socials:
Twitter | Telegram | Discord | Website | GitHub | LinkedIn | Youtube
