Gm PRQties! 🖖 Last week we announced our first Unicorn Workshop which will be hosted by Ivan this Thursday (Sept 21st 6pm UTC) where you can learn more about how to use Tsunami API and even use the PARSIQ SDK to build your own Data Lake! (Custom API) 🛠 But before that we’ve got some important info to share, so for any #BUIDLers planning to join the workshop just check out this blog post And don’t forget to sign up with this link for a chance to win a free Tsunami Pro subscription! 🎁 Hope to see you all there!

Working with the operations team on alternatives now on $XCHF on @defichain 's Quantum. Will share updates later this week.

Take a peek behind the development veil behind the upcoming MetaChain Layer: In this post, we explain the development process and provide some answers to some common questions 👇 In software development, new releases usually follow this roadmap: Alpha → Beta → Release Candidate (RC) → Stable Node. While most projects typically begin with an alpha stage, DeFiChain went with a different tack by cycling through a series of beta phases to emphasize new feature rollouts. What is a RC and what is the timeline of an RC? A Release Candidate (RC) is designed to resemble a release’s final versions, primed for deployment without needing further modifications, while still allowing for flexibility on improving any other software testing. As exchanges and affiliated programs require sufficient time for updates, an RC should ideally perform optimally over a span of 10 to 14 days. Should any version not meet these standards, it must be left in the beta domain. When will there be a stable node rollout? When stability is confirmed, the roadmap projects the launch of the release candidate before releasing a TestNet enhancement within 2–3 days. Once stability is confirmed across all integrated systems and services, DeFiChain will switch gears and focus on the launch of the stable node, culminating in a hard fork after a predefined waiting period. What are the current blockers? The standardized nature of the EVM and its associated integrations means they must adhere to specific operational guidelines. This becomes cumbersome when attempting to dovetail it with pre-existing systems, such as those rooted in Bitcoin. The MetaChain Layers's journey echoes these complexities, where the goal is to assimilate a raw-space virtual machine with DeFiChain. Obstacles are abound when attempting to integrate the EVM with a UTXO-centric blockchain. These include varying hash generation techniques or state alterations beyond typical transactions. Additionally, the DeFi Virtual Machine (DVM) presents a unique set of challenges. While having a pristine codebase as the starting point is ideal, the reality is that DVM, derived from a Bitcoin-centric codebase, has evolved with multiple layers over time. Also, DeFiChain’s codebase harnesses the power of two primary languages: C++ and Rust. While Rust boasts compile-time safety to flag potential errors before compilation, integrating it with C++ presents obstacles. These challenges also spill over into "endianness" and system-level data storage. Another dimension under evaluation is the "transfer domain." Traditional blockchain transactions operate on a "push" mechanism, verifying asset ownership and transferring it. However, the stringent architecture of the EVM doesn't facilitate a direct push from EVM to DVM. An alternate "pull" method is under exploration, demanding new ways to prove ownership without exposing private keys. Generally speaking, the team is facing these primary challenges: 👉 Addressing endianness and aligning hashes with standards. 👉 Seamlessly merging Rust and C++ without compromising stability. 👉 Achieving success in all unit tests. 👉 Instituting secure "pull" transactions 👉 Developing blockchain explorers tailored for Ethereum Virtual Machines (EVMs) We hope this offers clarity on the current state of the MetaChain layer. For a comprehensive insight, check out our detailed article here: https://blog.defichain.com/metachain-blazing-ahead-tech-talk-with-u-zyn/