With the rollout of Goguen, Cardano is becoming a smart contract platform. Adding metadata – information about the data being processed – to transactions is key to this, and last month this capability was added to the blockchain. From a focus on transactions, Cardano is now becoming a utility platform open for partnerships, enterprises, and commercial applications that can be used for the complex operations that will define the era of decentralized finance (DeFi).

With an increasing volume of financial cryptocurrency operations, the ability to access immutable data that cannot be altered is crucial, especially when it comes to applications such as wealth management. The Cardano blockchain maintains permanent records of processed transactions, ensuring that the history of financial activity is transparent and auditable. However, to grant more accountability and visibility to financial processes, context has to be added to these transactions. Additional information can include facts such as sender and receiver details, conditions, and time of processing. This is done by adding transaction metadata.

What is metadata?

Metadata refers to ‘data about data’. In other words, it describes the context, content, and structure of records. As blockchain technology provides a transparent ledger for storing records immutably and securely, metadata generates trust with permanent data attestation.

All transactions happen for specific purposes, whether this is a payment for product or service, or a funds transfer to a family member. When a purchase is made online, for example, there is so much information that can follow along with the transaction. Metadata can tell the story of the product purchase reflecting its buyer and seller, the time of deal, product manufacturer, or the supply conditions. All of these records are important to maintain along with the transaction of wealth.

With the emergence of Bitcoin, developers started leveraging blockchain technology to put such little bits of additional data on the chain, knowing that the information would be available forever. Over time, adding metadata to the chain became commonplace.

Cardano is a third-generation distributed ledger. In terms of metadata, this means that Cardano is far more efficient in adding transactional information than earlier blockchains. While earlier blockchains supported 40-80 bytes of metadata, Cardano’s transaction size is currently around 16KB. Subtracting the size of the rest of the transaction (UTxOs, inputs, and outputs) still leaves the majority of 16KB for metadata.

Why transaction metadata matters

Metadata is a handy way of certification and validation. It allows cryptocurrency assets to hold historical ownership, transfer or value details. This is highly beneficial when working with non-fungible – unique – assets representing value such as property or intellectual rights, for example. Additionally, a range of documents can be signed and certified using a public key that proves the document’s legitimacy.

One of the most prominent uses for metadata is in a supply chain. Supply chain involves parties such as factories, customers, suppliers, and delivery services. To enable efficient data tracking, participants must provide confirmation of services that are interlinked, and these must be accessible by everyone for verification. In this case, metadata can provide a complete picture of supply chain processes with fixed recorded data on the blockchain ledger. This grants transparency, immutability, and trust for all stakeholders.

The Atala products

The deployment of metadata on Cardano will see early commercialization through the Atala product suite, which includes Atala Prism, Atala Trace, and Atala Scan solutions. To enhance the overall product functionality in terms of data feasibility, accountability, and traceability, the IOHK team is implementing metadata support while integrating with the Cardano ledger.

Atala Prism is a decentralized identity system that enables people to own their personal data and interact with organizations seamlessly, privately, and securely. The Atala Prism team is integrating metadata to certify and store DIDs and DID documents on Cardano. Also, it will be possible not only to create but also to revoke credentials such as university certificates.

Atala Trace and Atala Scan are being developed to enable brand owners to improve the visibility over supply chain processes and establish product provenance and auditability. In these cases, metadata integration will be used to record tamper-proof supply-chain records.

Working with metadata

There are different ways of working with metadata both for enterprises and the developer community. One such way is using the metadata service developed by IOHK’s Professional Services Group. We have been working with a number of partners on integrations and have many more in the pipeline. So if you’re running a business and also wish to ensure trust for your customers and partners while managing your transaction metadata securely, please contact us via enterprise.solutions@iohk.io to find out how to incorporate metadata services in your processes.

Transaction metadata is an important early feature of Goguen utility and smart contract functionality, which will be enhanced and developed by many other capabilities over the months ahead. Stay tuned to this blog for all the updates on native assets, ERC20 convertor, Marlowe, Plutus and other smart contract languages as we roll these out.

