With the ‘Mary’ protocol upgrade, which will be implemented using our hard fork combinator technology, native tokens and multi-asset capability are coming to Cardano.

On February 3, we upgraded the Cardano public testnet to ‘Mary’ for final testing. We plan to deploy the Cardano update proposal to mainnet on February 24, which would therefore deploy ahead of the boundary of epoch 250 and take effect on March 1. If we need a few more days of testing, we'll deploy ‘Mary’ the following epoch instead, which will take a five-day period required for updates to take effect. ‘Mary’ has been successfully running on our testing environments for several weeks, so our confidence level remains high. As always, however, we’ll follow a strict process (developed and honed over the previous Shelley and Allegra HFC events) to get this right.

Once the code is successfully deployed to mainnet, we’ll release a new Daedalus Flight version for user testing, which will be our first Cardano wallet with integrated multi-asset capability. Once we are happy with wallet performance and usability, we’ll deliver the Daedalus mainnet release bringing the full-fat native token experience to every Cardano user.

Why native tokens?

Native tokens will bring multi-asset support to Cardano, allowing users to create uniquely defined (custom) tokens and carry out transactions with them directly on the Cardano blockchain.

The use of tokens for financial operations is becoming ever more popular. It can cut costs at the same time as improving transparency, enhancing liquidity, and, of course, being independent of centralized entities such as big banks. Tokenization is the process of representing real assets (eg, fiat currencies, stocks, precious metals, and property) in a digital form, which can be used to create financial instruments for commercial activities.

Cardano will provide many tokenization options. With the ‘Mary’ upgrade, the ledger’s accounting infrastructure will process not only ada transactions but also transactions that simultaneously carry several asset types. Native support grants distinct advantages for developers as there is no need to create smart contracts to handle custom token creation or transactions. This means that the accounting ledger will track the ownership and transfer of assets instead, removing extra complexity and potential for manual errors, while ensuring significant cost efficiency.

Future and utility

Developers, businesses, and applications can create general purpose (fungible) or specialized (non-fungible) tokens to achieve commercial or business objectives. These might include the creation of custom payment tokens or rewards for decentralized applications; stablecoins pegged to other currencies; or unique assets that represent intellectual property. All these assets can then be traded, exchanged, or used as payment for products or services.

Unlike ERC-20 tokens that are based on Ethereum smart contracts, the tracking and accounting of custom tokens on Cardano is supported by the ledger natively. Because native tokens do not require smart contracts to transfer their value, users will be able to send, receive, and burn their tokens without paying the transaction fees required for a smart contract or adding event-handling logic to track transactions.

Working with native tokens on Cardano

In creating an environment for native tokens, we have focused on simplicity of working, affordability, and, of course, security.

Depending on their preferences and technical expertise, users will be able to choose from three ways to create, distribute, exchange and store tokens:

• Cardano command-line interface (CLI). Advanced users can currently access the CLI via a dedicated testing environment. We will deploy the CLI on the mainnet when we hard fork.
• A ‘token builder’ graphical user interface (GUI). This will follow the native token CLI launch, providing an easier way for creating tokens.
• The Daedalus wallet. Daedalus will provide support for sending and receiving custom-created tokens. Daedalus Flight will test native token functionality in March, which will be shortly followed by the mainnet release.

Let’s dig down a little into each option.

Working with Cardano CLI

Advanced developers can use the native tokens testing environment to create (mint) assets and send test transactions to different addresses.

The nature of working with the CLI assumes that someone is familiar with setting up and operating the Cardano node, and has experience in working with transactions and managing addresses and values. To create native tokens using Cardano CLI, one would need to:

• Set up and start the Cardano node
• Configure a relay node to connect to the native tokens testing environment
• Start interaction with the network (prompt Cardano CLI)
• Construct a monetary policy script
• Create tokens using the monetary policy script
• Finally, submit and sign transactions to transfer tokens between addresses.

Native token tutorials and exercises are available on our Cardano documentation site to help developers mint tokens, create monetary policies, and learn how to execute multi-asset transactions.

We are already seeing particular interest from stake pool operators for this. So far, hundreds of test tokens have been created, and we continue to improve the CLI based on feedback. We welcome your comments and encourage community testing.

