New 0.40-beta Release !

[nhenin]

The Marlowe team is happy to announce the 0.4.0 release :

General

• Marlowe Template (PR-184) : Created a new experimental package @marlowe.io/marlowe-template that helps to share the parameters used in the creation of a Marlowe contract.

• Initial Account Deposits Feature Integration (Runtime v1.0.0): (PR-188)

  • Purpose: This update introduces the capability for users to make initial deposits into their accounts upon creation. This feature aims to streamline the account setup process and enhance user experience.
  • Benefits: This feature squashes the Contract Creation and Initial Input Deposits into 1 transaction instead of multiple ones.

• Introduction of a New Contract API in the Runtime Lifecycle API: (PR-188) :

  • Purpose: The addition of a new Contract API is designed to provide developers with more flexibility and control (contract instance concept) over smart contract management within the runtime environment.
  • Benefits: Developers can now leverage enhanced functionalities for deploying, updating, and interacting with smart contracts. This API simplifies complex contract operations and supports more robust smart contract development.

• Experimental CIP-45 support (PR-179) : An example shows how to use the @marlowe.io/wallet/peer-connect module together with the https://github.com/fabianbormann/cardano-peer-connect library.

@marlowe.io/wallet

• Feat: Added a @marlowe.io/wallet/peer-connect module to enable mobile support by adapting to the cardano-peer-connect library. (PR-179)

@marlowe.io/language-examples

• Feat: Atomic swap v2 : Simplified version using the new runtime v1.0.0 feature (initial account deposits)
  • see end-to-end tests for examples (e.g : swap.ada.token.e2e.spec.ts)

@marlowe.io/runtime-rest-client

• mkRestClient provides optional strict parameter for performing dynamic type checking in RestClient methods. (PR-180)

• BREAKING CHANGE The following RestClient methods uses keyword argument object instead of positional arguments. (PR-180)

  • createContractSources
  • getContractById
  • submitContract
  • getTransactionsForContract
  • submitContractTransaction
  • getContractTransactionById
  • getWithdrawalById
  • submitWithdrawal

• Feat: initial account deposits (runtime v1.0.0) for Contract Creation (BuildCreateContractTxRequest via buildCreateContractTx):(PR-188)

@marlowe.io/runtime-core

• Feat: Added AddressBech32 validation using the lucid library (PR-184)

• Fix: Added proper type guards to Metadata (PR-184)

• Fix: Branding of ContractId and TxId (PR-185)

• Feat: initial account deposits (runtime v1.0.0) for Contract Creation (PR-188):

  • Added export type AccountDeposits = { [key in AddressOrRole]: AssetsMap }; and associated utility functions.

@marlowe.io/runtime-lifecycle

• Feat (PLT-9089): Added support for contract bundles in the lifecycle.contracts.createContract function. (PR-167)

• mkRuntimeLifecycle provides optional strict parameter for performing dynamic type checking in RestClient methods. (PR-180)

• Fix: Temporal fix for converting the cardano time interval to the Marlowe time interval in getInputHistory (PR-181)

• Feat: Added a new experimental API for computing, simulating and applying the next applicable Actions/Inputs. (PR-187)

• Doc: Improved package main documentation (PR-187)

• Feat: New Contract API packages/runtime/lifecycle/src/generic/new-contract-api.ts (PR-188):

  • Generic waitConfirmation() : same for contract creation and apply inputs
  • Seamless Integration of Applicable Actions API
  • simplfied interface (create and load with a concept of ContractInstance object)
  • see end-to-end tests for examples (e.g : swap.ada.token.e2e.spec.ts)

• Feat: initial account deposits feature (runtime v1.0.0) for Contract Creation (PR-188):

  • new parameter field accountDeposits in
  • e.g.

const sellerContractInstance = await sellerLifecycle.newContractAPI.create({
  contract: swapContract,
  roles: { [scheme.ask.buyer.role_token]: mintRole("OpenRole") },
  accountDeposits: mkaccountDeposits([[scheme.offer.seller, seller.assetsProvisioned]]),
});

@marlowe.io/marlowe-object

• BREAKING CHANGE Feat: Added Annotations to the contract type. (PR-181)
• Experimental Feat: Added a sourceMap API to match the annotated marlowe-object source with the ContractClosure. (PR-181)

Full Changelog: 0.3.0-beta...0.4.0-beta

[ErickRomeroDev]

Hi Marlowe team, I wanted to share some of my recent findings from testing the latest release of the TS-SDK

BUG DETECTION

• Issue using Marlowe wallet implementation with Nextjs (App Router). It is a problem related to Nextjs webpack implementation working with Lucid library. Solution is to use a separate backend in the meantime.
• The algorithm of NewApplicableAction (myActions) works fine when there is only one role token in my wallet (from the same assetname). However, once I have more than one token, the algorithm seems to think I have none
• The lifecycleNami.payouts.available() function is constrained by the number of NFTs present in the user's wallet. When the user possesses an excessive number of NFTs (exact threshold unknown, but over 100 NFTs were noted during testing), the function returns [object Object] rather than providing the list of available payouts.

FEATURES REQUESTED

• Minting several tokens with same policy+assetname and send them to different addresses during contract creation
• Another feature nice to have would be the option to be able to search for open roles based on contracts, labels.
• i have another "feature" that could be included in the short-term. More than a feature, it is a request to include it back, since in previous TS-SDK version this function result was included.
  In the present TS-SDK 0.4, the result of the fucntion withdraw is empty, and in previous versions it return the TxId, which should be the case.
• It would be nice for the TS-SDK give some warning related to this restriction (external payout + open role), could be during the input creation or even better, if possible, during the contract creation

[ErickRomeroDev]

Next15 solved the issue (created a workaround) with Marlowe wallet and Lucid on Server components