As the Alonzo hard fork brings core Plutus smart contract capability to Cardano, the ledger evolves to meet the growing need for the deployment of decentralized solutions. Cardano ledger design focuses on high assurance, security, and proven formal verification. In alignment with this strategy, it is also important to ensure that transaction processing is deterministic, meaning that a user can predict its impact and outcome before the actual execution.

The ability to guarantee the cost of transaction execution, and how the transaction behaves on the ledger before it is submitted, becomes even more prominent with the introduction of smart contract support. Unspent Transaction Output (UTXO)-based blockchains, like Cardano, provide such capabilities. Account-based blockchains, like Ethereum, are indeterministic, which means that they cannot guarantee the predictability of the transaction’s effect on-chain. This presents risks of monetary loss, unpredictably high fees, and additional opportunities for adversarial behavior.

In this blog post, we take a closer look at the benefits of Cardano’s deterministic design that allows for secure transaction and script evaluation before execution. In the following blog post, coming later this week, we discuss the two phases of transaction validation on Cardano.

What is transaction determinism and why is it important?

Determinism, in the context of transaction and script processing, is a synonym for predictability. This means that a user can predict locally (off-chain) how their transaction will impact the on-chain state of the ledger, without:

• unexpected script validation outcomes or failures
• unexpected fees
• unexpected ledger or script state updates.

A transaction in a deterministic system might yet be rejected, even if constructed correctly. Rejected means that the transaction could not be applied to the ledger at all, therefore having no effect on its state, so no fees are paid. The reason this would happen is due to ledger changes caused by other transactions processed between the time when the initial transaction is constructed and the time it is processed. This can happen even with simple transactions. For example, another transaction might spend a UTXO that a user was also planning to spend. Determinism ensures that, whenever a transaction is accepted, it will only have predictable effects on the ledger state.

Addressing the issue of indeterminism

Indeterminism means that we cannot predict what effects a transaction will have on the ledger before execution. When designing the ledger, as well as a smart contract interpreter, it is important to foresee conditions in which indeterminism might occur, and make design decisions to avoid them. One of the main hazards in such a case is access to mutable ledger data, that is data that can be changed or altered. When the changes a transaction or a smart contract make to the ledger depend on its state at the time of processing, rather than only the contents of the transaction, indeterminism might become an issue.

Ethereum is notably susceptible to this problem. For example, gas prices, or a decentralized exchange (DEX) rate can fluctuate between the time a user submits a transaction and the time it gets processed. This results in unexpected gas fees, or price changes of assets being purchased. Or a script might simply fail, resulting in high execution costs (hundreds of dollars) and no other effect. This could occur, for instance, if the funds available to cover the gas costs run out mid-execution. Deterministic ledger design eliminates these possibilities.

Other possible sources of indeterminism include allowing scripts to see:

• data in the block containing the transaction, but not included in any transaction, e.g., system randomness, block header, or the current slot number
• data altered or substituted by an adversary, which might change the outcome of script validation, while the transaction itself remains processable.

In most systems, there are ways to mitigate these issues with improved script-writing practices, or layer-2 solutions. Cardano is designed to guarantee predictable outcomes for all scripts and transactions.

How basic UTXO model benefits in terms of determinism

The Cardano ledger is built on a UTXO accounting model, which means that assets are stored on the ledger in unspent outputs, rather than in accounts. Each of these outputs specifies quantities of assets stored therein, together with its address. Unspent outputs are immutable, so a transaction might consume the entire output, but it cannot alter it.

To transfer assets, a transaction consumes one or more outputs and creates new ones, which, in total, contain the same quantities of assets as the ones consumed. These quantities -and their UTXO addresses- are specified in the outputs of the transaction. The only way a transaction can influence the effect of another transaction applied to the ledger is by spending the same UTXO as the later transaction attempts to spend, thus causing the node to reject it. This is the key feature on which the UTXO model relies for maintaining determinism.

A UTXO ledger has both benefits and drawbacks over the account-based model. The latter will encounter fewer instances of transactions blocking one another, for example. Unlike UTXOs, accounts are mutable ledger data. So a transaction might see, for example, a different quantity of assets in an account, depending on whether it was processed before or after another transaction that updates that same account. This circumstance might not cause the transaction to be rejected, but it could result in different – and unpredictable – changes to the ledger.

Spending a UTXO is just one example of an action a transaction can take. Next, we explain what transaction actions are, and how they can be validated. The most significant set of changes introduced in Alonzo are changes to the process of action validation.