The Ethereum Classic network suffered from four 51% attacks between 2019 and 2020. Three of those attacks have occurred recently – with just weeks between each other – which resulted in expensive losses for stakeholders due to double spending and service disruption. A number of Ethereum Classic Improvement Proposals (ECIPs) followed after these attacks aiming to provide the immediate solution for 51% attack resistance.

IOHK, and ETC Coop have collaborated to provide Ethereum Classic stakeholders and the broader community with the knowledge and understanding on how to resist these issues. To support this activity, we have created a comparison document to showcase and summarize the different 51% attack mitigations. In it, ETC community members will be able to assess each proposal, understand any concerns, and be advised on how the ETC community can solve ETC network security issues together.

The ECIP that seems to be reaching adoption in the immediate term is ECIP 1100: Modified Exponential Subjective Scoring (MESS). MESS is a modified version of Vitalik Buterin’s Exponential Subjective Scoring (ESS) and aims to make larger chain reorganizations more difficult. However, we believe that it will not provide robust security and there is no guarantee that it will prevent further attacks. What’s most concerning, however, about MESS, is that it has not been formally studied nor has its security been proven. Moreover, a series of potential attack vectors on MESS have already been identified.

Checkpointing is the way forward

Checkpointing, on the other hand, can make 51% attacks impossible with deterministic confidence of finality. This approach grants the ETC core developer community a safe space to innovate and implement the more speculative proposals that are underway. These may include MESS, Reducing the dag, Keccak-256, and many others. Considering that ETC value and user experience is currently hindered by the low-confidence and subjective finality of MESS, MESS doesn’t provide high confidence for stakeholders to reduce confirmation times to desirable levels.

The Ethereum Classic network is a minority proof of work blockchain in the Ethash environment. As of October 08, 2020, the Ethereum’s network hashrate is ~248.16 TH/s, Nicehash’s hashrate is ~9.34 TH/s, while Ethereum Classic’s network hashrate is only ~3.47 TH/s . This means that Ethereum Classic’s hashrate is only ~1.5% of Ethereum’s and ~40% of Nicehash’s, which is just one of many other mining rental platforms. It should be noted though, that non-Ethash networks that are minable by general purpose hardware can also be turned on to Ethereum Classic, which means that the Ethereum Classic network is even more of a minority proof of work blockchain than represented by the Ethereum and Nicehash comparisons above.

It thus follows that the current security assumptions of the Ethereum Classic network no longer hold. Speculating ETC’s network security on ETH’s proof of stake timeline is also not a sustainable security strategy and arguably not competitive enough to increase the value of the network.

Looking to the future

Indeed, it goes further than that. ETC is at an important crossroads and the choices we make now will impact not only the future of the platform but of the whole ecosystem. Any 51% attack mitigation must be robust enough to give absolute certainty to ETC holders, users and service providers that their transactions will be secure.

We need to be decisive and resolute, while giving ourselves the time to get this right. If we adopt a suboptimal solution at this point, and there are further issues with the network, it is unlikely that our (thus far) patient stakeholders – especially exchanges – will remain so.

Our focus at the moment is rightly on mitigation. But let’s also ensure we remember the longer-term goal – the health and sustainable success of Ethereum Classic. Let’s move decisively to underpin the security of the network, and together look forward towards a new era of network growth, community growth and sustainable innovation.

This post was originally published on the ETC Cooperative blog

Project Catalyst is, at its heart, a series of experiments in innovation and governance. Once it was decided to set up a funded system to encourage innovation for Cardano, the IOHK team decided to collaborate with our global community from the start. So, that’s what we did. Now, with two funds already incubating hundreds of proposals and fostering thousands of conversations, we wanted to share some of the things that we’ve learned.

1. Our diversity is our strength

