In November, we announced our intent to support our corporate mission and encourage network decentralization through a new delegation approach. But to summarize, starting January, we’ll be delegating a proportion of our ada holdings across a range of community stake pools. Our goal? To support positive social change and continue building a more robust, resilient, and geographically distributed Cardano network.

Today, we’re delighted to take the first step in delivering on this strategy by opening our first call for applications. From today, we’re inviting eligible stake pool operators (SPOs) to consider applying. This is an evolving program, and we will refine it over the year ahead. But initially we are encouraging SPOs to gauge their eligibility for a delegation award based on these criteria:

1. IOG will run two programs: one for ‘Incubator’ pools and another for ‘Purpose’ pools.

Incubator pools will be selected based on more ‘technocratic’ criteria. We’ll focus on pools that are performant and competently run by skilled operators who have invested a decent amount of pledge (or invested heavily in the ecosystem) but have struggled to attract delegation. Again, these are guidelines rather than hard rules; we’ll also look positively upon lower pledge pools with clear technological skill sets that contribute to the ecosystem.

Purpose pools will be selected according to the mission and purpose driving them. We will delegate to pools driving positive change by offering educational opportunities, supporting a charitable endeavor, committed to sustainable eco-friendly energy, etc. Or they might be driven by the desire to increase awareness and adoption of Cardano by hosting a stake pool centered on a developing country, holding blockchain meetups, creating non-English language Cardano/developer content, and many other options. Ultimately, it is up to each pool to state the positive change they want to make and how delegation can help them achieve that goal.

2. IOG will select up to 100 stake pools each quarter and delegate between 3 and 4 million ada to each pool. There will be 4 cohorts/selection processes per year (one every 3 months)
3. While we will not discount larger, more established operations, we will prioritize smaller pools (less than 5M ada/with low saturation) for the Purpose pools.
4. We will monitor the block production rate across any pools we delegate to. We want to support skilled SPOs that are committed to deliver on the task their delegators have entrusted to them.
5. We will show a strong preference to SPOs that run single pools. Any operator running multiple pools will need to demonstrate how they are adding community value by doing so. Failure to declare multiple pools at application will result in ineligibility to receive delegation.
6. We will aim to delegate to a variety of new stake pools each quarter. We are focused on encouraging success and autonomy, and we will change our delegation when we are confident that the pool can continue to operate successfully without our support, or a quarter has passed. Unless exceptional circumstances arise, no pool will receive delegation for longer than 6 months.
7. We will delegate on the basis of trust. We look for the same from SPOs and expect them to be transparent in all their dealings and how they represent themselves. We reserve the right to withdraw delegation without notice from any SPO making false or inaccurate claims about their eligibility for delegation. We will look for SPOs that are transparent with their costs and charge appropriately for them. In the short term, you may be prepared to invest your time and energy ‘for free’ (or at an effective loss, after hosting costs), but remember that this is not a sustainable model for the network over the medium and longer term. You are a pillar of Cardano and so you have every right to be compensated by the community.

8. We will seek community feedback as we develop the process to help us both refine program mechanics and the choices we make. Community members are welcome to raise any particular concerns about delegation choices. However IOG reserves the right to make delegations in line with its ongoing decentralization strategy and changes to the program can be made at any time.

Building a decentralized, empowered, self-sustaining and self-governing ecosystem lies at the heart of our mission for Cardano. If 2020 was about laying the foundations of Shelley, 2021 will be about building upon that success through community opportunity and empowerment. Ultimately, our success is down to community and the protocol. But with this new delegation strategy, we hope to play a small but important role in helping to establish the stake pool ecosystem as a blockchain network unlike any other. Power pushed to the edges, skilled and empowered to support and accelerate all the exciting opportunities the future will bring.

We encourage any SPO who feels they meet the above criteria and would like to apply to do so through this form. We’ll also reach out directly to a number of pools we have already identified as strong candidates (based on their community contribution during 2020) and encourage them to apply. We’ll keep the application form open until the end of this year and review applications in early January, with a goal to make the first delegations by the end of January.

Ethereum, custom (user-defined) tokens are implemented using smart contracts to simulate the transfer of custom assets. Our approach with Cardano does not require smart contracts, because the ledger itself supports the accounting of non-ada native assets.