Validating actions with signatures and scripts

An important aspect of processing a transaction is validating the actions it is taking. A transaction is taking an action when it contains data in the specific field to that action. For example, a transaction is spending UTXO U when it contains a reference to U in its input field, and it is minting a token X when its mint field contains X.

When the node processes a transaction, it verifies whether it can perform the action it intends to. For this, the author of the transaction must provide relevant pieces of data, e.g., scripts, redeemers, or signatures. A common example of an action that requires validation is spending a UTXO locked with a public key. The transaction must provide a signature from the corresponding private key to perform this action.

Cardano uses scripts to validate actions. These scripts, which are pieces of code, implement pure functions with True or False outputs. Script validation is the process of invoking the script interpreter to run a given script on appropriate arguments.

Script validation can be performed for the following actions:

• Spending a UTXO locked by a script address: the script that is run is the one whose hash forms the address.
• Minting a token: the script that is run is the one whose hash forms the policy ID of the token being minted.
• Reward withdrawal: the script that is run is the one whose hash forms the staking address.
• Applying a certificate: the script that is run is the one whose hash forms the certificate author’s credential.

Besides letting the node know which script to run, all transaction actions indicate how to assemble arguments passed to that script.

Cardano’s multi-asset ledger (Mary) supports simple multisig and timelock scripting languages. These allow users to specify signatures required to perform an action (such as spending a UTXO or minting a non-fungible token (NFT)), and the time interval in which it can be performed. A timelock script can never see the actual slot number in the transaction that includes it. Timelock can only see the validity interval of the carrying transaction. Allowing a timelock script to see the current slot number (i.e., data coming from the block, rather than the author) would break determinism. This is ensured by the fact that a user cannot know the exact slot in which the transaction gets processed, and therefore they cannot predict how the script will behave.

Mary scripts, unlike Plutus contracts in Alonzo, are very limited in what they can express. The Alonzo hard fork ushers in a new era of powerful, stateful contracts that do not compromise the deterministic ledger property.

Plutus scripts

Alonzo introduces a new approach to transaction validation on Cardano due to the implementation of Plutus scripts. The extended unspent transaction output (EUTXO) model, deployed as part of Alonzo, provides the ledger infrastructure to support Plutus contracts. Below, we provide a high-level overview of ledger and transaction changes. For more details about working with the ledger and Plutus scripts, check out the Plutus Pioneer program!

Alonzo changes the data on the ledger as follows:

1. Plutus scripts can lock UTXOs.
2. A new component, added to the contents of the output parts of UTXOs, enables script state-like functionality. In addition to assets and an address, a UTXO locked by Plutus scripts also contains a datum. A datum is a piece of data that can be thought of as an interpretation of the script state.
3. There are a number of new protocol parameters used to impose additional validation requirements on transactions. These include upper limits on computational resources that scripts can consume.

To support Plutus scripts, transactions have been upgraded as follows:

1. For each of its actions, the transaction now carries a user-specified argument, called a redeemer. Depending on the script, a redeemer can serve a different purpose. For example, it can act as the bid the user places in an auction, or the user’s guess in a guessing game, among many other functions.
2. The transaction specifies computational execution budgets for each script.
3. To ensure that a transaction can pay its execution fee, Alonzo introduces additional pieces of data, which we’ll discuss in a follow-up blog post.
4. Transactions contain an integrity hash, needed to ensure that it has not been compromised, outdated, etc.

There are also some changes to the specifics of Alonzo transaction validation as compared to Mary. For each action, the node assembles script arguments expected by the Plutus interpreter, including:

• the datum
• the redeemer
• execution budget
• a summary of the transaction.

The node performs new, Alonzo-specific checks that ensure the transaction is constructed correctly. For example, it must not exceed the maximum execution resource budget. It also invokes the Plutus script interpreter to run the scripts.

Datum objects vs script state

Like mutable accounts, mutable script state falls squarely into the ‘mutable ledger data’ category of indeterminism sources. We already saw that the UTXO model avoids the mutable accounts indeterminism issue. It can also help us reimagine the concept of script state in a way that maintains determinism. If a UTXO is locked by a Plutus script, that UTXO’s script code is associated with its address. The state-analog of this script is the datum stored in that UTXO. When a transaction spends that UTXO, it gets deleted from the ledger, including the datum. However, the contents of the Plutus script could enforce that the transaction carrying it must also create a UTXO containing a specific datum that can be viewed as the updated script state.

Script execution budget