We knew that the Cardano community was crucial to realizing the full potential of Project Catalyst. But we did not fully realize the depth of the expertise available, nor its truly global reach. When we called for ideas for the project, people responded. To date, Project Catalyst has drawn 3000 registered users, 500 perspectives, 126 proposals and +5,000 comments from 70 countries around the globe. Building courses in Haskell engineering, boosting decentralized technology in West Africa, podcasts and blockchain applications in many fields are among the ideas pitched on our Ideascale innovation platform. Furthermore, each one of these has been refined by the Project Catalyst community.

With such a worldwide community of entrepreneurs, experts, and specialists, we are able to tap into a previously unknown well of ingenuity. Furthermore, the community itself is responsible for ensuring that the brightest ideas rise to the top.

2. Community interest is self-interest

Proposals in Fund2 are vying for a share of an ada fund worth $250,000. This is an enormous incentive for individuals to make their pitch as strong as possible. However, we are working hard to ensure that there is an equal incentive for people to help develop the ideas of others, instead of focusing on just their own proposal. When a strong idea comes to fruition, it will inevitably benefit Cardano, and therefore every ada holder. Ultimately, we have learned that we need to provide a variety of motivations and experiences for the community to foster the most productive dialogue.

Currently, Project Catalyst participants can give a limited number of ‘kudos’ or positive affirmations to people providing value to the Fund through their comments and proposals. This is meant to build communal support. We are also establishing a cohort of community advisers. These are registered participants who have no active proposals but want to provide thoughtful and fair advice to voters. The first of these community advisers are now joining up and we are looking forward to seeing how they will benefit the project.

3. Innovation requires a positive mindset

Despite its many benefits, the digital world can be a toxic place. From YouTube scams and keyboard warriors, to Twitter trolls and spam emails, there sometimes seems no end to the pitfalls in online engagement. Project Catalyst is learning to minimize this activity if not eliminate it entirely. One way that we are working on this is by leveraging the experience of our Fund1 participants. These early pioneers are helping encourage mutual respect and collaboration, which we hope will proliferate through the entire system. However, we understand that is a tough goal for any global platform.

That being said, we have an automated reminder to encourage people to keep their thoughts focused on how feasible an idea is, how its effect can be measured and audited, and its potential impact on Cardano. We want to attract the most talented entrepreneurs, and so the more constructive the feedback, the nearer we come to fulfilling our strategic objective. Furthermore, the Catalyst team has published a guide for community behavior and feedback. If and when we detect abusive activity, we reserve the right to warn or ban the miscreants. Toxicity can damage the project and even Cardano as a whole, so our interventions will develop as the community grows. We remain focused on creating a forum for passionate discussions without constraining creativity.

4. Break down barriers to creativity

Thus far, we have been pleased with the progress Project Catalyst has made on the Ideascale innovation platform. It provides an easy-to-use interface for developing complex ideas. But no system is perfect. Some community members have found the interface overwhelming. For us to find and develop groundbreaking ideas, our working methods must always work to enhance creativity.

Currently, we are listening to community feedback through the Catalyst problem sensing challenge and feedback forms. This helps us hear what works and what needs iterating and improving. Ultimately, the proposals chosen and funded by Project Catalyst are only as good as their ability to be embraced and championed by the community. And great collaboration tools are vital for this.

5. Focus on the returns

Every challenge within the program represents an intention to generate outcomes from the fund. We are now working on ways to measure the effect of these intentions and how they contribute to a challenge being met. These measures include measuring how many developers, entrepreneurs, businesses, and Dapps were developed as an outcome of every proposal. Ultimately, that which is measured can be managed.

For example, the current Fund2 challenge is:

“How can we encourage developers and entrepreneurs to build DApps and businesses on top of Cardano in the next 6 months?”

This challenge is fairly open-ended, and deliberately so. These wide-ranging challenges are designed to encourage a broad spectrum of ideas. But not too broad, so we can still measure and track them effectively.

Applying the lessons

We’re building a system which will eventually be run, developed, and funded entirely by the community itself. In time, IOHK will only be involved with the daily operations of Cardano at the request of the community itself. However, until we are able to hand over total control to ada holders, we must maintain constant communication.