Token builder: a user-friendly GUI for token creation

The CLI requires a certain level of development prowess. So we have devised other ways for less technically proficient users to create tokens. To achieve this, we plan to launch a token builder after the mainnet CLI launch.

The token builder is a graphical user interface that makes token creation easier. If you’re interested in creating tokens for your decentralized application, wish to tokenize your property, create NFT collector cards represented as specialized assets, or want to create a stablecoin pegged to the value of other currencies, the token builder can help with that.

To create a token you would just need to fill in:

• The token name (eg, Hello World)
• The token symbol (eg, HEW)
• The token icon (generated automatically)
• Amount to create (eg, 1,000)
• Cardano wallet address (your address to host newly created tokens).

The token builder generates the monetary policy automatically – you won’t need to define it yourself. This streamlines the token creation and simplifies it for a non-technical user.

Figure 1. The prototype token builder dashboard

Initially, the token builder will be supporting only fungible token creation (while non-fungible tokens can be created using Cardano CLI). In time, we’ll extend the functionality to allow creating non-fungible tokens and changing the monetary policy according to specific preferences. This means that users will be able to specify the conditions under which tokens are minted (or burned), or who has control over the asset supply, for example.

Finally, when tokens are minted, it will be possible to mint more by clicking the ‘Mint more’ button. This can be done based on the same policy to create more tokens of the same kind, or you can create other tokens that represent different values based on a different policy. For example, you can create more Hello World tokens, or, starting from scratch, you can create 500 ‘test’ tokens that will be used for other purposes (these will have a different minting policy).

The token builder aims to reduce the complexity of token creation and also focuses on the enhancement and visual presentation of functional processes. As an outcome, we aim to provide visibility around all the tokens created, their values, quantity, and addresses between which they are being transferred – all in one place.

Daedalus

Those users who do not wish to create their own tokens but who want to use existing ones for payments, purchases or exchange, will be able to use such wallets as Daedalus, and later Yoroi.

The Daedalus team continues to work on integrating the wallet backend with the user interface to support the native token functionality. Users will be then able to hold native tokens in their wallets, send and receive them as they would do with ada.

Native tokens are uniquely identified by two hexadecimal numbers stored on-chain ‒ the Policy ID and the Asset Name. Considering that these numbers are not 'human-friendly', we have created fingerprints for easier identification of native tokens by users. Fingerprints are 44 character long alphanumeric strings beginning with the prefix 'token'.

Additional token data displayed in the wallet UI (name, description, and acronym) will be provided by the Cardano token registry, administered initially by the Cardano Foundation.

Figure 2. Daedalus native tokens UI

Native token lifecycle

When all the necessary components are deployed, the native token lifecycle will be complete. It consists of five phases:

• minting
• issuing
• using
• redeeming
• burning.

Figure 3. Native token lifecycle phases

During these phases, asset controllers will be able to define the policy for the asset class and authorize token issuers to mint or burn tokens. Token issuers can then mint tokens (for applications, for instance), maintain their circulation, and issue them to token holders. Finally, token holders (eg, individual users or exchanges) will be able to send tokens to others, use them for payment, or redeem them when they have finished using them.

What’s next?

We launched the testing environment in December 2020, laying the foundation for native token development. We also added a staging environment to enable initial testing by exchanges and stake pool operators. It features a faucet and allows a network of nodes to be built while connecting to the relays.

Follow our Cardano status updates to see our weekly progress. As we expand the capabilities of the native tokens, and add tools and interfaces, we’ll be providing documentation and tutorials to encourage people to get involved. Naturally, the codebase is open source and we have already seen a number of interesting community projects emerge (around digital collectibles, for example).

So a lot will be happening in late February and early March, from final testing and the HFC event, to native tokens on Cardano within a brand new Daedalus wallet experience. Exciting times ahead!

Find out more by joining other community members to discuss native tokens in the Cardano Forum's dedicated native token section. And don't forget to sign up for our devnets program.

Additional technical input by Olga Hryniuk.

Portrait of Mary Shelley by Richard Rothwell (1800-1868)

