2021 Rewind

MELD

We have finally come to the end of 2021 – the first year in the MELD journey with over three quarters of insane activities and development. This report summarizes the technical progress of MELD in 2021 and what we can look forward to in 2022. More details will be posted in their dedicated posts next year.

Let us start with the more community-driven works before getting to the core of MELD.

Cardano

MELD’s mission is to bring secure, efficient, and low-barrier-to-entry financial services to the mass. Such a mission is technology-agnostic by definition, and we will do whatever is best towards that goal.

For now, MELD started as a Cardano project and is determined to stay so in the foreseeable future. Early platforms take time to mature so we have to practice patience more than expected. Nevertheless, as eager developers, we did enjoy the daily challenges. We also prefer to develop from principles and treat products as profound works. As such, being early in Cardano allows us to stay closer to the core progress of the ecosystem itself.

In 2021, we mainly contributed to Plutus when we could afford the time. We hope to be even more active, supportive and organized in 2022 with frequent discussions with the core Plutus team themselves. We have also studied Hydra to understand the keys to isomorphic state channels, to contribute to Hydra and design our own variants for MELD. Like Plutus, we have met the IOG scalability team and expect more technical workshops in the future. We want to be one of the first Hydra users, build it with the whole community, and propose own variants in Q1 2022.

We have also spent some effort trying to master Ouroboros but it has not gone far given our current deadlines. We expect to resume Ouroboros and more topics in 2022 to join more intriguing challenges in the consensus, ledger, and node works.

Dependency Updates

The Cardano codebase has been moving very fast! We frequently test our projects with the latest updates to evaluate and help fix breaking changes when possible. A few samples:

A few breaking APIs require some reasoning, but following Git history and GHC compile errors are sufficient most of the times. The process is also not that involved to learn more about these different Cardano components. That said, it is still nice to test our software with newer dependencies and help contribute when possible. We expect to continue this work when opportunities arise in 2022.

Better Developer Experience

We have to confront the truth that developing on Cardano, or any young ecosystem for the matter, is brutal. Cardano possesses further challenges given its not-very-industry-friendly technical stack. It is sometimes challenging to get the right things up, even for experienced Haskell and Nix engineers. It gets way worse for our interns and newcomers to the ecosystem. The relatively high system requirements and lack of documentation do not help either. A few detailed pain points can be found in input-output-hk/plutus-apps#180 Plutus on Hackage/Stackage.

As an ambitious R&D-driven effort, we have to recruit and train many engineers to work in the Cardano ecosystem. A few brilliants have refused to join or given up so far. While we cannot tell the exact reasons, we believe it would be easier to convince them if the developer experience was better, i.e., to help them feel more productive with their time and talents. After all, there are still many good opportunities outside of MELD and Cardano for these bright minds.

As a result, we are determined to help improve the developer experience on Cardano. The main two lines of work are tooling and documentation, with better development environments a nice place to start.

For instance, we have been trying to make plutus-apps thinner for dApp developers to at least build faster:

Trying to make plutus projects easier to build outside of patched GHCs:

With a few efforts here and there to improve stack support, as Nix has a steep learning curve, resource-intensive, and sometimes have flaky behaviours outside of NixOS and Linux.

Some documentation efforts:

We have also seen many positive movements both from the Plutus team like in:

And from the community like in Plutonomicon/plutonomicon. We are excited to join hands with these greats and build a more developer-friendly ecosystem together. Hopefully, this time next year, anyone can quickly spin up a development environment to iterate on dApp ideas with confidence, thanks to better tooling and documentation. Then with a stable and efficient environment for prolonged development comes even more greats to the ecosystem.

PAB & Chain Index

We have been using, customizing and contributing to PAB since March. Our wildest customizations were in the PAB 1.0 days with the Plutus Playground UI. We even had a customized Chain Index tracking application-specific data and serves them cleanly through custom GET endpoints. We still remember fondly how input-output-hk/plutus#2801 PAB v2 nuked everything (for the better, of course!) and how we slowly transitioned to Emulator traces when new Plutus updates were desired.

From that point onward, we became a lot more careful with our customized tooling and tried to contribute upstream more. Here are a few examples:

Regardless of the contributions, we have spent more time on emulator traces this year for core contract works and would need more time to master PAB for off-chain integrations. We have been stacking exciting ideas to propose to the Plutus team. Our primary focuses are better setup, API, and documentation for PAB users and better runtime performance.