Throughout the Project Catalyst program, we have worked to ensure that communication is a two-way street. We are redoubling these efforts by ensuring that we seek out feedback at every stage. We also ensure that community assessments will be performed at the conclusion of each fund. These interventions allow us to prioritize solving issues that are important to the community.

Project Catalyst has been an incredible journey. These are only five of the takeaways from our current process. As the experiment continues grows, we are looking forward to learning more, attracting more participants, and building a best-in-class governance system. This is only the beginning.

Get involved with Project Catalyst by logging on at Ideascale or joining our next Crowdcast town hall on October 21.

In our Developer Deep Dive series of occasional technical blogs, we invite IOHK’s researchers and engineers to discuss their latest work and insights.

Marlowe is a domain-specific language for secure financial smart contracts that is being developed by IOHK for the Goguen capabilities of the Cardano blockchain. Following my introductory post on Marlowe, in this Deep Dive post, we'll look at the details of the language, and the various ways of writing Marlowe smart contracts as we move into the era of decentralized finance (DeFi). After explaining our approach to oracles, which import ‘real world’ information into a running contract, we look at the Algorithmic Contract Types Unified Standard (Actus) for financial contracts, and explain how we have implemented this innovation in Marlowe.

Marlowe in a nutshell

Marlowe is a small language, with a handful of constructs that, for each contract, describe behavior involving a fixed, finite set of roles.

• A running contract can make a payment to a role or to a public key.
• In a complementary way, a contract can wait for an action by one of the roles, such as a deposit of currency, or a choice from a set of options. Crucially, a contract cannot wait indefinitely: if no action has been initiated by a given time (the timeout), then the contract will continue with another behavior, such as refunding any funds in the contract.
• Depending on the current state of a contract, it may make a choice between two future courses of action, which are themselves contracts.
• When no more actions are required, the contract will close, and any remaining currency in the contract will be refunded.

When a contract is run, the roles it involves are fulfilled by participants, which are identities on the blockchain. This model allows a role to be transferred during contract execution, so that roles in a running contract can be traded. Each role is represented by a token on the chain, and transferring this transfers the ability to perform the role’s actions. Taking this further, we can represent a single role with multiple tokens, thus allowing the role to be shared: this could be termed being ‘securitized’.

The Marlowe system

We deliberately chose to make the language as simple as we can, so that it is straightforward to implement on Cardano and in the Marlowe Playground. Marlowe describes the flow of cryptocurrencies between participants, and for this to be implemented in practice on the Cardano blockchain, code has to be executed both on-chain and off-chain: remember, though, that just one Marlowe contract describes both parts. The on-chain part accepts and validates transactions that conform to the requirements of the smart contract: this part is implemented as a single Plutus script for all Marlowe contracts, with the particular Marlowe contract comprising a datum passed through the transactions. Off-chain, the Marlowe contract will be presented via the user interface and wallet, offering or, indeed, automating deposits and choices and receiving cryptocurrency payments.

Figure 1. Marlowe Playground simulates the ways that contracts behave

In the Playground we’re able to simulate contract behavior, so that potential users can walk through different ways that contracts will evolve, according to different actions taken by the participants. In the main simulation, Figure 1, users have an omniscient point of view and are able to perform actions by any participant, with the option at each point to undo the actions taken, and then to take a different path. The wallet simulation allows users to see behavior from one particular participant’s perspective, thus simulating how that user will interact with the running contract once it is deployed on the blockchain.

This simplicity also makes it possible for us to model Marlowe contracts in an SMT solver, a logic system for automatically checking the properties of systems. Using this model, which we call static analysis, for each contract we are able to check whether or not it might fail to fulfil a payment, and if the contract can fail we get evidence of how it fails, helping the author to rewrite the contract if they wish.

We can build a formal model of our implementation in a proof assistant, in which we are able to produce machine-checked proofs of how the language behaves. While the SMT solver works for individual contracts, the proof assistant can prove properties of contract templates, as well as the system itself: for instance, we can show that in any running contract, the accounts it references can never be in debit. Simulation, static analysis, and proof provide complementary levels of assurance for a contract to which users will be committing assets to ensure that the contract behaves as it should.

