Mycel Blog

APPLICATION

Introducing Astraeus: A New Era of Cross-Chain Asset Transfers with Mycel

# Introducing Astraeus: A New Era of Cross-Chain Asset Transfers with Mycel  Today, we are thrilled to announce the launch of Astraeus, a pivotal milestone in the Mycel ecosystem that marks a new era in cross-chain asset transfers. Designed with interoperability, privacy, and decentralization at its core, Astraeus provides a robust framework for synchronizing state machines and securely transferring assets across multiple blockchains. ## What is Astraeus? Astraeus is Mycel’s latest proof of concept that showcases the potential of Transferable Accounts using the [SUAVE](https://suave-alpha.flashbots.net/). Astraeus integrates Trusted Execution Environments (TEEs), decentralized cryptographic verification, and cross-chain communication, creating a seamless bridge between otherwise fragmented blockchain ecosystems. The Astraeus release represents the first public demonstration of Mycel's capabilities, laying the groundwork for a decentralized infrastructure that facilitates secure and frictionless cross-chain asset transfers. ## Key Features of Astraeus Astraeus represents the foundational stage of Mycel's architecture, focusing on the implementation of Transferable Accounts. This phase is centered on establishing the core functionality that allows assets to move securely and efficiently across different blockchain platforms. - Transferable Accounts with SUAVE: In this phase, the Transferable Account system is prototyped and tested within a controlled environment using SUAVE. The goal is to establish a reliable mechanism for moving and managing assets across different blockchain platforms. - Interoperability Testing: During this stage, initial tests are conducted to ensure that Transferable Accounts can operate smoothly across various blockchain platforms, validating the concept of cross-chain asset management. ## Architecture Astraeus introduces a secure and decentralized infrastructure for managing Transferable Accounts on top of SUAVE. The architecture focuses on enabling the creation, transfer, and management of accounts in a confidential, transparent, and efficient manner, while leveraging key components like Kettle, MEVM and SUAVE. Components of Astraeus Architecture - SUAVE Kettles: a network of actors that provide confidential computation for SUAPPs. These all operate in Trusted Execution Environments (TEEs). - Confidential Data Storage: a private place to store data (e.g. user transactions). - SUAVE Chain: a public place to store data (e.g. intentionally leaked information) and SUAPP logic (e.g. deployed smart contracts). MEVM: a modified EVM that exposes confidential computation and storage APIs to developers  ### Account Creation and Transfer In the Astraeus system, Alice (the initial account holder) starts by creating a Transferable Account that can later be transferred to another user (Bob). This process is facilitated by SUAVE and involves several key steps: 1. Create Account and Approve Transfer: Alice creates a request to create an account. The account is created in the Confidential Data Store within the MEVM layer of the SUAVE Kettle. The account creation process includes an approval step, where Alice grants permission for the account to be transferred to Bob to the application like DEX. 2. Generate and Store the Account Key: Once the account is created, the MEVM generates an account key and securely stores it within its Confidential Data Store. This account key is critical for signing transactions and managing the account. The key remains hidden and is only accessible under specific conditions, ensuring security and privacy throughout the lifecycle of the account. 3. Publish Public Key: The public key of the newly created account, along with the account ownership details, is published on the SUAVE Chain. This information is stored transparently on the chain, which maintains a record of ownership, approvals, and other account-related metadata (e.g., lock duration and transfer permissions). 4. Transfer Ownership: After Alice approves the transfer to the application (suchas order flow auction), the application verifies the transfer conditions which are the account balance, the lock duration, and approvals. If the conditions are met, the ownership of the account is securely transferred from Alice to Bob by updating the state on the contract on SUAVE Chain. ### Interaction with SUAVE and Signing Transactions Once the account has been transferred to Bob, Bob can use the account for transactions. SUAVE and the MEVM architecture facilitate this interaction securely and privately. 5. Request Signature: Bob initiates a transaction and requests a signature from the system to authenticate the operation. This request is sent to the SUAVE Kettle, which manages the confidential storage and execution environment. 6. Ownership Verification: Before generating the signature, the SUAVE Chain verifies that Bob is the current owner of the account. This verification involves checking the ownership information associated with the account. 7. Sign and Send Transaction: Once ownership is verified, the MEVM retrieves the account key from the Confidential Data Store, signs the transaction on behalf of Bob, and sends the transaction to the blockchain for execution. ## Getting Started with Astraeus Developers and users eager to experiment with Astraeus can start exploring its capabilities through Mycel’s API endpoints and documentation. This initial release serves as a proof of concept, providing a glimpse into the future of decentralized cross-chain asset management. Let's get started from here [https://docs.mycel.land/develop/astraeus/get-started ](https://docs.mycel.land/develop/astraeus/get-started ) ## Looking Ahead: The Future of Cross-Chain Interoperability The launch of Astraeus is just the beginning. As we continue to develop and enhance the Mycel ecosystem, future iterations will introduce more advanced features, greater scalability, and additional integration points with other blockchain platforms. Astraeus showcases the power of Transferable Accounts and the potential of a decentralized, intent-driven cross-chain ecosystem. By combining trusted execution environments, decentralized verification, and the flexibility of intent machines, Astraeus sets the stage for a more interconnected and accessible blockchain world. ## Join Us on This Journey We invite developers, users, and the broader blockchain community to explore Astraeus and join us in building the future of cross-chain interoperability. The road ahead is filled with possibilities, and we’re excited to have you be a part of this transformative journey. Learn more about Astraeus and Mycel: [https://docs.mycel.land/overview/architecture/astraeus](https://docs.mycel.land/overview/architecture/astraeus)