We are expected to serve millions of users in 2022 (Tingo users alone are in millions) and integrate with many banking services, so we naturally have high demands for performant off-chain integrations. Learning from the PAB v2 destruction in April, we would love to do most PAB work directly upstream. We are also ready to roll our own solutions with Elixir and Rust when high performance is required. The best part is that all these solutions can still be integrated.

Plutus Script Size

Cardano currently has a tight transaction size limit, and for good reasons. However, this limitation makes it hard for dApps to include many scripts in a single transaction for composability and clarity. We have faced many challenges representing complex application logic within the current limit and had to resort to hacky or semi-trustful designs at times. The aftereffect is that dApp development is very inefficient and error-prone. Sometimes we feel like spending most of the time reasoning about security properties, contract architectures on UTxO, ad-hoc script size optimizations instead of working on actual application logic. It is not the end of the world, but an apparent overhead when expanding dApp functionalities and inviting more builders to Cardano.

Therefore, we are determined to contribute anything upstream for smaller script sizes. The near-future goals are to represent more logic, handle more data in validator scripts, and fit sane code well to remove the need for hacky solutions. A longer-term goal is to support state machines for better abstractions, analysis and faster development. We have discussed a few on-chain solutions internally and will start proposing when we have more time in January. For now, we slightly prefer compiler optimizations so that no hard-forks nor node updates are required, and improvements can be made locally and flexibly in a single project’s scope. A few examples:

We still need more time to get comfortable with Plutus and its compilation pipeline. We are looking forward to a new year full of studies, contributions, and sharings within the tight Plutus ecosystem.

Hydra

We have studied most Hydra materials and joined many Hydra conversations this year:

There is still a long road until Hydra can scale dApps, and we want to help push it there. We will continue the conversations internally, with the Hydra team and the community, and cannot wait to contribute PRs and propose our variants. We are also developing those variants on Nervos. Exciting time ahead!

More Core Works

In 2022, we would like to venture into more core works like with the ledger, consensus, and node to better understand Cardano and design the best solutions accordingly.

We have, for example, had a Plutus suggestion implemented at the ledger level for Plutus v2:

Important: Reading redeemers in script context to make validation rules more concise and scripts smaller was Duy’s idea. kk-hainq in the above issue was just the delivery boy.

It has also been several months since Dat and Quang proposed two general solutions to the concurrency challenge here. Many difficulties on layer-1 prevent these general solutions from functioning as intended, and ad-hoc optimizations are still preferred on Cardano at the moment. Since then, we have learned a lot more to polish and improve the proposals next year.

Haskell

Haskell plays a vital role in the Cardano ecosystem as the primary programming language in the technical stack. Cardano seems to attract several engineers, us included, for its use of Haskell in production. That said, it is more or less apparent that there are still many pain points in using Haskell for large-scale projects. The main problems are the relatively small community, limited tooling, the difficulty in recruitment and training, compile-time, runtime performance, and resource requirements. These are not impossible to handle, but it might worth trying to improve the situation at source if we choose to run the marathon with Haskell.

With that in mind, we have attempted to work on our first GHC work as suggested by the Haskell Foundation:

We hope to help make GHC error outputs more structured for tools like HLS to utilize directly instead of parsing raw text outputs. It went fine for a while until we simply failed to allocate any time for it. Hopefully, with the upcoming waves of engineers in 2022, we can be a bit more active on this front.

As our difficulty list suggested, our primary focus at the moment is to make Haskell development more practical, especially to newcomers that we hire and train. Apart from tooling like the above GHC work and sub-library dependency support in stack, we are also interested in making compile-time faster, reducing resource requirements, and improving runtime performance through better garbage collection or something. Then maybe in five years, we can start working on the beautiful type system and more theory-heavy works like that.

Nix is also an ecosystem we are interested in contributing being central to the Cardano ecosystem and heavily used by many of our technical partners. That said, similar to Haskell; we might love it dearly on paper but have also suffered several pain points using it in practice. When resources are still limited, we would probably avoid Nix for a while more.

It is important to note that Haskell is not our go-to language. We choose what makes sense for each specific purpose. Rust and Elixir will also be core in 2022, with hard opposites like Python and Javascript where appropriate.

Hachi

MELD has helped fund Hachi entirely up till now. We need dedicated security research to achieve our dApp ambitions for the MELD protocol and the greater Cardano ecosystem.

