Concept

Reading into the limitations and benefits of Marlowe, it appeared that because the contract does not stay on chain permanently, Marlowe particularly excels at single use financial agreements. As a result I decided to build a contract that facilitates something that can only happen once for any organization, defi project, or DAO, a merger.

How it works

  1. The merger fund will submit some amount of tokens for this contract to send to the end user.
  2. The user of this contract will deposit their tokens.
  3. An on chain oracle will submit a value for one time period
  4. The on chain oracle will wait some time and submit again.
  5. These prices will be averaged out.
  6. A new token representing the merger of TokenA and TokenB will then be given to the shareholder.
  7. The old tokens will be burned.

Environmental Assumptions

This contract makes a few assumptions for the environment it will be deployed in

  1. A frontend will submit this contract along with a call to a plutus contract that controls the new fund for the merged company. This plutus contract will submit an amount to deposit for the merger contract, and the frontend will pre-fill the constant values for shareholder deposits before deploying.
  2. Deposits from shareholder to interim roles can be controlled by shareholder after contract ends.
  3. The newly merged organization has paid careful attention to tokenomics, particularly so they don't run out of new tokens to supply the plutus contract before burning all of the pre-merger underlying tokens.
  4. There is some on chain oracle contract, or a helper contract that can submit choices for this contract to find the price of token A relative to token B.

Challenges

Early on I was feeling ambitious enough to attempt directly editing the plutus playground to both create new features for building contracts, and at the same time build a contract for myself. Halfway through the weekend, once I finally had the development environment set up, I realized I didn't have time to learn enough PureScript to build a quality commit. As a result I pivoted to building this Contract.

What's next for Marlowe-Company Merger

For this project in particular I made a few assumptions about what is necessary for a Marlowe contract. I plan to examine the following assumptions given further time:

  1. Tokens that we wish to burn should be sent to the 0 address
  2. I made estimates that are probably not realistic for the slot timing of functions.
  3. I'm not certain that I used Account of and Party correctly in this contract.
  4. There may be a more elegant way to find averages of two values on Marlowe.
    I was very surprised to see how powerful static analysis was for debugging, if I ever have short one-time contracts that need to be executed on chain, Marlowe may become my go to for quick and easy prototyping.

Built With

  • marlowe
Share this project:

Updates