Writing Marlowe contracts

We have seen how Marlowe contracts can be analysed in various ways, but how do authors actually write smart contracts in Marlowe? The Playground provides several ways of producing Marlowe contracts. Users can write Marlowe directly, but beginners often choose to build contracts visually, using an interactive Blockly editor. Figure 2 shows a section of an escrow contract.

Figure 2. An escrow contract in Playground’s interactive Blockly editor

Working in this visual editor has the advantage of showing all the options as you select how to fill in a part of the contract that is being developed. Alternatively, you can develop contracts in Haskell, because the Marlowe DSL is in fact embedded in Haskell. Figure 3 shows the same contract in Haskell: the blue and purple parts are Marlowe, and the black components are defined in Haskell, as abbreviations that make the overall contract more readable. This approach allows users to build up a smart contract step by step from components. In the code shown in Figure 3, the roles, Alice and Bob, are each asked to make a choice: if their choices match, they agree, and the contract proceeds one way; if not, then a third participant, Carol, is asked to arbitrate between them. The contracts agreement and arbitrate are defined later in the Haskell file.

Figure 3. The escrow contract in Haskell

Users will also be able to write their financial smart contracts using JavaScript, while still enjoying all the advantages of analysis, simulation, and proof, as provided by the Marlowe implementation.

Oracles

One of the first questions we get asked when we describe Marlowe is about financial oracles, or how we can get a contract to take account of external data values, such as the exchange rate between ada and bitcoin. Abstractly, an oracle is just like a participant that makes a choice, and so the semantics of Marlowe can already deal with external values. However, we plan to support oracle values as part of the implementation, allowing contracts to access values directly from a stock market ticker or a data feed such as Coinbase. At the same time, the Plutus team is researching the best way to deal with oracles in general, and we can expect support for that in due course, though maybe not in the first full release of Marlowe and the Plutus Application Framework.

Actus for financial contracts

Marlowe has the potential to give people the chance to make financial commitments and trades without a third party facilitating it: the blockchain ensures that the contract is followed.

We are building a Marlowe implementation of disintermediated contracts to offer to end users who want to make peer-to-peer financial deals directly without the intervention of any third parties.

The Actus Financial Research Foundation categorizes financial contracts by means of a taxonomy that is described in a detailed technical specification.

Actus builds on the understanding that financial contracts are legal agreements between two (or more) counterparties on the exchange of future cash flows. Historically, such legal agreements are described in natural language, leading to ambiguity and artificial diversity. As a response, Actus defines contracts by means of a set of contractual terms and deterministic functions mapping these terms to future payment obligations. Thereby, it is possible to describe most financial instruments through 31 contract types or modular templates.

Next, we look at a simple example, and then we explain our full approach to implementing Actus, with complementary approaches providing different pros and cons.

A first Actus example

A zero-coupon bond is a debt security that does not pay interest (a coupon) but is issued at a discount, rendering profit at maturity when the bond is redeemed for its full face value.

For example, Figure 4 describes a contract whereby an investor can buy a bond that costs 1,000 lovelaces with 15% discount. She pays 850 lovelaces to the bond issuer before the start time, here slot 10.

Later, after maturity date, slot 20 here, the investor can exchange the bond for its full notional value, ie, 1,000 lovelaces.

Figure 4. Contract for a zero-coupon bond with a 15% discount

This contract has a significant drawback. Once the investor has deposited the 850 lovelaces, it will be immediately paid to the issuer; if the investor does not invest quickly enough, ie before the timeout, the contract ends. After that, two outcomes are possible:

• the issuer deposits 1,000 lovelaces in the investor's account, and that sum is immediately paid to the investor in full;
• if the investor doesn’t make the deposit, then the contract is closed and all the money in the contract is refunded, but there is no money in the contract at this point, so the investor loses her money.

