tqtezos / minter-sdk Goto Github PK

Example: https://github.com/tqtezos/minter-sdk/pull/132/checks?check_run_id=2439803839

Note the result:

Test Suites: 1 failed, 1 total
Tests:       1 failed, 1 total

Yet, the runner sees the script as returning a non-error exit code.

The issue here is that spawn-jest-worker isn't passing through the spawned process' exit code. Listening to the exit event on the spawned process and returning its exit code in the main script should solve this.

Hello team,

We are actively looking for a way to mint 10000 unique NFT's. For now we have to mint them 1 by 1. We've been following the open minter project and this feature has been pushed back since v0.4

Are you still working on a way to do it, or have you given up on this feature ?

Seems interesting for large collection projects similar to crypto punks, hashmasks for example.

Thanks for the reply

#58 added a script which generates a JSON representation of a Michelson contract to facilitate idiomatic importing of contracts into a JavaScript project. This solution outsources Michelson parsing to the @taquito/michel-codec package. Unfortunately, this package often goes out of date with respect to the protocol, encountering parse errors on valid contracts. To mitigate this, we should use a canonical implementation like the tezos-client / RPC.

• Buy with permits entrypoint
• Delayed distribution after purchase

From here tezos-commons/baseDAO#154

The number of contract variations is growing rapidly, and with the current approach maintaining them becomes too problematic. For instance, for english_auction contract we have