SECURITY

Introduction to Transferable Account

## Introduction Mycel is a decentralized platform that enables the transfer, management, and trading of accounts across different blockchain platforms. By creating a “Transferable Account,” which combines their own account with a threshold signature scheme (TSS) signed by Mycel, users can: - Exchange assets across different blockchain platforms. - Transfer assets across various smart contracts and rollups. - Buy and sell accounts tied to specific activities. As of 2024, with the emergence of Layer 2 solutions and various blockchains, users are required to maintain accounts for each environment, making management increasingly difficult year by year. By using Mycel’s Transferable Account, users can manage their assets across various platforms safely and efficiently. In this article, we will explain what Transferable Accounts are in detail, and how they are designed to ensure the security of users’ assets. ## Overview of Transferable Account Mycel’s Transferable Account (TA) is a specialized account structure designed to facilitate secure cross-chain asset management and transfer. TA operates using multisig, ensuring that both the user and the verifier (Mycel) jointly manage the account. This design ensures that no single entity can arbitrarily manipulate the account or its assets, thus maintaining decentralization and enhancing security. The Transferable Account is capable of handling various forms of assets, such as those represented in account balance format on Ethereum or in UTXO format on Bitcoin. It serves as a gateway that enables transactions between assets across all chains.  ## System Using Transferable Account ### Conducting account exchanges using Mycel  If Alice wants to sell BTC on Bitcoin and acquire ETH on Ethereum using Mycel, she will follow the steps below: 1. Deposit BTC into the designated Bitcoin account and submit an Intent to Mycel - Alice sends BTC to the Bitcoin address specified by Mycel. - Alice submits an Intent, specifying ETH as the asset she wishes to acquire. 2. Resolution of the Intent and transfer of assets - The submitted Intent is processed by a Solver, responsible for matching and executing the swap. - The Solver prepares the required amount of ETH in an Ethereum account for executing the swap. 3. Verification of the transfer - Mycel verifies whether the necessary amount of BTC is present in the Bitcoin account where Alice made the deposit and whether the required amount of ETH is available in the Ethereum account prepared by the Solver according to the Intent. 4. Updating ownership - Once it is confirmed that the necessary assets are present in each account and they have been confirmed for a certain number of blocks, the ownership of the respective Transferable Accounts (TA) is exchanged. As mentioned earlier, the TA is managed by a multisig controlled by both Mycel and Alice. By using both signatures from Alice and Mycel’s service, the authority as a signer on the TA that Alice owned is updated to another user, thereby transferring ownership of the TA. If you want to learn more about Intents, please refer to the article below. [https://medium.com/@mycel/understand-intents-fully-in-just-8-minutes-8c95ccfb55a1](link) ### FROST: Implementing Transferable Accounts with Threshold Signature Scheme Until now, accounts generated with multi-signature (multisig) schemes could not change their signatories. If the signing party for a multisig account was changed, the public key and corresponding address of that account would also change. However, by adopting a threshold signature scheme known as FROST (Flexible Round-Optimized Schnorr Threshold Signatures), it is now possible to update the signing party’s composition without changing the multisig account’s public key or address. With FROST, an account managed by Alice and Mycel can be created on Bitcoin, and this multisig account managed on Mycel becomes a Transferable Account (TA). If Alice wants to send BTC to Bob, instead of executing a BTC transaction on Bitcoin, the signing party managing the TA is changed from Alice and Mycel to Bob and Mycel. This allows BTC to be transferred without actually executing a transaction on Bitcoin. If Alice wishes to stop managing BTC on this TA, she can withdraw the BTC owned by the TA to a Bitcoin address specified by her at any time. This withdrawal process requires signatures from both Alice and Mycel signatories. Of course, the system is designed so that Mycel cannot withdraw assets from the TA on its own. ## Conclusion In this article, we explained the overview of Transferable Accounts proposed by Mycel and how they work. We hope that by understanding the TA mechanism, readers can join us in thinking about the new ecosystems that can be created with this innovation. Mycel will continue to provide innovative experiences leveraging TA. If you’re interested in this project, please join our official Discord through the link below. Additionally, if you’re interested in Mycel’s development, feel free to contact us. Official Discord: [https://discord.gg/mycelland](link) Official Twitter: https://x.com/mycelmycel ### Reference Mycel Docs [https://docs.mycel.land](https://docs.mycel.land) Frost [https://eprint.iacr.org/2020/852.pdf](https://eprint.iacr.org/2020/852.pdf)