The non-deterministic gas model can charge users unpredictably large fees. In Cardano scripts, this source of indeterminism is addressed by requiring that the resource budget itself, as well as the fee required to cover this budget, are included in the transaction. In Alonzo, a user can predict both locally when constructing the transaction. Script execution necessarily returns either True or False, and will not loop indefinitely. The reason for this is that every operation a script performs takes a non-zero amount of resources, which are tracked by the interpreter. If the budget specified by the transaction is exceeded, script execution terminates and returns False.

Transaction validation in Alonzo

Addressing the possible sources of indeterminism, the following key points make the outcomes of script and transaction validation predictable:

• the script interpreter will always terminate and return the same validation result when applied to the same arguments
• a transaction necessarily fixes all arguments that will be passed to the script interpreter during validation
• a transaction specifies all the actions it is taking that require script validation
• compulsory signatures on a transaction ensure that it cannot be altered by an adversary in a way that causes scripts to fail
• applying a transaction in the EUTXO ledger model is deterministic.

The last point is largely inherited from the UTXO model, as Alonzo ledger protocol updates remain, for the most part, consistent with updates in previous eras (including the delegation scheme, etc.). After the Alonzo upgrade, script validation failure or success does affect how a transaction is processed (more about this in part 2!). However, the True or False outcome, as well as ledger changes associated with either outcome, are predictable for a given transaction.

The deterministic behavior of Cardano’s script and transaction validation is not a natural outcome of using the EUTXO model. To ensure this property, the IOG team had to carefully track the source of every piece of data which a script is allowed to see.

The deterministic evaluation property is formally specified in the Alonzo specification, and the IOG team has also sketched proof that the interpreter gets only those arguments that would not break the property.

In our second blog post, we’ll take a closer look at the 2-phase validation process of Cardano transactions. So, keep an eye out later this week for part two.

The Cardano network continues to grow exponentially, thanks to the efforts of the stake pool operators (SPOs) who secure and maintain it.

During 2021, we have been delegating a proportion of our corporate ada holdings to help bootstrap our SPOs. In the first two rounds of delegation, IOG’s strategy has focused on supporting geographically distributed pools, mission-driven operators, pools creating content or driving social awareness. We also supported geographically distributed lower-middle-sized small pools to help balance the network. In previous rounds, we have tried to identify pools where our delegation can support strong performers, while making a positive impact for the whole community.

To date, around 200 pools have received IOG delegation of c. 3M ada each. It's a healthy number of pools but just a fraction of a vibrant SPO ecosystem now numbering in the thousands. Inevitably, we haven't been able to support as many pools as we’d have liked and plainly, a number of valued community contributors have been missed.

So this time, we’re doing things a little differently. In this third round, as we enter a new era of smart contracts, we wanted to acknowledge and applaud the community contributors that are widely recognized yet so often without much fanfare. As well as applying for themselves, we’re asking the SPO community to nominate the best of their own. As well as requesting delegation to their own pools, SPOs will also be invited to nominate up to two additional pools they feel should be recognized and supported for their positive contribution to the community.

We’re looking for outstanding contributions made to the ecosystem that fall into at least one of these categories:

• Build: SPOs contributing to ecosystem growth by providing tools, dev advice, resources, etc.
• Create: SPOSs producing high-quality written content and creative artwork such as infographics that adds value to the wider community.
• Educate: SPOs building alliances, groups or educating delegators on important topics, role modelling technical excellence, or contributing to the Plutus Pioneer body of knowledge.

In addition, SPOs should operate only a single pool and have a current stake of 12M or less.

Once we have received all the delegation requests and community nominations, we shall evaluate all the candidates against these criteria, publish the pools selected and make delegations in October after the Cardano summit.

And another thing. It’s not often we get a chance to survey the whole community. So this time, we’re also asking SPOs to contribute to our study on sustainability. Along with the questions for the delegation survey, this time we’re also polling SPOs at the end of the survey on their pool’s setup and green credentials. We’ll share the results of this survey with the community.

I’m an SPO. How do I take part?

Each month, we publish an ‘SPO Digest’ newsletter bringing together key news for the stake pool operator community. The next SPO Digest, which we will be sending out shortly, will include the survey where you can apply for delegation. SPOs seeking delegation should fill this in and also add up to two additional SPOs they’d like to see recognized. To receive the delegation survey, please ensure you are signed up to the digest list via https://mailchi.mp/iohk/spodigest by midnight UTC on Sunday 4th September.