Here is a quick summary of what Hachi did in 2021:

  • General:
    • internal documentation, experiments, and public blogs on Plutus and blockchain security.
    • a few Plutus libraries and tooling here and there.
  • A Plutus chain index customized to sync security-relevant data from the chain.
  • Different grammar formats and transpilers for Plutus Core that target Scheme, Racket, LLVM IR, WebAssembly, C, Javascript, Python, and more.
  • A Plutus Core playground where one can edit and evaluate Plutus Core in the browser.
  • Plutus Core analysis tools, like attempting to infer type for core terms. It is undecidable in theory, but there are practical cases where type inference at the core level is very useful.
  • Racket-based tooling:
    • Concolic execution on top of Rosette.
    • Instrumentation for Plutus Core.
    • AFL++based fuzzer.
    • AFL-based concolic execution fuzzer.
    • Symbolic execution for transpiled Plutus Core.
    • Plutus’s built-in functions in Bigloo.

Big thanks to Quang, Quynh, Nicholas, and Michael for that list!

Hachi has also had a warm demo with IOG and got invited to further seminars and meetings as a result. We are looking forward to connecting Hachi to more auditors like Runtime Verification and CertiK, on top of the current partner in Tweag. It is fascinating to see researchers getting together for profound works on a new ecosystem. Both MELD and Hachi would love to be a part of that.

As an ambitious venture with a different focus, Hachi is expected to separate and grow on its own from August 2022. We can think of it as the Plutus repo split with Hachi being plutus and MELD being plutus-apps. Different goals and structures but benefit from each other to thrive!

Please visit Hachi’s blog for more information. 2022 will be an exciting Hachi year with the first wave of products and more focused directions.

ADAmatic

We want to thank Obsidian Systems, especially Rune and Tom, for their consistent ADAmatic bridge work!

Since September, the earliest version of mADA has been deployed and tested on Mumbai at 0xc70a3cd8ff5775d27e79f106f30fe94ff8186768. The latest iterations moved all tests to local private testnets on both sides for more reproducibility and consistency. More features, optimizations, and auditing are still required, but we expect the first public testnet launch in January.

It is important to note that the first testnet version of the bridge will be centralized and custodial without smart contracts. It is a deliberate choice to first focus on the core of the ADAmatic node and how it interacts with the Cardano and Polygon nodes. We expect another public testnet launch with smart contracts and multi-signatures, with more decentralization and dApp integration proposals before the mainnet launch.

We are also completing the first public White Paper of the bridge from internal specification with more dedicated articles in general. Hang tight and prepare your Cardano and Polygon wallets!

MELD

In alphabetical order, we would like to thank An, Dai, Dat, Dong, Duc, Duy, Frane, Huong, Ivan, Ivo, Karlo, Mario, Marin, Matej, Matija, Quang, Robert, Tam, Thanh, Thuy, Trung, and Tuan for their intricate and inspirational work in 2021. We cannot wait to add Binh, Hoang, Hrvoje, Sasha, Thanh, and many more next year.

Let us summarize some of the core works done this year before going into more details in the following dedicated posts.

ISPO

We have executed the world’s first large-scale ISPO at the peak of over a billion dollars worth of ADA in delegation. It was a huge commercial success without requiring much work on the technical side, showing just how good ADA staking is out of the box. That said, we still made a few technical mistakes when dealing with the pool tickers, KES keys, impersonations, ISPO dashboards, and more. While we only keep one MELD stake pool after the ISPO, the gained experience is still precious going forward as we collaborate with more SPOs to continue innovating on ADA staking. Dashboard difficulties also raised awareness around the importance of efficient and stable chain synchronizers and any off-chain solutions for the matter.

At the moment, we already have all the ISPO data on-chain to prepare the airdrop on January 31st 2022. We will soon complete an audit and open-source the codebase and all ISPO data.

For more information, you can read the intro to the ISPO here, and the outro here.

MELD NFT

MELD is not an NFT project. That said, due to the high demand from the community and relatively mature tooling for NFT on Cardano, we started an NFT program called bank managers for the ISPO participants.

At a high level, anyone who has participated in the ISPO can claim an NFT and evolve it by solving MELD challenges. People can transfer and trade the NFTs like any other native assets. MELD holders can stake MELD with the NFT for better yield at launch. The higher the level of the NFT, the higher the yield. More high-level information can be found here.