How can we avoid this problem of the bond issuer defaulting? There are at least two ways to solve this: we could ask the issuer to deposit the full amount before the contract begins, but that would defeat the object of issuing the bond in the first place. More realistically, we could ask a third party to be a guarantor of the deal, as expressed here.

Figure 5. Improved contract with a guarantor

Actus in Marlowe

Products in the Actus taxonomy, such as the principal at maturity contract, can be presented in different ways in Marlowe, according to the degree to which they can accept changes to their terms during the contract lifetime (Figure 6).

Figure 6. Actus taxonomy and Marlowe

In the simplest case, all cash flows are set, or frozen, at contract initiation, so that it is entirely predictable how the contract will operate, assuming that all participants continue to engage with the contract during its lifetime. Contracts of this kind we call Actus-F (for fixed or frozen).

Dynamism – that is change during contract evolution – can happen in two ways. Participants can make unscheduled payments that require re-calculation of the remaining cash flows, and also the cash flows can be modified by taking into account external risk factors. The full generality of contracts that do both are modelled in Actus-M (for Marlowe).

There are intermediate levels too: Actus-FS models fixed schedules: allowing risk factors to be taken into account, but with no unexpected payments; conversely, Actus-FR contracts allow payments to be made at unexpected points, but do not take into account any risk factors.

Finally, moving outside Marlowe, Actus-H (H for Haskell) models the contracts directly as programs in Plutus or Haskell, using Marlowe for validation of each transaction in the contract lifetime by generating Plutus code from the Marlowe description of the contract logic.

Why do we offer these different models of Actus contracts? The reason is that there is a trade-off between the dynamic nature of contracts and the assurance we can give to users about how the contracts will perform in advance of contract execution.

• Actus-F contracts present an entirely fixed schedule of payments, which can be scrutinized directly by the participants so that it is straightforward to see, for example, that all payments from such a contract will succeed.
• Actus-FS and -FR contracts present more dynamism, but the contracts are readable and easy to scrutinize. Moreover, they are subject to (slower) static analysis to establish, for example, that all payments will succeed.
• Actus-M contracts are expressed in Marlowe, and so can be analysed. Analysis is, however, substantially slower because of the unpredictability of the actions that the contract will undergo at any particular point in time. Note that assurance can be offered for scaled-down versions of contracts, which have the same computational content, but which evolve over a shorter time, thus involving fewer interactions.
• Actus-H contracts are written in a combination of Plutus and Marlowe, and so are not amenable to static checking in the same way as the others. However, this platform offers corporate clients full extensibility and tailoring of the implementation of the Actus standard.

In our implementation of Actus, available as a pre-release version in the Labs tab of the Playground, users are able to generate Actus-F and -FS contracts from the terms of the contract, using a visual presentation of the data required.

Figure 7. The three items with asterisks are required for a principal at maturity contract

For a principal at maturity contract, three items are required: the start and end date, and the notional amount of the contract (hence the items being starred in the template). Such a contract will comprise a simple load, in which the notional amount is transferred from the counterparty to the party at the start of the contract, and in the reverse direction at the maturity date.

Adding additional items will change the generated contract accordingly. In Figure 7, the party will have to transfer the notional plus the premium to the counterparty at maturity date, hence giving the counterparty an incentive to make the loan in the first place.

Moving into a DeFi world with smart contracts

As we have seen, finance professionals and developers now have a way to start creating financial smart contracts directly in Haskell or pure Marlowe, or visually, using the Marlowe Playground, depending on their programming expertise. In the Playground, you can simulate and analyse the contracts you create to test that they work properly and are ready to be issued into the world of decentralized finance when the Goguen stage of Cardano is implemented. IOHK’s Marlowe team will continue implementing examples from the Actus standard, as we prepare to finalize the implementation of Marlowe on Cardano, and bring financial smart contracts to the blockchain itself.

In this post, we introduce Marlowe, a new language for financial contracts, and describe the benefits of it being a domain-specific language (DSL). As a DSL it describes only financial contracts, rather than smart contracts in general. Because of this, it differs from general-purpose blockchain languages like Solidity and Bitcoin Script.