• 2 versions fa2 vs tez
• per 3 versions of allowlisting for FA2 addresses/tokens (if we take #132 into account)
• per 2 versions with fixed fees
• some variations have versions with permits
• later: per 2 versions of allowlisting for admins that can be added in #12

Currently, to get a version of the contract with tez and simple allowlisting, I create a contract called english_auction_tez_allowlisted.mligo that sole purpose is to glue basic contract components and then add it to the TS compilation scripts. And so for every single contract configuration.

Apparently, we have to come up with a scheme where it will be possible to ask TS script to e.g. enable whitelisting in a specific mode, and the script will automatically glue the necessary contract components. This scheme must be transparent for developers, to avoid situations when a compilation error is raised for an obscure reason.

I have little experience of working with LIGO and preprocessor pragmas, but my preliminary suggestion would be to assume that to enable a certain component in a complex contract one always adds a corresponding #include statement. E.g. english_auction_tez_allowlisted.mligo consists solely of includes, and english_auction_tez_fixed_fee.mligo can be rewritten to consist of those.

The current version of fixed price sale contract uses unnecessarily complex big_map keys (a record of seller, and token info) for sales data. It would be better to just use nats as keys and move that data to the value.

Create a Minter contract that supports token creation abilities from a single administrator

Tests that interact with admin users require an admin user to be provisioned in the sandbox environment to execute successfully. We should automate this process such that tests don't require explicit user setup to execute correctly.

Via @emishur:
We can do two things:

• Modify existing flextesa image and bootstrap many test accounts. So, it gets maintained with any flextesa updates
• Bootstrap those accounts ourselves when starting the sandbox using taquito

Contract development can move independently of SDK development. It would also be nice to export the contracts as a discrete package in the event that consumers want to wrap the contracts on their own.

Set up yarn workspaces to facilitate parallel package development.

• Move existing contract code into packages/minter-contracts.
• Stub SDK client code at packages/minter-sdk

Integrate DIDkit to enable proofs of authenticity / tie to external accounts

fa2-auction-fee.test.ts reliably passes locally, yet reliably fails in CI. @EGuenz believes this is due to the combination of the inherent time sensitivity of the test and its execution on a slower machine (the CI runner node in the failure case).

We should tweak whatever time constants are at play to ensure the test reliably succeeds in CI.

Provide a README / specification for the minter collection similar to the Editions README: https://github.com/tqtezos/minter-sdk/tree/main/packages/minter-contracts/ligo/src/minter_collection/editions

It is not necessary for contract logic/should be handled offchain.

Create a Minter contract in which there's a specified admin and other administrators can be added via an allowlist.

This is a nitpick, but it could save you or an unfortunate user quite a bit of headache down the road: I suggest using either yarn or npm to manage deps, but not both, and, in particular, don't commit both yarn.lock and package-lock.json. They aren't always compatible, and weird things can happen, especially if you switch between the two.

Taquito supports initializing contract storage using a plain old javascript object (POJO). Update the origination helpers in nft-contracts.ts to represent initial storage as an object as such for readability.

We have new contracts incoming which will be in the form of "raw Michelson". Simply putting those in packages/minter-contracts/bin is not sufficient, as that directory is often cleared out during the compilation process.

Create a new directory to house the set of "raw Michelson" contracts. During the compilation process (alongside LIGO compilation), these contracts should be copied into the packages/minter-contracts/bin directory such that

1. The subsequent type-generation process will pick them up, and
2. ./bin can be safely blown away and properly regenerated during compilation.

We have various scripts and tests which rely on querying a Tezos environment to execute. As we'd like to execute these scripts and tests in a CI environment, we'll need to devise a solution for provisioning a Tezos sandbox (e.g., Flextesa) in Github Actions.

Integrate Fractional NFT DAO contract which allows holders of a fungible token to govern transfers and marketplace sale/auction of an FA2 NFT

• Implicitly testing ts bindings.
• Reduces code as we will be able to delete the temporary ts interfaces written for the same purpose.

A percentage of purchase should be sent to contract admin

We now have a compilation process which compiles LIGO to TypeScript. As such, the test helpers are now able to reference the compiled TypeScript directly (removing the need to compile at test time).

An additional advantage of this approach is that we're testing the same contract code consumers will be running.

tslint is deprecated. Configure eslint instead.

• Remove tslint
• Configure eslint
• Fix eslint errors that emerge as a result

They currently fail

Integrate FA2 bazaar contract for swapping FA2s w/ FA2s

Allow a designated address to append new metadata to enable dynamic NFT metadata

Example:

• Display a new opt-in visual layer inside of a marketplace or wallet UI on top of the original image of the NFT

• Minter / Collection: complete
• Fixed Price Sale (tez-FA2, FA2-FA2): complete
• English Auction (tez-FA2, FA2-FA2): complete
• Fractional Ownership: in development
• FA2-FA2 Bazaar Swaps: in development

Organize and add links to the locations of each of these key contracts in README a la @emishur 's Smart Contracts repo here: https://github.com/tqtezos/smart-contracts

Provide a checklist and basic sanity checks with which smart contract developers may assess whether or not their contract is ready to be reviewed.

Should include things like (among others):

• Does the contract implement admin checks
• Is the contract being tested against arbitrary values
• Does it include property-based tests

Add a version of fixed price/english auction in which admins only power is cancelling sales/auctions

We don't have a solution at the moment for distributing smart contracts via npm, much less providing a mechanism for them to be imported into a JavaScript project in an idiomatic fashion.

A quick and dirty method to get this over the line is to leverage @taquito/michel-codec's ability to output Michelson code as JSON. We can embed the generated JSON in a JavaScript module which will allow it to be idiomatically imported into a JavaScript project.

We'll need an additional script to facilitate this generation.

https://github.com/tqtezos/minter/blob/9bd894ec8c7a5a5a45d166f6b0c6b49c3810ddc7/contracts/ligo/src/english_auction_tez.mligo#L98

Shouldn't it be:

(Tezos.now <= auction.start_time + auction.auction_time) && (* the auction has not ended yet AND *)
(Tezos.now > auction.last_bid_time + auction.round_time) && (* round time has passed since the last bid AND *)
 Tezos.now > auction.start_time  (* auction has started *)

?

Since the second condition checks if the next bid can be placed, consider renaming the function to actually reflect what it checks (for instance can_place_bid)

As #64 is being addressed, and assuming all tests run reliably, it should be fairly simply to execute the jest tests against the flextesa sandbox.

Should leverage exploration performed to address #74 (in particular, https://github.com/tqtezos/minter-sdk/pull/81/files#diff-b803fcb7f17ed9235f1e5cb1fcd2f5d3b2838429d4368ae4c57ce4436577f03fR82)

The minter-contracts package doesn't have any documentation on how to integrate the package into a javascript/typescript project.

Currently, the swaps contract has a whitelisted version with the following properties:

• Only those FA2 contracts can participate in exchanges that are mentioned in the whitelist.
• Whitelist can be reset by the administrator via the Set_allowed entrypoint.

Now we would like to have similar functionality in marketplace and auction contracts.

Since I didn't know how whitelisting should work in other contracts, I've put it directly to swaps/fa2_whitelisted_swap.mligo. We need to think about whether that functionality is worth extraction and reuse, and have something similar in other contracts.

Details of how exactly the marketplace and auction contracts have to be updated - are to be clarified.