The Goguen rollout continues with another key building block in Cardano’s evolution into a decentralized, multi-asset (MA) smart contract platform. The Goguen ‘Mary’ update – named after author Mary Shelley – introduces the ability to create user-defined tokens. These custom tokens will be ‘native’, so they can be transacted directly on the blockchain, just like ada. While ada will remain Cardano’s principal currency, Cardano will transform into a multi-asset (MA) blockchain, opening up a constellation of possibilities. This MA capability will become a fresh development fulcrum for developers worldwide, further widening Cardano's reach and potential.

Another hard fork?

Yesterday, using what was effectively a hard fork, we successfully deployed the Mary update to the Cardano public testnet, for final testing prior to mainnet deployment. This forking event is a crucial step in the process, as the Testnet is as close an environment to the Mainnet as we can get. Once we deploy all the elements on the Testnet, invite devs to dive in and monitor the results, we can accurately ascertain how the Mainnet will behave.

Hard forks tend to be disruptive events because the history of the pre-forked blockchain is no longer available. Without careful planning, testing, and execution there can be unintended consequences. Earlier blocks can be lost when the protocol rules are altered, for example.

However, Cardano handles hard fork events differently. We use a hard fork combinator to combine protocols without triggering service interruptions or a network restart – and, crucially, the combinator maintains the history of the previous blocks.

Cardano has undergone several development stages, and the quest is far from over. Goguen is happening now. We’re seeing the early steps toward Voltaire now with Project Catalyst, and Basho will follow. Each stage brings Cardano's journey closer to its ultimate destination: True decentralization and scalability, utility, and sustainable governance. And each stage will use the combinator, a tried and tested technology, to power the transition. We first used it for the Byron to Shelley upgrade, proving the combinator's effectiveness in achieving a seamless transition. Allegra, which introduced token-locking in December, used it, too, as will Cardano’s next development stages.

How we got to Mary

The advent of token-locking with Allegra, though a relatively small technical change to the Ouroboros protocol in itself, established the threshold for Cardano's multi-asset strategy, and the network's future as a whole. The change readied the platform for smart contracts and the support of native assets other than ada.

Allegra laid down the foundations for Mary with the introduction of production-ready code so engineers could start testing. This work covered features such as defining a monetary script, minting, redeeming and burning tokens, and sending tokens in a transaction.

Just before the holiday break, a programming interface (command line interface -CLI) was added for the wallet backend. Since then, updates for that wallet backend and interface, along with explorer support for multi-currency blocks, have been underway.

We are now finalizing the integration of the completed wallet backend with the metadata registry, and the Rosetta API (a common interface for exchanges to interact with the Cardano blockchain) will be updated to support multi-assets.

The metadata registry

The concept of metadata is worth explaining here. In Cardano, metadata is a description of the native assets that people can read. These assets are stored on-chain using identifiers which are non human-readable. The readable version of this information is stored off the blockchain, in public token registries. These registries – initially managed by the IOG – will ultimately be owned and be configurable by the community, thus enabling another layer of Cardano's decentralization goal. By empowering the community to own and configure these registries, we ensure that the community can fully trust the datasets, as the users themselves are the owners of the data, so it's in their best interest to act honestly.

Mary is almost here

The Mary codebase is due to be deployed on mainnet by the end of February, assuming all final testing goes as planned during the month. Mary's arrival is the first in a series of evolutionary stages that will enable the community to benefit from these new capabilities:

• Yesterday, we successfully deployed the Goguen ‘Mary’ code onto the Cardano testnet. The SPO community and internal teams are now doing final UAT on this.
• The Cardano explorer (the tool that retrieves and presents blockchain and transaction information from the Cardano network) has also been updated and released for quality assurance testing yesterday.
• We also deployed a basic version of the Daedalus wallet, for testing the wallet backend.
• During February, the Daedalus wallet will be updated to include support for sending, receiving, and viewing multiple tokens , including integration with the new backend interface.
• The metadata registries (Github repos that store user-submitted metadata) will come online a little later this month.
• From the testnet phase onward, there will be support from our Technical Support Desk (TSD), a specific testnet wallet to view and transact tokens, and use of the registry to add metadata to tokens. There is also a dedicated dev support program run by our community team to support developers who want to get involved.