Marlowe is industry-scale. We have built Marlowe contracts based on examples from one of the leading projects for financial smart contracts, the Algorithmic Contract Types Unified Standards (Actus) system. Currently, these and other examples can be seen in the Marlowe Playground, a browser-based environment in which users can create, edit, simulate, and analyse Marlowe contracts, without having to install or pay for anything.

Who can use Marlowe? Marlowe is a platform for decentralized finance (DeFi) that supports direct, peer-to-peer lending, contracts for difference (CFD), and other similar instruments. Financial institutions can use it to develop and deploy custom instruments for their customers and clients, for example.

As a part of the Goguen rollout, we will be completing the implementation of Marlowe on Cardano, giving users and organisations the opportunity to execute DeFi contracts they have written themselves or downloaded from a contract repository, transferring cryptoassets according to the contract terms. Marlowe will run first of all on the Cardano blockchain, but it is not tied to Cardano, and could run on other blockchains in the future.

Smart contracts running on Cardano will be able to access external data values, such as the exchange rate between ada and bitcoin, through oracles. In some ways, an oracle is just like a participant that makes a choice, and we plan to support oracle values as part of the implementation, allowing contracts to access values directly from a stock market ‘ticker’ or a popular data feed such as Coinbase.

Marlowe contracts can be used in many ways: for instance, a Marlowe program can automate the operation of a financial contract that transacts cryptocurrencies on a blockchain. Alternatively, for audit purposes, it could be used to record compliance of users’ actions to a contract being executed in the real world.

Marlowe is just one example of a DSL running on a blockchain, but it is also an exemplar of how other DSLs might be created to cover supply-chain management, insurance, accounting, and so on, leveraging the experience of designing and building Marlowe on the Cardano platform.

We have stressed that Marlowe is a special-purpose financial DSL, but what if you want to write other kinds of contract? To write those, Cardano has Plutus, a general purpose language running on the blockchain. Plutus contracts can handle all kinds of cryptoassets, and don’t have the constraints of Marlowe contracts: for example, they are unconstrained in how long they will remain active, and in how many participants they can involve. Indeed, every Marlowe contract is run by a single Plutus program, the Marlowe interpreter.

Marlowe as a domain-specific language for DeFi

Being domain-specific, rather than general purpose, has a number of advantages.

Contracts are written in the language of finance, rather than the language of the blockchain. This means that some sorts of errors are impossible to write: so certain kinds of incorrect contracts are ruled out completely. For example, every Marlowe contract will have a finite lifetime after which it will perform no further actions, and at that point any funds tied up in the contract will be returned to the participants, meaning that funds in a contract can never be locked up indefinitely.

It is possible to analyse, completely automatically, how a contract will behave in all circumstances, without having to run it. For example, it is possible to determine whether a particular contract can fail to make a payment in some cases, or whether it is guaranteed to make full payments in every eventuality.

Contract behaviour can be simulated in a browser, so that users can try out the different ways that a contract might behave, before committing funds and running it for real.

Users can create their DeFi contracts in different ways: they can write them as text, but also use visual programming to create smart contracts by fitting together blocks that represent the different components. Users can also choose from a range of templates and customise them as needed.

Next steps – and some prize challenges

Currently, Marlowe contracts can be written in Haskell or JavaScript or directly in Marlowe, and visually, using the Marlowe Playground, where it is also possible to simulate and analyse those contracts. Over the next few months we will continue revising and improving the user experience provided by the Playground, and continue implementing examples from the Actus project. At the same time, we will finalise the implementation of Marlowe on Cardano, so that Marlowe contracts will run on the blockchain itself. We look forward to sharing that work with you as soon as it is ready.

In the meantime, take a look at Marlowe Playground or join in one of the two Marlowe-based challenges running this month – there’s a $10,000 cryptocurrency fund to tackle the United Nations’ global development goals, and a $5,000-prize Actus event at the Wyoming Hackathon.