Company Name (if applicable)

Project details

Overview

This proposal is for an open-source, decentralized multiparty escrow (MPE) solution on Cardano’s Extended UTxO (EUTxO) model, aimed at secure payments through Multiparty validation. We propose a simplified approach by leveraging Cardano transactions as message equivalents, removing the need for complex cryptographic primitives. This will streamline the validator’s design while maintaining robust security. Key features include single-channel interaction per transaction and automatic prevention of double-spending by design.

This design prioritizes transaction security and ease of use while providing flexibility for future enhancements, aligning with the goals of decentralization, efficiency, and accessibility.

Implementation Details

• Open Channel: A State Thread Token (STT) minting policy will validate initial channel UTxOs by minting a unique token for each channel, ensuring only legal states. Any channel UTxO must include this STT, preventing illegal UTxOs. At this moment, the channel owner is set.

• Checks: Minting of channel STT, sending STT and tokens to channel validator.

• Modify Channel: Allows any party to add funds or, if signed by the service consumer, extend expiration. Modifications rely on transaction validity intervals as a proxy for current time.

• Checks: Fund additions, expiration extension if signed, and STT return.

• Close Channel: When signed by the owner and expiration has passed, the remaining funds can be claimed, and the STT burned.

• Checks: Owner signature, validity after expiration, STT burn.

• Claim: The STT is returned, with checks consistent with specifications to ensure safe and intended usage.

We will simplify the "message" system to use Cardano transactions instead. If a transaction was signed by a given party, that is equivalent to signing a message and checking for the signature in the validator. This allows us to cut costs on developing required cryptographic primitives and simplifies the implementation of the validator. More precisely, it allows us to not bother with the possibility of using the same message twice (with some sort of on-chain set) because even if the same signed transaction is submitted twice, it will be rejected the second time as inputs were already spent, providing the same security guarantees at way lower implementation time. The other limitation will be to allow interactions only with one channel at a time in the same transaction (this may get lifted, depending on implementation of `Claim` redeemer we may get this one for free).

### Open Channel

Because anyone can create any UTxO at any validator we need a way to distinguish between legal and illegal initial states. This can be done by a STT minting policy that gets invoked when creating channel UTxOs. Any spending of channel UTxO requires this STT to be present so all illegal UTxOs are automatically unspendable. Moreover, the specification requires us to mint a unique token for each of the channels and STT can fulfill this requirement simultaneously. During the mint the policy will check if datum of the channel UTxO is not malformed.

#### Checks

• Mint channel STT with channel STT minting policy

• This verifies channel datum fields

• Send channel STT to channel validator

• Send tokens in the same UTxO as STT

### Modify Channel

Channel modification can be done by anyone by spending channel UTxO, adding some tokens and returning it otherwise unchanged. There is a special case when this transaction is signed by the channel owner in which case they can also increase expiration period. Because it is impossible to know current time from within validator execution context, time checks are based on transaction validity interval. If transaction validity is enforced to be short enough (e.g. 10 minutes), we can approximate that "now" is the same as end of the validity interval.

#### Checks

• - Anyone can add funds

• - Expiration period can be extended if signed by channel owner

• - STT returned

### Close Channel

If transaction is signed by the channel owner and it is already past the channel expiration, the owner can claim all remaining funds by consuming channel UTxO and burning the STT. Note that time is being handled just like in the modification case.

Checks

• - Signed by channel owner

• - Validity range starts after channel expiration period

• - STT is burnt

### Claim

### Checks

• - STT is returned

• - Rest of the checks like in documentation

Estimated Execution Time: 4 Months

Team Requirements: 2 primary developers experienced in Haskell, Plutus, and decentralized payments.  1 Delivery Manager for oversight, 1 additional expert Developer for oversight.

Project Objectives

1. Smart Contract Development: Implement multiparty escrow using EUTxO with simplified transaction signing as a substitute for message verification.

2. Integration compatibility with SingularityNET: Integrate with SingularityNET’s marketplace for AI services to allow secure escrow-based transactions.

3. Open-Source Deployment: Release as an open-source project for broader community use and potential Catalyst-funded enhancements.

Open Source Licensing

Subject to change.

Links and references

Company site: mlabs.city
Github: https://github.com/mlabs-haskell