Point Release 1.1.0

[ggobugi27]

New Features and Changes

1. New concrete policy: non-updatable-uri-policy

What is it?
The new policy enforces that a token's URI is never upgradable when added to a policy list.

Action Item for Builders:

• Understand and implement the new policy in tokens that do not want updatable-uri feature.
• Check if util-v1 functions are being used and refer to Adjustment of marmalade-v2.util-v1 to support non-updatable-uri-policy

2. rotate creator information in Royalty Policy

What is it?
marmalade-v2.royalty-policy-v1.rotate function is newly added, allowing creator to rotate the creator information.

Action Item for Builders:
Alert users with the new functionality, and implement the functionality in apps.

3. Reintroduction of creator-guard in the marmalade-v2.ledger.CREATE-TOKEN capability

Reason: The creator-guard field was removed in the last upgrade to improve user experience. However, to enhance security and consistency in the capability signing process, we've decided to reintroduce it.

Action Item for Builders:
Update
(marmalade-v2.ledger.CREATE-TOKEN token-id)
to
(marmalade-v2.ledger.CREATE-TOKEN token-id creator-guard)

4. Sales in dutch-auction and conventional-auction that did not create auction can bypass enforce-withdrawal check

Reason: Mal-formed sales with sale-type=marmalade-sale.conventional-auction or sale-type=marmalade-dutch-auction and sale-price != 0.0 cannot be withdrawn. Bypassing the auction-completion checks at sale-contract::enforce-withdrawal enables a method for withdrawals.

Action Item for Builders:
N/A

5. Change in event emissions sale-contracts

Details:

• (marmalade-sale.dutch-auction.AUCTION_UPDATED token-id sale-id) is newly introduced at marmalade-sale.dutch-auction.update-auction
• (marmalade-sale.conventional-auction.AUCTION_UPDATED token-id sale-id) is newly introduced at marmalade-sale.conventional-auction.update-auction
• (marmalade-sale.conventional-auction.AUCTION_CREATED token-id sale-id escrow-account) is modified to
  (marmalade-sale.conventional-auction.AUCTION_CREATED token-id sale-id)
• (marmalade-sale.conventional-auction.BID_PLACED bid-id bidder bidder-guard bid token-id ) is modified to
  (marmalade-sale.conventional-auction.BID_PLACED bid-id sale-id)
• (marmalade-sale.dutch-auction.PRICE_ACCEPTED sale-id buyer buyer-guard price token-id) is modified to
  (marmalade-sale.dutch-auction.PRICE_ACCEPTED sale-id token-id)

Reason
To minimize event emission, we've removed additional data that can be looked up from the escrow-account, or retrieve-auction function from the events.

Action Item for Builders:

• Ensure the removed data from the events fetched from the escrow-account, or retrieve-auction calls.
• Integrate the new event, AUCTION_UDPATED

6. Adjustment of marmalade-v2.util-v1 to support non-updatable-uri-policy

Reason
To add support for the new concrete policy, non-updatable-uri-policy, we've added the new field to the schema, marmalade-v2.util-v1.concrete-policies and added/modified defconsts, and functions with details below.

Details

• adjustment of marmalade-v2.util-v1.concrete-policy-bool schema

(defschema concrete-policy-bool
    non-fungible-policy:bool
    royalty-policy:bool
    collection-policy:bool
    guard-policy:bool
  )

was modified to

(defschema concrete-policy-bool
   non-fungible-policy:bool
   royalty-policy:bool
   collection-policy:bool
   guard-policy:bool
   non-updatable-uri-policy:bool
 )

Updated/newly introduced functions

• util-v1.mint-basic-NFT was updated to include a non-updatable-uri-policy.
• util-v1.create-token-with-uri-guard is newly introduced

Newly introduced defconsts:

• DEFAULT_NON_UPDATABLE
• DEFAULT_ROYALTY_NON_UPDATABLE
• DEFAULT_COLLECTION_NON_UPDATABLE
• DEFAULT_COLLECTION_ROYALTY_NON_UPDATABLE

Action Item for Builders:

• Update the util-v1 functions to use the updated concrete-policy-bool schema:
  • marmalade-v2.util-v1.create-policies
  • marmalade-v2.util-v1.create-concrete-policy
• Incorporate the new non-updatable-uri-policy field and utilize the new defconsts and functions where applicable.

Sample Scripts

Sample scripts of marmalade functions are available here

Deployment Schedule

Testnet Deployment : Friday, 5/24/2024
Mainnet Deployment : Friday, 6/7/2024

[daplcor]

Is there any way to remove the requirement to sign as the users with in WITHDRAW once the timeout is expired? So we could scrape and remove any sales that are in timeout in ledger.pact? Users having to go back and manually withdraw vs being able to have a bot/process scrape/remove will make it more robust for marketplaces. this will be especially important if we have other active services using the V2 ledger. If we just tweak the if statement and remove guard signing with this series of code it should still maintain security since timeout will be expired.
;;Step 0, rollback: withdraw
(let ((token-info (get-token-info id)))
(with-capability (WITHDRAW-CALL id seller amount timeout (pact-id))
(marmalade-v2.policy-manager.enforce-withdraw token-info seller amount timeout (pact-id)))
(with-capability (WITHDRAW id seller amount timeout (pact-id))
(withdraw id seller amount))
(pact-id)
)

(defcap WITHDRAW:bool
(id:string seller:string amount:decimal timeout:integer sale-id:string)
@doc "Withdraws offer SALE from SELLER of AMOUNT of token ID after timeout."
@Managed
(compose-capability (SALE_PRIVATE sale-id))
(if (= 0 timeout)
(enforce-guard (at 'guard (details id seller)))
(enforce (not (sale-active timeout)) "WITHDRAW: still active")
)
(compose-capability (DEBIT id (sale-account)))
(compose-capability (CREDIT id seller))
)

[ggobugi27]

Is there any way to remove the requirement to sign as the users with in WITHDRAW once the timeout is expired? So we could scrape and remove any sales that are in timeout in ledger.pact? Users having to go back and manually withdraw vs being able to have a bot/process scrape/remove will make it more robust for marketplaces. this will be especially important if we have other active services using the V2 ledger. If we just tweak the if statement and remove guard signing with this series of code it should still maintain security since timeout will be expired. ;;Step 0, rollback: withdraw (let ((token-info (get-token-info id))) (with-capability (WITHDRAW-CALL id seller amount timeout (pact-id)) (marmalade-v2.policy-manager.enforce-withdraw token-info seller amount timeout (pact-id))) (with-capability (WITHDRAW id seller amount timeout (pact-id)) (withdraw id seller amount)) (pact-id) )

(defcap WITHDRAW:bool (id:string seller:string amount:decimal timeout:integer sale-id:string) @doc "Withdraws offer SALE from SELLER of AMOUNT of token ID after timeout." @Managed (compose-capability (SALE_PRIVATE sale-id)) (if (= 0 timeout) (enforce-guard (at 'guard (details id seller))) (enforce (not (sale-active timeout)) "WITHDRAW: still active") ) (compose-capability (DEBIT id (sale-account))) (compose-capability (CREDIT id seller)) )

ledger.withdraw does not require the seller's signature after the timeout. The seller's guard is only required if timeout is set to 0. However, the cap is still required to be in scope, but can be signed with any keypair.

This is the test case written for the specific case:
https://github.com/kadena-io/marmalade/blob/main/pact/ledger/ledger.repl#L196:L199

[daplcor]

My apologies. You are absolutely correct, and I omitted an important detail. The issue was expired auctions, which, unfortunately, also use timeout = 0.

[ggobugi27]

My apologies. You are absolutely correct, and I omitted an important detail. The issue was expired auctions, which, unfortunately, also use timeout = 0.

For this I would suggest using the timeout in the ledger that is equal to the auction's end-date parameter, as we don't have restrictions to timeouts. However, timeout=0 would allow flexibility in auctions such as update-auction

[daplcor]

Thank you, I thought we were always supposed to do timeout 0 for auctions, so I'll test that out. Appreciate the info!