We are pleased to announce a new and exciting partnership between IOHK and the European Business University of Luxembourg (EBU) to make education accessible for everyone in developing countries.

EBU is a renowned educational provider and non profit organization dedicated to higher education and certificate programs. They are partnered with over 36 key global organizations and currently educate over 2000 students in 25 countries on the African continent. Together, we intend to roll out our training programs on a wider scale. We firmly believe that EBU can play a pivotal role in furthering the prospects of the people of Africa with this expansion of their scholarship program that will provide great benefits to prospective students.

The objective of this partnership is to expand the teaching and content material with the provision of courses in Plutus and Haskell to a broader audience, thereby empowering people in developing countries to learn new skills and become self-sufficient.

Working closely with Alexis Hague and Dr. James Mulli, directors at the European Business University of Luxembourg (EBU), this new partnership will be sponsored by IOHK’s director of education, Lars Brünjes, in conjunction with our IOHK education team. The collaboration will give a wealth of new African students access to educational material for free, whilst also supporting our mission in the region.

Widening the reach of education in Africa

These programs have been developed to meet the increasing demand for Haskell programmers and enable students to work on DeFi solutions, application programming, tokenization projects, and smart contract development.

IOHK will support the Plutus-Haskell offering that EBU plans to deliver to students with teaching and content material for the provision of these courses. EBU will promote the IOHK goal of bringing smart-contract developer expertise to students and relevant stakeholders in Africa and other continents. This is a very positive benefit to those people who are interested in getting up to speed and ready for the Alonzo release that will deliver smart contract functionality.

How will the scholarship program work?

EBU will include Haskell in their curriculum and offer courses in Plutus and Haskell to students who are enrolled in the EBU Certificate program at no tuition cost to the student, but with a €10 commitment fee. In addition, students who join the EBU Ambassador program will be incentivized to grow the courses using an “Earn as you Learn” stipend for bringing new students on board. Both of these rewards offer direct benefits to the students who enroll on our courses and will help us to grow and expand this program organically.

IOHK and EBU will work together to support the implementation of each other’s missions for education and creating opportunities for people in developing countries. This will be achieved using tools such as an education for all approach, the provision of learning hubs with internet for participants, and the practical implementation of blockchain solutions.

How can I sign up?

If you are interested in signing up for these training programs ahead of the start of EBU’s new term on September 27th, please visit the EBU scholarship website to register and enroll. Participants will then receive a coupon code to use for enrollment. We are pleased to confirm that the price of these courses will be waived and only includes a nominal administration fee. If you have any questions, please contact EBU admissions or EBU administration.

Looking forward

We plan to release these training programs and content publicly in GitHub in the near future, so that other institutions can follow this approach and roll out their own Haskell and Plutus training courses. Stay tuned for more details on availability of this content coming soon.

The Cardano ecosystem is committed to supporting and growing our developer community. A vibrant, informed community is essential to the development of a decentralized, functional ecosystem with a diverse user base. In line with our open-source approach, as we evolve Cardano together, everyone can benefit from its decentralized financial solutions while delivering best-in-class blockchain technology.

To reach our common goals, it is essential that everyone participates in the development process and can always get the information, guidance, and assistance they need.

To support this mission, we are encouraging development talent and experts from across the globe to gather in one place – Cardano Stack Exchange. This developer hub is the ideal place to share experiences, ask and answer questions about all the streams of Cardano development and operations, and share resources. This site – being driven by members of the Cardano community – is one of the resources to help you learn how to develop decentralized applications (DApps) and write smart contracts.

What is Stack Exchange?

Cardano Stack Exchange originated from Stack Overflow, the free community website for developers created by Jeff Atwood and Joel Spolsky in 2008. The name was chosen by a voting process in April 2008 by readers of Coding Horror, Atwood's popular programming blog. From this beginning, the movement has grown to host many specialized Stack Exchanges.

One of the newest is dedicated to Cardano developers. Currently in beta, it is a community-moderated question-and-answer site where all Cardano developers, including Plutus pioneers, can get expert answers to a variety of questions, ranging from installation queries to configuration and implementation details.

This community-driven, decentralized philosophy of Stack Overflow fits particularly well with the open-source, decentralized philosophy of Cardano.

How it works

If you are stuck on an issue in Cardano, or curious about an element of its technology, the Stack Exchange is a great resource. It serves more as a place for specific questions about real problems than a discussion site like the Cardano Forum. This format means that you can easily find the questions you are looking for without getting lost in long-winded discussion threads. Once you come on board, you will have the opportunity to search all previous questions and suggested resolutions.