At a lower level, we focus on the principles like a script-based minting policy with an on-chain guarantee for NFT uniqueness. We also require the ISPO participants to pay to script-based vending machines instead of the project’s wallet. A more centralized solution might be easier to implement, batch, and execute in general. Nevertheless, we want to push for decentralization on the most mature front of Cardano dApps. We will have better batching when we have better script sizes. It would also be interesting to monitor Cardano’s performance during the high time of minting requests. More details and the codebase will be published in the upcoming weeks leading to launch.

We also have a special NFT for the ISPO diamond hands, which are more or less badges with no further utility. Or is there? We will announce more soon enough!

Smart Contracts

We have designed and implemented several contracts in 2021, including vesting, staking, mFiat, lending, liquidation, governance, and experiments for ADAmatic, concurrent and deterministic batching, and more. Few have passed our quality requirements which resulted in the initial delays. As we grow with the UTxO ledger model, we have also developed brand new architectures to replace early models inspired by account-based ledgers like from Aave or Liquity. Several layer-one limits block the elegant and decentralized designs we demand in our contracts. Large-scale migrations are also not yet well-studied and supported on Cardano. Therefore, we have only signed off vesting and locked staking in 2021. We have been patiently experimented with and innovated more core contracts alongside Cardano’s and our growth.

For instance, we question the account-based state-driven DeFi that we know today. The intuition is that an asset is only liquid in the specific service it is deposited to, making the whole model capital-inefficient by default. Instead, we would like to redefine DeFi on highly parallel, multi-layered decentralized economies on the UTXO ledger. The nuance is that an asset can be lent or traded simultaneously. Then the total amount of borrowable and tradable assets can reach the total amount of assets in the economy.

As a result, we are not rushing the core products. While a fiat lending license is already in reach, we are still several months away from being able to lend fiat legally. Launching principle works after another hard fork or two would also benefit significantly from more layer-one improvements. The current focus is then on a successful genesis and first launch that incentivizes early MELD holders. Then we stay tight to get the most out of Cardano, Plutus, and Hydra to finalize the best products one can offer next year.

The current key components are:

  • Decentralized protocol fees, to be integrated with ADAmatic and more.
  • Variable staking to withdraw rewards from protocol fees.
  • Liquidation specialized for UTxO.
  • Stablecoins specialized for UTxO.
  • Lending & borrowing specialized for UTxO.
  • Governance specialized for UTxO.
  • Integration with scaling solutions like Hydra, a MELD sidechain, and more.

For the vesting and locked staking contract that we are launching on January 31st, here is an audit report from Tweag. In general, the contracts are straightforward, with no vulnerabilities found thus far.

As a final note, we are unhappy with ourselves for the massive time spent on re-designs, reasoning about security properties and contract architectures on UTxO, ad-hoc optimizations to reduce script sizes, and ad-hoc scalability solutions in 2021. Our primary goal in 2022 is to better formalize solutions and plans, and work with the whole community on tooling so that everyone can spend more time on actual application logic. The engineering team has been growing well towards the end of 2021 and are optimistic about further organized improvements.

We also plan to publish much more writing on contract architectures specialized for the UTxO ledger and the concrete designs of MELD contracts in 2022.

Economics

Given our determination in helping make tooling and documentation better on the engineering side, we hope many people, regardless of background, can write dApps well in the future. On the other hand, economics modelling is relatively harder to generalize and has lower demands for tooling. In truth, all dApps need some engineering tooling, while not all are financial products nor need complex economics. Therefore, building an outstanding economics team is critical to MELD and will soon be a competitive edge over other projects in the same area.

Our economics works are principled, research-driven, and math-heavy, so we only summarise what has been done in 2021 here. We will publish much more dedicated writing in 2022.

For 2021, the team have:

  • Had many brainstorming sessions on varied topics, from economics designs for MELD core products, ADAmatic, other popular DeFi applications like DEX, to game theory for layer-two solutions like Hydra and ADAmatic.
  • Run training sessions for engineers on economics, finance, and the mathematics involved.
  • Written a decent amount of internal documentation. Although much more is required to match our ambitions.
  • Modelled vesting, staking costs and rewards with detailed analysis on investor and staker behaviours, expectations and token pricing.
  • Forecasted MELD economics on lending (without vesting). These include lending and borrowing rates, MELD token price, revenue growth, total locked value, costs of incentive scheme, and more.
  • Discussed a better inflationary economy for MELD v2 in 3-5 years.
  • Modelled ADAmatic economics with basic assumptions from similar projects. A lot more data is required to iterate on improvements.
  • Worked on market-making frameworks and buyback plans to protect the MELD token price and its holders.
  • Worked on different investment models to further utilize the project’s capital.
  • Built simple data pipelines for centralized exchanges.
  • Proposed many new lending, stablecoin, exchange, and economics designs in general.