The deployment of Goguen ‘Mary’ marks a significant stage in Cardano’s journey. When Mary turns her crypto key within the network, we will unlock the mechanism for users to create their own tokens for a myriad applications: Decentralized Finance (DeFi), and countless other business use cases.

Next week, we’ll publish a blog post digging a little deeper into core native token functionality and what users can expect. Remember to follow us on Twitter and subscribe to our YouTube channel to get the very freshest updates as we continue the Goguen rollout.

The Cardano stake pool community powers the Cardano network; the health and vitality of this critical operator ecosystem is essential to the effective running of the protocol. And as we continue to evolve Cardano’s utility through Goguen, this will become ever more important. Staking with quality pools is the very best way to give back to the Cardano community.

Like any ecosystem, success comes from the balancing of interests, dissemination of power, and the variety and diversity of actors. And like an economy, a balance of commercial influence; bigger players, smaller players offering greater diversity and a healthy core in between.

As much as ‘code is law’ (and features the judiciary?) we can all recognize the inputs, outputs, human behaviours and social dynamics that shape the community which surrounds and supports any blockchain protocol.

So as part of our continuing commitment to healthy ecosystem growth, we recently outlined our new strategy for delegating IOG’s ada funds. We instigated this delegation strategy to support our long-term vision for Cardano’s growth and evolution and reaffirm the values we espouse. All in line with following a fiscally sound path which can maintain the commercial viability of our organization.

A positive response

We put out the call for delegation in December. Our community responded very positively, and by the time we closed for entries just before the Christmas break, we had received just under 300 (299 in fact) applications for delegation. We have since retired all but one of our public pools – their creation was always an entirely tactical activity – and we’re now shifting toward our longer term strategic intent.

The process

Over the past two weeks, we have reviewed all entries from our call for delegation. The process has been relatively complex. We have tried to identify a cross section of pools based on a number of factors, all important on their own merit. Viewed holistically, these factors provide an invaluable map of the SPO environment. Among the key factors (and within them, variables) that we took into account were:

Purpose – is this a purely commercial venture, or is it doing something to give back or pay forward to the community or the wider world (content, education, support for the disadvantaged, sustainable practice, donations to charity, etc. )

Geography – are they an active and committed player in an under-represented region?

Technical contribution – is the SPO running a best-in-class technical operation or building (tools, applications etc.) on Cardano? Have they been a contributor since the ITN – or longer?

Stake and pledge ratio – what is the ratio here? Is the amount of pledge ‘reasonable’ given their stake, or does this SPOs ‘commitment to the network’ –through pledge – suggest they ‘deserve’ a higher level of delegation from the community?

Community engagement – are they an active member of the SPO community? Are they adding value through positive role-modelling on social, or supporting other community members via contributing to guilds/alliances etc. Are they helping drive visibility and adoption in an ethical, sustainable way?

The selection process has been challenging, iterative, illuminating and inspiring.

Challenging because we have not been able to delegate to every pool we might have liked to – our SPO community is hugely talented and not everyone got a delegation in this first cohort. While we applied some basic filters to narrow down the field from 299, we still had a long list of probably 75% of that number. So we had to look at factors more holistically; this was not a yes/no choice. Kudos, by the way, to pooltool.io and adapools for providing additional data sources during the process.

As our first-ever program, we had always regarded this as a ‘pilot’ we would evolve iteratively. Initially, we planned to classify pools separately. Pools centered on purpose or mission-driven objectives vs. those focused on more technocratic factors. For a start, we were surprised at the number of mission driven pools within the ecosystem. Given our broader mission as a community, perhaps this shouldn't have been a surprise. However, once we dug into the data, it became clear that many pools were hard to classify, adding value in a number of ways; purpose, technical contribution, geographic spread, community contribution. The very best pools here set the standard for all.

Choosing pools

The selection process was illuminating due to the richness of the data set, which reflected the diversity and breadth of our community. We gained some powerful insights. So much so, in fact, that we plan to anonymize the data set and share a subset with the community a little further down the line, both to identify elements we need to iterate, and to provide a snapshot of community growth and evolution over time. Think of it as a quarterly ‘census’ of the SPO community.