Another difference is that Cardano’s multi-asset ledger supports both fungible and unique, non-fungible tokens without specialized contracts (similar to those required by ERC-20 and ERC-721 tokens). It can store a mix of both fungible and non-fungible tokens in a single output.

Cardano’s native tokens framework is based on four principles:

• lightweight
• affordability
• security
• unified process

Lightweight

The native token framework is based on a multi-asset ledger structure built around token bundles (values), A token bundle can contain a heterogeneous mix of ada and other tokens. These token-containing structures are stored in outputs on the ledger instead of ada, as previously. Each type of token is identified by its asset ID, which includes a hash reference to its minting policy. The minting policy itself is only ever checked during minting or burning, and is not itself stored on the ledger, which makes this approach quite lightweight.

The fungibility relationship is also captured by the asset ID in a lightweight way: tokens with the same asset ID are fungible with each other, but not fungible with those with a different asset ID. Unique tokens have a quantity of exactly 1 associated with their asset ID.

The asset ID identifies each type of token within a single token bundle and across the whole ledger. It also identifies the token’s place in the internal two-level map structure of the token bundle. This internal data structure enables fungible and non-fungible tokens to be represented uniformly. It also gives great flexibility to the kinds of asset use cases that can be tokenized in the system. It is straightforward to represent, for example, timeshares of a single piece of property, or a selection of unique pieces of art scoped under a single minting policy controlled by the artist.

The inherent simplicity of native tokens is further highlighted when we look at how transferring assets between two contracts works in Ethereum’s ERC-20. In this situation, smart contract code is required, which adds complexity, and with it room for error and cost. The structure of token bundles offers a rather lightweight approach to asset transfer, because different types of token can be transacted in a single transaction, with greater speed.

Affordability

In an ERC-20 token environment, transferring any number of tokens between two peers requires the execution of a smart contract, which carries an execution fee (gas). By contrast, in Cardano’s native multi-asset ecosystem, the transfer of assets (tokens, ada, custom currencies, etc) does not require a smart contract, and does not carry any execution fee, which means greater affordability.

Security

Native tokens feature a more lightweight and less costly design than that of Ethereum’s ERC-20 and ERC-721 standards. But these two features would mean nothing without a robust security layer to guarantee the integrity of the system.

In native tokens, system integrity is built around the ledger property of value preservation (that is, that the sum of all the inputs is equal to the sum of the outputs). All native token transfer logic is coded in the ledger, as opposed to user-defined smart contracts. This ensures predictable and uniform behaviour of the system, and does not require users to understand smart contracts, which can often be a point of vulnerability.

While accounting correctness is ensured by the ledger, minting and burning of tokens is regulated by their user-defined minting policies. A minting policy is permanently hash-associated to the tokens scoped under it, and there is no way to change this policy. This guarantees that the policy an issuer chose can never be changed to allow minting or burning of this type of token which was not authorized under the original policy. Whenever a minting transaction is added to the ledger, the policy for each type of token being minted is checked and must be satisfied. Each token in circulation, except ada (as Cardano forbids minting additional ada), necessarily has a minting policy and is guaranteed to have been minted according to that policy.

Therefore the only custom code required to manipulate tokens in Cardano is the policy itself. Tying the policy hash to the asset identifier means that there is no need for a global asset registry, so creating assets is cheap and easy. The system remains simple, lightweight and easy to use.

Unified process

When native tokens are implemented as part of Goguen, the ledger will handle all tokens in the same way. And minting a token can only be done in one way, to reduce ambiguity and possible mistakes or bugs. This simplification in using a unified process will lead to faster development and a better development experience overall.

Pre-production environment incoming

Native token capability will be deployed to the Cardano mainnet following a protocol upgrade in Q1 2021 (known internally by the working name, ‘Mary’) opening up a new world of use cases and opportunity. To onboard new developers ahead of this date, we’re now finalizing the deployment of a pre-production environment for native tokens. So stay close to our social channels for the very latest news on deployment.

If you are a developer and want to get involved early on, visit our developer site, where you can get supporting documentation and resources. We’ll add to this over time; sign up to our developer survey on this page to express your interest and be alerted as soon as everything becomes available.

IOHK has a long association with Ethereum Classic (ETC) and its community, which preserves an untampered history free from external interference and subjective altering of transactions. Serving as the next-generation digital currency platform, ETC is built as an intuitive programming platform, which allows developers of all skill sets to build the next wave of market disrupting decentralized applications (DApps).