Our number one difficulty is building the data team that, in turn, builds efficient data pipelines and warehouses for the Quant researchers to backtest their models. While most models have already been simulated in one way or another, nothing is close to constant live data from the platforms that we are on. On this note, as we see more dApps launched on the Cardano mainnet, we are starting to have real-life DeFi data, which is a lot better than where we were six months ago. We cannot wait to serve the researchers the data they need and to see lively data pipelines from a Cardano node straight to the economics models and dashboards.

Another important task in 2022 is for the engineers to further study economics, finance, and mathematics and for the researchers to study blockchain and Cardano to better communicate and co-design products. Our ambitious projects do require harmonized depths from both worlds.

MELDapp

Our number one mistake in 2021 was to have a Zagreb team and a Vietnam team working separately under different management and cultures. As weak leaders, we unconsciously considered the Vietnam team more core as they had more workload in the early days and worked on the more internal components of the products. For that reason, the blockchain and economics teams there have received a lot more care and support to thrive. On the other hand, the MELDapp team in Zagreb did not have the best working environment, got vague requirements, late feedback, and more. Having to handle imprecise yet unrealistically high demands with unstable tooling on Cardano, the team had to work under tremendous stress, and the MELDapp got delayed again and again. I am utterly ashamed and sincerely apologize to the MELDapp team and all of our users for it.

As a solution, we have been erasing the boundaries between the teams to unify management and cultures. We also have core researchers and engineers in Canada, Europe, and Singapore at the end of the day.

Furthermore, UX is our number two criteria right behind security. The MELDapp is expected to be installed in millions of devices in 2022 through partnerships like with Tingo. With the current toolset on Cardano, scalability solutions for off-chain components serving that traffic are not trivial. Our soon integration with banks and other fiat services would be brutal as well. There is no reason why the MELDapp team is not as core as the blockchain and economics teams, and absolutely no reason why we should not brainstorm to kill challenges together.

For now, we are hurrying to finalize the first version of the MELDapp to serve launch. Nami and Metamask integrations for Cardano, Polygon, and Ethereum wallets work. We also have a built-in Cardano wallet as another option. Integration with the ADAmatic bridge, vesting and staking contracts are being hurried on. There are still unfinalized designs due to overly detailed requirements and late feedback. However, given the current timeline, we also consider going with what we have first, to iterate on designs with user feedback afterwards. At least most UI components have been built now.

Everything is long overdue, but we do expect much more progress soon given the management and working cultures change. Again, sincere apologies to the team and all of our users who have been looking forward to the MELDapp. The intention of a UX-first application has not changed since day one, and we do owe everyone such a product for the many years to come.

Conclusion

2021 has been a foundational year in MELD history. We have made several mistakes and learned many priceless lessons. From that, we are determined to make significant improvements on all fronts in 2022.

As an R&D-driven effort, we are incredibly grateful to our researchers and engineers for trusting the best years of their careers with us. In return, we must build a better working environment for them to innovate in 2022, and with that comes the great products that all MELD users deserve.

Last but not least, we would like to thank the researchers and engineers from these organizations:

  • IOG: for laying the foundation for us to build on and for the patience reviewing our issues and PRs (especially the Plutus team).
  • Tweag: to the Tweag engineers at Hachi, the auditing team, and the Plutus team for doing much cool stuff with us.
  • Obsidian Systems: for our (you do most of the work thus far, but well…) work together on the ADAmatic bridge.
  • MLabs: for your massive contributions to the Plutus ecosystem. We are three letters and one space more but always jealous of your resourceful team. May our road cross some time next year.
  • Well-Typed: for your huge contributions to the whole ecosystem. May our road cross next year.
  • SundaeSwap: for your early pushes and displays through the difficulties.
  • Maladex: for your exciting ideas. Hopefully, we can explore more together next year.
  • Nervos: for your fantastic RISC-V support, layer-2 driven works, and tooling with Rust. Our resources have been limited this year, but we hope to build tons with you in 2022.

That is it. Happy new year, everyone! Let us build many great products for the users in 2022!