Examples of questions currently being answered on the site include:

What happens to staked ada after transferring ada to another wallet?

What is the maximum number of addresses in a Cardano Wallet?

How to create a serialized transaction without a local full node?

Your question might have already been answered; in this case, you can see how many times it has worked for someone. On the other hand, if you have a new question, someone else will probably encounter the same issue, and your question and answer will be helpful for them.

Cardano developers and support staff regularly check the site and will provide answers where they can. You can check for new questions too, and maybe provide an answer for someone else. The community elects the moderators and upvotes questions and answers to show appreciation.

The more you use the site, the more valuable it becomes. Users gain reputation points by asking questions, upvoting questions and answers, and providing answers to fellow developers. Reputation points increase your overall score and earn you more site privileges. Many people find that explaining something to another developer is one of the best ways to deepen their own understanding. The best way to learn, as they say, is through teaching.

How to get involved

We’re very keen to establish and grow our Stack Exchange presence. The site is currently in beta and can only grow with community usage and support. This is where you come in. We’d like to encourage you to ask a question – or a bunch of them if you like!

The site is completely free to use. Just provide an email address, set your password, and you’re good to go!

When someone from the community answers your question, you can return the favor by helping your fellow developers with possible resolutions and suggestions to their questions. When you receive an answer that works for you, remember to accept and upvote it. Considering the search terms that others might use will help you write a good question.

With the site currently still in beta phase, it needs wider adoption and activity to progress to full production. We encourage you to log on, get involved, and help make the site a valuable resource for everyone in the community.

The Stack Exchange initiative is truly a Cardano community effort. So particular thanks to all the contributors working to drive this project forward.

I would like to acknowledge Neil Burgess for his contribution to this article.

Cryptocurrency volatility is one of the obstacles to its wider adoption. Blockchain technologies provide benefits such as transparency, data immutability, and proven security of financial operations. Yet, it is harder than fiat currencies to predict how the market will behave, or forecast the value of a digital currency. This hinders using cryptocurrencies as accounting and exchange units in daily operations.

A stablecoin is a cryptocurrency pegged to a basket of fiat currencies or a single currency (eg, USD or EUR); commodities like gold or silver; stocks; or other cryptocurrencies. Stablecoins include mechanisms that maintain a low price deviation from their target price and so are useful to store or exchange value, as their built-in mechanisms remove the volatility.

Some stablecoins lack transparency and liquidity of their reserves, which compromises their price stability. To address these challenges, IOG has teamed up with Emurgo, another of the three founding partners of Cardano, and the Ergo blockchain, which uses UTXO-based accounting like Cardano, to work on a stablecoin contract called Djed. Djed is based on algorithmic design. This means it uses smart contracts to ensure price stabilization, and that the coin will be useful for decentralized finance (DeFi) operations.

How stablecoins work

Different mechanisms contribute to the stability of the coin’s value and help eliminate price variations. These mechanisms are underpinned by the economic principles of supply and demand.

A common mechanism is backing the stablecoin by a reserve of the currency used as the peg. If demand is higher than the supply of sell or buy orders, this supply should be increased to avoid fluctuations in the price. Typically, stablecoin reserves are not stored in cash. Instead, they are kept in interest-bearing financial instruments such as bonds. The returns on these provide revenue for the operator.

As long as the stablecoin is fully backed by reserves in the currency to which it is pegged – and the operator can react quickly to variations in demand – price stability is maintained.

Common risks

Stablecoin reserves are commonly associated with investments. The lack of liquidity of these investments may prevent the operator from reacting quickly to demand. This compromises stability in the short term.

A drawback of fiat-backed stablecoins is that they require trust in the entities keeping the reserves. Lack of the reserves’ transparency or of the ‘full-backing’ claim, combined with inefficient stabilization measures, have already caused Tether stablecoin (USDT) to fall below $0.96, as shown in Figure 1.

Figure 1. Price of the Tether stablecoin (USDT) in the past three years

Issues of transparency do not arise when the backing asset is a cryptocurrency on a public blockchain. Furthermore, the use of smart contracts ensures efficient and reliable execution of stabilization measures due to its automated and secure mechanisms.

Enhanced stabilization mechanisms of Djed algorithmic stablecoin