That same richness has been truly inspiring – SPOs in dozens of countries, across every continent (except Antarctica… hmm… now there’s a challenge for someone to take up!). Tangible evidence of a young, but fast-maturing community committed to excellence, collaboration, and making a positive difference in the world. All through Cardano.

So let’s meet the pools we have selected:

Congratulations to our very first 100-strong pool cohort. We’ll start delegating to our selected pools from the end of January/early February (based on operational considerations), staking IOG funds of 3.2M ada per pool to support block production. Each quarter through 2021, we shall recruit a fresh cohort and update this list accordingly.

We want to make our approach as visible as possible. We have created a dedicated Twitter list, so you can follow our first cohort. And while we have no formal guidelines, we see these delegations as bootstrapping; pools should continue doing what they do within the community and look to organically grow their delegate base, while we delegate to them.

To check out some of these pools, visit pooltool.io or adapools and search on each ticker. You will also shortly be able to filter by dedicated lists. Additionally, we’ll also be introducing some of them here on the blog and to our monthly show over the weeks and months ahead.

Looking ahead

If you were not selected this time, take heart. We had many more pools than we could delegate to this time. We encourage all pools that missed out to apply again for the fresh cohort in Q2; we’ll make a new call for applications at the end of March and rotate delegations at the end of April.

Every pool will need to reapply. However, we shall simplify the process for pools that missed out this time. It is also important to note that as the ecosystem grows, we are seeing some strong community contributors emerge who did not apply for delegation. We also welcome community feedback on how we can continue to grow and evolve the process.

Please check out the program and if you want some support bootstrapping your pool operation (or providing ‘block security’ while you grow your organic delegate base) don't miss out next time.

We are delighted to see many pools grow from strength to strength. Equally, when a smaller pool calls out that they are stalling, we must listen. Alongside this program, your choice as a delegator is key to supporting a pool ecosystem of abundance and generosity. Because there lies growth and the community we all desire. This is what we do. As the leading crypto community, it is something we should all be very proud of.

IOG is committed to seeing the Cardano ecosystem grow and flourish. We will continue to play our part. And remember, as a community, we all have our parts to play.

A blockchain environment is not a static one. Blockchains evolve as their communities grow and learn, and Cardano is no exception.

With every development stage, Cardano's core functionality has been expanded with new features: Shelley added delegation, stake pools, and decentralization to Byron’s core transactional capability. Goguen is now starting to bring fresh utility, from metadata to smart contracts and native tokens. Voltaire introduces a treasury and voting system, and we’ve seen the early steps of this process with Project Catalyst and the first ever public funding round for Cardano community ideas.

We introduced transaction metadata in November, an important first element in creating new utility and commercial use cases. We recently deployed the first pre-production environment for native tokens. Following that will be token creation and ERC-20 conversion. Plutus and Marlowe, Cardano’s native smart contract languages are under active development and will be released in 2021, opening up the platform for developers to create fresh solutions and power exciting new use cases.

All of these Goguen elements play their part in delivering Cardano's ultimate objective: a truly decentralized and self-sustaining platform. All the time encouraging deeper community engagement and growth by creating fresh opportunities.

We have a vibrant and skilled community, arguably one of the strongest and smartest in the crypto space. And in line with our avowedly non-’maximalist’ and open approach, we want to reach out to other communities and bring them onboard too.

As outlined in Charles Hoskinson’s recent video, Cardano's next strategic move will be the addition of a range of devnets to draw fresh developer communities into the wider Cardano ecosystem.

These devnets will act as ‘bridges’ between developer communities, providing development environments, virtual machines and suites of developer tools so new applications can be tested in an environment as close to the 'real world' as possible.

Understanding the devnets

After some initial exploratory work back in 2018, we are now restarting and accelerating the K Ethereum Virtual Machine (KEVM) program. The new KEVM devnet is the first of several devnets we’re building out over the next month or so. The EVM runs within the K Framework, a system for specifying languages and VMs, and then deriving tools such as interpreters, type checkers, equivalence checkers, debuggers, etc. for these languages. (The EVM is what runs smart contracts in the Ethereum network.)