The goal of ETC is to securely and methodically establish a strong ecosystem underpinned by solid foundation and core immutability. However, recent 51% attacks have put the ETC ecosystem into a precarious position, denting its confidence and challenging the community’s ability to address this issue, while representing an existential threat to its future viability.

Driving innovation & future growth for ETC

New Mantis is the only client that is written natively for Ethereum Classic and it offers unrivalled levels of assurance, security, and usability. IOHK has relaunched the Mantis project to mitigate against the recent attacks, provide enhanced security, and establish a robust means of interacting with the ETC chain. A commitment to fostering innovation and sustainability lies at the heart of the project. We are aiming to provide a steady funding income with the establishment of a proto-treasury to nurture future development and growth. This Mantis re-launch represents the culmination of a project that we've been working on for some time. Over the past few months, we have resurrected our code base, and gathered a dedicated Mantis team together who have worked hard to refine and improve the code and deliver important new features.

What is the Mantis project?

Mantis is a project that is built for the community, specifically designed for the developers, wallet users, and infrastructure providers to enable direct interaction with the ETC blockchain. Essentially, it is a place where future development can evolve and be tested by the community. The Mantis release includes the following components:

• Mantis client - a CLI tool that connects to other clients in a peer-to-peer manner to allow users to communicate with the ETC chain, send and receive transactions, sync the blockchain data, execute and validate smart contracts, and deploy new smart contracts on-chain.
• Mantis wallet - a node wallet with incorporated graphical user interface (GUI), which connects to both mainnet and the Sagano and Mordor testnets.
• Mantis faucet - enables developers to receive testnet funds for use on the Sagano and Mordor testnets.
• Mantis explorer - allows tracking recent activities and transactions in regards to the ETC chain, covering the ETC mainnet, and Sagano and Mordor testnets.

Please visit the Mantis website where you can download the latest version of both the Mantis client and wallet.

Mantis software implements the official Ethereum Classic specification and Ethereum Classic Improvement Proposals (ECIPs) introduced by ongoing efforts and discussed across teams in the ecosystem. The project has undergone a number of enhancements in terms of adding robustness and variety to the client offering, including optimizations and network upgrades that improve network security, sustainability, and performance in the long term. It has been developed from the ground up and built in 100% Scala code, a functional programming language that offers security guarantees that other languages do not. Mantis features include stable peer discovery, pruning, fast synchronization, and newly implemented checkpointing (for 51% attack resistance) and proto-treasury (for long-term sustainability). Let’s take a closer look at these features.

Checkpointing

Persistence and liveness are two crucial properties that a transaction ledger should possess. It is a proven fact that both persistence and liveness suffer when the adversarial mining power in the proof of work surpasses 50%, and in the recent year, ETC has undergone several double-spending attacks prompted by the creation of large chain reorganizations. Considering that persistence and liveness were not guaranteed within the ETC network, we sought to implement protocol changes that will re-establish persistence and liveness under current network conditions, and checkpointing is one of the proposed solutions.

Checkpointing ensures that the protocol is unaltered, by using the k parameter, or depth parameter, where every k block gets irreversibly "checkpointed", meaning that no one can ever drop or revert it. A trusted authority can choose the block on which to issue a checkpoint, which means that they can decide which block becomes the canonical chain that all parties should follow. This trusted authority must run continuously and is responsible for publishing the checkpoint to the network. Checkpointing ensures that the protocol is unaltered with regards to mining. The mining rewards are not affected and the checkpointing federation can only issue checkpoints on blocks that have valid proof of work and cannot mint blocks on its own.

Checkpointing is now implemented within the Mantis project, and according to our recent ECIP comparison for 51% attack resistance, it provides far greater, and importantly formally proven, security against these types of attacks. It is important that any 51% attack mitigation is truly robust enough to give absolute certainty to ETC holders, users, and service providers that their transactions will be secure.

Proto-Treasury

For the longer-term health and success of the ETC ecosystem, we position network growth, sustainability, and innovation as key elements to ensure network security. With that in mind, we are implementing a proto-treasury system within the Mantis project to establish a steady funding income. A well-developed governance strategy will enable effective, distributed funding for the long-term development of Mantis, whereas a decentralized treasury would ensure two important things for the future of the ecosystem:

• Firstly, it would provide a permanent ongoing source of funding for the ETC network. while increasing the value of the ecosystem and promoting greater developer engagement.

• Secondly, it would provide a distributed and transparent funding mechanism, which lets the ETC community determine its future growth and enable the sustainability required for innovation and growth.

Establishing the treasury for funding purposes ensures a clear vision of the substantial system maintenance focused to obtain innovation and diversity from other projects, including proof of stake (PoS) and newer blockchains. This solution is straightforward in its optimization for speed and implementation.

The proposal foresees to distribute 80% of existing mining rewards to miners and 20% to the proto-treasury smart contract. The treasury will be controlled by the community and will enable a decentralized, collaborative decision-making process, offering an opt-in type collaboration for those who are interested.

What’s next?

As much as we’re excited about the Mantis relaunch, it should be stressed that its capability won’t be limited to just the features outlined here. Mantis is an evolving project and right now we are establishing its foundational building blocks and running rigorous security audits. Further down the road, it will see more performance improvements in terms of CPU, GPU and ASICs compatibility, a new proof-of-work consensus protocol and algorithm introduction (PRISM consensus, Keccak256 algorithm) and, of course, additional enhancements for better interoperability and speed of transaction processing. You can also find out more by reading the Mantis documentation and joining the Mantis discord to stay up to date on all things Mantis or Ethereum Classic. Check out the Crowdcast launch event for the full Mantis showcase (and a keynote from Charles Hoskinson) and follow the Mantis team on Twitter to get the latest updates!

It all began in the ether. Ethereum was launched in July of 2015. Bitcoin had been around for six years by then, but the whole cryptocurrency world still remained a niche affair.

Bitcoin was designed (and so it remains today) purely as a digital currency. When Ethereum came along, it had a solid ace up its crypto sleeve: smart contracts, right out of the box. This meant that third-party developers could build their own applications and run them in a decentralized manner on top of the Ethereum blockchain. Ethereum trumped Bitcoin with better marketability and more versatility.

Smart contracts enabled the creation of user-defined tokens on the Ethereum blockchain. Fungible Ethereum tokens could be developed with the ERC-20 standard, while unique, non-fungible tokens were created under the ERC-721 framework. However, user-defined Ethereum tokens (both fungible and non-fungible) carried an inherent inefficiency: they required the creation and implementation of custom code because the Ethereum chain did not offer native token support.

Tokenization in brief

Let’s remind ourselves of the purpose and value of tokens. Tokenization can be defined as the process of substituting a sensitive data element with a non-sensitive equivalent. This non-sensitive equivalent is referred to as a token and it has no extrinsic or exploitable meaning or value. Simply put, tokenization is the process of turning things into digital assets.

This approach offers distinct advantages: reduced transaction costs, transparency, enhanced liquidity, decentralization, and increased efficiency, to name a few. In itself, tokenization is a highly versatile feature that opens the path to achieving many commercial objectives. This utility stems from the fact that tokens are programmable, so they can be made unique.

For example, tokens can be programmed to grant the holder access to exclusive content, custom merchandise, or even a stake in voting. The actual purpose of the voting process is irrelevant. Ultimately, tokenizing the ability to vote gives participants the feeling that they are part of something larger than themselves, and they can have their views represented in it.

Tokenization can be used to create financial products and economic models. Examples can be envisaged in fields as diverse as collectibles, alternative investments, gift cards, sports betting, in-game assets, commodities, and much more. This has the potential to connect real world goods, services, and activities to the digital space.

Turning things into digital assets, the Cardano way

Goguen introduces a mechanism whereby tokenization is handled natively. That is, the logic is based on the Cardano ledger, rather than smart contracts. By taking this approach, we are able to implement an efficient tokenization strategy that is superior to the ERC-20 and ERC-721 standards supported on the Ethereum blockchain.

User-defined tokens on the Ethereum chain (both fungible ERC-20 and non-fungible ERC-721 tokens) are non-native, that is, the underlying ledger does not directly support these tokens. That is because tokens created with ERC-20 and ERC-721 standards are fundamentally different from Ether, the cryptocurrency native to Ethereum.

The Cardano approach to tokenization enables the representation of custom assets on the blockchain without the need for smart contracts, and also enables those assets to behave in a similar way to the principal currency, ada, except that:

• native tokens can be created and destroyed, unlike ada.
• ada is the only currency that can be used to service fees, rewards, and deposits.

Native tokens, some terminology

The terms 'coin' and 'token' are often used in the crypto world. Sometimes, these terms are interchangeable, sometimes not. And sometimes, 'token' is a sort of umbrella term that encompasses all digital assets.

It is worth making a finer point here. Cardano's approach to tokenization is as unique as the ledger itself, so here's some terminology to help understand the native tokens framework.

In Goguen/Cardano:

• A token is defined as the representation of an asset stored on the Cardano blockchain
• An asset is anything that can be quantified
• A token bundle is a representation of multiple tokens
• Native refers to token logic running on the Cardano ledger, rather than using smart contracts.

Native tokens on Cardano

Ethereum requires custom code for user-defined tokens to be supported on the chain; this adds a layer of complexity, cost (gas is needed to pay for the execution of the code), and inefficiency, since token code for both standards is replicated and adapted, rather than being part of the system itself. This is an inherent weakness of the Ethereum chain, because it leaves room for human error. Custom code, if done sloppily, can introduce bugs that could potentially lead to great financial loss. In one particularly infamous incident, software bugs led to the loss of ether worth $300m. The Cardano approach aims to prevent such catastrophic errors.

Cardano supports user-defined tokens natively, that is, without the need for custom code, through the native tokens framework. Native tokens is an accounting system defined as part of the cryptocurrency ledger and enables tokens to be transacted with (tracked, sent and received.) This eliminates the need to use custom code or costly smart contracts. In short, native tokens remove the unnecessary layer of expensive complexity and inherent inefficiency found in the Ethereum chain.

Why are native assets necessary on Cardano?

Cardano is a distributed ledger. Typically, when a distributed ledger is designed, it can only track a single asset type (its own cryptocurrency, for example.) But as the ledger evolves in terms of further decentralization, the need and possibility of tracking multiple types of assets using the same infrastructure becomes apparent, which is why many blockchains can support multiple assets such as stablecoins, utility tokens, credential tokens, and security tokens.

Native token functionality extends the accounting infrastructure defined in the ledger model (which is designed for processing ada-only transactions) to accommodate transactions that use different types of assets simultaneously.

Native tokens on Cardano have advantages over ERC-20 and ERC-721 tokens, in terms of security and affordability. In the next blog post, to be published tomorrow, we’ll dig down into this as well as outline how developers can get involved in the months ahead. For now, visit our Cardano documentation site, where you can access supporting documentation and resources.

Cardano’s development has been conceived as a journey involving five overlapping development themes, each of which is underpinned by a consensus protocol – Ouroboros. As Cardano evolves, the protocol must also change as fresh functionality and utility are brought onto the platform. Upgrades require gradual changes to the network protocol and in this article, we will explain how these protocol changes are implemented and what goes on behind the scenes to make this process smooth and straightforward.

Reducing complexity in protocol changes

In the crypto world, any fundamental change to the blockchain protocol is referred to as a hard fork. In most blockchains, a hard fork is a ‘traumatic’ event that causes a – hopefully short – break in block production. In contrast, Cardano handles hard forks automatically, without stopping block production. This gives a uniquely smooth upgrade process that allows new features to be introduced easily and evolve the platform’s capabilities.

Traditionally, when a hard fork event occurs, the current protocol stops operating. All block producers upgrade to a new version of the software that implements the new block production rules or other changes. Having done this, the chain history is erased and block production is restarted. This means that a hard-forked chain will be different from the previous version, which can raise concerns over the integrity of the blockchain, or even lead to splits in the chain.

With Cardano, we do things differently

The way that Cardano implements protocol changes is completely different from the way other blockchains handle hard forks. Our goal has always been to make these changes as seamless as possible. To enable a smooth transition, Cardano automatically preserves the history of previous blocks. This allows the protocol to be upgraded without radical interference to the chain. The previous state does not vanish. Rather, it is extended to include new capabilities. Instead of splitting into two different chains, Cardano combines the original blocks that comply with the current block production rules with new blocks that comply with the new block production rules.