Djed is a crypto-backed algorithmic stablecoin contract that acts as an autonomous bank. It operates by keeping a reserve of base coins, and minting and burning stablecoins and reserve coins. The contract maintains the peg of stablecoins to a target price by buying and selling stablecoins, using the reserve, and charging fees, which accumulate in the reserve, as shown in Figure 2. The ultimate beneficiaries of this revenue stream are holders of reserve coins, who boost the reserve with funds while assuming the risk of price fluctuation.

Figure 2. How Djed works

The Djed stablecoin is designed as an asset pegged to a fiat currency (USD), along with a governing algorithm. This approach provides a stable means of exchange. But Djed is not limited to being pegged to the dollar. It can work with other currencies, as long as there are oracles providing the contract with the corresponding pricing index.

The first formally verified stablecoin protocol

Djed is the first formally verified stablecoin protocol. The use of formal methods in the programming process has greatly contributed to the design and stability properties of Djed. Using formal techniques, the properties are proven by mathematical theorems:

• Peg upper and lower bound maintenance: the price will not go above or beyond the set price. In the normal reserve ratio range, purchases and sales are not restricted, and users have no incentive to trade stablecoins outside the peg range in a secondary market.
• Peg robustness during market crashes: up to a set limit that depends on the reserve ratio, the peg is maintained even when the price of the base coin falls sharply.
• No insolvency: no bank is involved, so there is no bank contract to go bankrupt.
• No bank runs: all users are treated fairly and paid accordingly, so there is provably no incentive for users to race to redeem their stablecoins.
• Monotonically increasing equity per reserve coin: under some conditions, the reserve surplus per reserve coin is guaranteed to increase as users interact with the contract. Under these conditions, reserve coin holders are guaranteed to profit.
• No reserve draining: under some conditions, it is impossible for a malicious user to execute a sequence of actions that would steal reserves from the bank.
• Bounded dilution: there is a limit to how many reserve coin holders and their profit can be diluted due to the issuance of more reserve coins.

Djed versions

There are two versions of Djed:

• Minimal Djed: this version is designed to be as simple, intuitive, and straightforward as possible, without compromising stability.
• Extended Djed: this more complex version provides some additional stability benefits. The main differences are the use of a continuous pricing model and dynamic fees to further incentivize the maintenance of the reserve ratio at an optimal level.

Implementations

IOG, Ergo, and Emurgo teams have been working on the implementation of the Djed algorithmic stablecoin contract earlier in 2021 to test different models.

The first implementation of a Djed stablecoin contract was SigmaUSD on Ergo. This was the first algorithmic stablecoin deployed on a UTXO-based ledger in Q1 2021. It had a fee of 1% for buying or selling operations, and an oracle that updated the exchange rate every hour. This initial version was subject to a reserve draining attack by an anonymous user who owned a large number of ERGs (Ergo’s native coin). The attack was ultimately unsuccessful, and it is estimated that the attacker lost $100,000.

To further discourage such attacks, this initial deployment of Minimal Djed was replaced by a version where the fee was set to 2%, the oracle updated every 12 minutes, and every oracle update was allowed to change the price by at most 0.49%, unless the price difference was greater than 50%. This provided stronger resilience against reserve draining attacks.

Djed has also been implemented by the IOG team in Solidity. One version uses the native currency of the Ethereum blockchain as a base coin, and another uses any ERC20-compliant token as a base coin. So far, these implementations have been deployed to testnets for Binance Smart Chain’s testnet, Avalanche’s Fuji, Polygon’s Mumbai, Ethereum’s Kovan, Ethereum’s Rinkeby, and RSK’s testnet.

Djed: Cardano implementation

The Alonzo update to Cardano will enable smart contracts using Plutus. Plutus is powered by Haskell, which guarantees a safe, full-stack programming environment.

Draft implementation of an earlier version of Minimal Djed is available in the Plutus language. In this implementation, stablecoins and reserve coins are native assets uniquely identified by the hash of the monetary policy that controls their minting and burning according to the Djed protocol. This implementation also assumes that oracle data such as the exchange rate is provided as signed data directly to the transactions, instead of being posted on-chain.

There is also an ongoing OpenStar implementation. OpenStar is a framework for private permissioned blockchains developed in Scala. The implementation of Djed using OpenStar follows the idea of off-chain smart contract execution to have a stablecoin on Cardano that does not depend on smart contracts executed on-chain.

To find out more about Djed stablecoin, see the recently published research paper or check out the presentation by Bruno Woltzenlogel Paleo, IOG technical director, at Ergo summit 2021.

We’d like to thank and acknowledge Bruno Woltzenlogel Paleo for his input to this article and support throughout the process of its creation.