K applies formal reasoning and mathematical rigor for the highest levels of assurance. It enables developers to define or implement the formal semantics of a programming language in an intuitive and modular way. K also generates an executable, 'correct by construction VM' from its formal specification, which is fast and powerful enough to run real programs and smart contracts. This effectively means that software should perform the required functions and nothing else, for all possible inputs, and have verifiable evidence.

Our long term vision – in association with our partners at Runtime Verification – is to build a K environment where we can just 'plug-and-play' new VMs. You can hear more about the goals of K from the team at Runtime Verification in this video segment from the Cardano monthly show.

The KEVM devnet, which is aimed at the Solidity/Ethereum community, will enable full backward compatibility with Ethereum. Because Solidity is a high-level language similar to JavaScript and C++, it cannot be directly executed by the EVM. Solidity programs must be compiled to assembly language (EVM bytecode) first, so they can run on the KEVM.

KEVM will allow developers to write applications in Solidity, EVM code, or Glow, providing toolkits to compile and deploy them on the devnet for (close to real-world) testing. We also plan to soon add Truffle integration, further increasing developer usability.

Glow

Solidity is by far the most popular higher programming language compiling to EVM bytecode, but by no means the only one. One fascinating alternative to Solidity is Glow, developed by our partner MuKn.

Glow is a ‘high-level’ language (other examples of high level languages include JavaScript, Python etc.) designed to allow writing highly secure financial contracts intuitively. Glow follows the 'correct-by-construction' doctrine to avoid common pitfalls and potentially costly bugs. Glow can prove that contracts written in this language have certain desirable properties, no matter what other participants in the contract do or do not do.

Glow has been designed with interoperability in mind. There will be Glow compilers targeting many diverse platforms and blockchains, making code reuse so much simpler and more practicable.

This will be the next devnet to be deployed. Most of the core development work is now done, ready for final QA and deployment in January 2021.

IELE - A foundation for third-generation blockchains

Full compatibility with the EVM is convenient and attractive to many experienced developers familiar with Ethereum, but KEVM inevitably also inherits the EVM’s weaknesses.

For this reason we’ll offer a more advanced and secure alternative in the form of our IELE devnet. The IELE (pronounced yeah-leh) virtual machine, also being developed by our partner Runtime Verification, is similar to the EVM, but much more secure. For example, it uses arbitrary precision integers, immediately eliminating many of the EVM's vulnerabilities. IELE is also register-based, not stack-based like the EVM, making it much easier for developers to write IELE bytecode by hand directly.

The term IELE describes two things:

• The IELE VM
• The IELE assembly language

IELE is a human-readable, blockchain low-level language, meant to serve as the foundation for third-generation blockchains. IELE was designed using state-of-the-art formal methods to address security and correctness concerns in Ethereum, while simultaneously enabling the verification of mathematical correctness of smart contract code that K EVM brings to Ethereum.

IELE represents the next step in the evolution of correct-by-construction, automatically generated implementation concepts. It is built to become the foundation of an entire compiler backend, allowing robust gas optimization, including contracts written in a high-level language that has IELE as its compilation target, like Solidity or Plutus.

Bridges between developer communities

The KEVM, Glow and IELE devnets align closely with Goguen’s key goals: to bring use and utility to Cardano, and build solid, lasting partnerships that contribute to the ongoing growth of our developer ecosystem. We aim to attract as many developers from as many disciplines as possible, to foster versatility and inclusivity.

Alongside Plutus and Marlowe, we hope these devnets present an unrivalled opportunity for developers (in the blockchain-crypto world and beyond) to engage with the Cardano platform, build compelling use cases, and contribute to the growth of the ecosystem.

An exciting future

We hope to provide a clear path towards new developer opportunities that will require close collaboration with many different communities, not least Cardano’s own. And it's one step at a time.

We’re putting the building blocks in place now. Once fully established, the devnets will act as bridges between developer communities, opening up new avenues of communication and cooperation across not just blockchain, but the whole developer ecosystem. Cardano will have permanent backward compatibility with the Ethereum network, keeping pace with any developments in the Ethereum chain. And by broadening the developer base, the Cardano community can help drive the continuing evolution of smart contracts and the decentralized finance (DeFi) space. Another remarkable year awaits. See you on the other side.

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.