We have christened the mechanism that does this the hard-fork combinator since it combines protocols without triggering interruptions or forcing a restart to Cardano. The Byron to Shelley transition used this technique for the first time. But the crucial point here is that Byron’s chain history did not disappear. Byron and Shelley chains appear ‘as one’, where the Shelley blocks extend the chain that was produced in the Byron era. Shifting from Byron’s Byzantine Fault Tolerance consensus protocol (OBFT) to Shelley’s Ouroboros Praos did not require block production to be stopped or all the nodes to update simultaneously. Instead, nodes could update independently.

As Cardano and Ouroboros evolve, the hard fork combinator approach ensures that Goguen, Basho, and Voltaire blocks will all be held in a single chain. Features will be added at each stage in successive hard forks. Some new features may not even need a hard fork (where the consensus protocol does not change).

The advent of token locking

Token locking is a feature in the next protocol update that we are now preparing to deploy on mainnet. Internally, we are calling this development stage Allegra (named after Lord Byron’s daughter). Alongside the integration of metadata on the network, this is the next significant upgrade for Goguen.

This represents a relatively small technical change to the consensus protocol, with a slight impact on the actual ledger. However, it is significant since it will prepare the platform for smart contracts and the creation of assets (in addition to ada) that run on Cardano. It also provides an important piece of Voltaire (governance) functionality, supporting a voting mechanism. Underlying this are system changes to ensure that we can continue to develop through future hard forks.

Token locking is a way of recording that a specific token is being used for some purpose. By token, we mean the items that are counted by the blockchain ledger. Until now, there has only been ada, but soon many other custom tokens will be able to use the Cardano platform. Locking, in this case, means ‘reserving’ a certain number of tokens for a specified period of time so they cannot be disposed of to gain a benefit (such as voting, or running a smart contract).

We can compare this with earning dividends from shares. A person who buys shares in a company might be rewarded with a dividend from the company’s profits. Let’s assume that this dividend is paid at the end of each calendar year and requires the shareholder to have held their shares for the entire year. If they were to sell some of their shares at the end of November, they would lose all the dividends for those shares for that year. They have entered a conditional contract with the share provider that gives them something of value (here, a dividend) in return for holding a specific token (here, a share) for a certain period (in this case, a full calendar year).

Enabling complex smart contracts

Token locking is essential to enable complex smart contracts, and to support certain conditions, for example, when making a purchase. Thus, when someone enters into a contractual agreement to sell a house, a promise is made by the vendor that this house won’t be sold to another person – only to the person who actually pays the money. So, the token can represent the house in this case, whereas the ‘promise’ will be the actual token locking. If the house is sold to a third party, the promise in the contract will have been broken and any penalties will be invoked. This precise functionality will become available to contract providers with the introduction of token locking, using ada coins as the tokens. The ada may still be delegated to a stake pool as usual.

Within the Voltaire mechanism – which will be first used with Project Catalyst Fund2 voting – those ada holders who wish to participate in the voting process will need to ‘lock’ some ada. This will represent their voting rights, according to the amount of ada that they lock. It will prove that individuals have a certain number of votes, and eliminate the possibility of any votes being counted more than once. An individual cannot allocate more votes than they hold, or vote on contradictory ideas, or duplicate the votes.

How is this implemented?

The introduction of token locking will happen behind the scenes. It will not affect the experience of ada holders because Daedalus and Yoroi wallets will automatically be updated without requiring any action from ada holders.

However, to implement the updated version of Ouroboros that will support token locking, all the nodes that run the network will have to ‘agree’ on it (that is, reach consensus). To achieve this, stake pool operators and exchanges that are running nodes will simply have to download the new version of the code and check its operation. IOHK’s development teams will support stake pool operators and monitor the network throughout this process to ensure that the transition goes smoothly.

Once token locking is running on the mainnet Cardano ledger, subsequent hard forks will introduce multi-asset and other smart contract capabilities. These will also be able to use token locking, opening up many new possibilities for Cardano users. In time, this will also lay the groundwork for creating non-fungible (unique) tokens on the Cardano blockchain.

IOHK’s innovative hard fork combinator has given Cardano a secure, smooth path to regular protocol updates – each bringing fresh value and utility to the network while minimizing disruption and risk. We’re in the final stages of quality testing and will start the testnet deployment process this month, with an expectation of moving to the mainnet around the middle of December. During 2021, there will be more upgrades using the combinator – multi-asset support is coming up – as the Cardano platform continues to fulfill its potential. Stay tuned for an exciting year.