origin-byte/nft-protocol

Sui NFT Smart contracts maintained by the Origin Byte team

nft-protocol's Issues

Version key mismatch

The version key of a Kiosk object created directly from a package (version 1) and a Kiosk object created through another package are currently mismatched (version 3).
Could someone explain to me what the difference here is, if any, and as far as I know, the latest version is 2, so where is version 3 being created from? Many thanks

• 0xbe3375037f23156a9c4119f274b8e4fd4e06d2beb615b23b0e7dc86876858cb3 (version 1)
• 0x211de3b032fe89d3a5addb2e9ac7dea23a4e7eeefb4a674a955c088bb35eba24 (version 3)

Why we use "TypeName" directly as key, instead of a custom key containing the "TypeName" as key?

nft-protocol/contracts/allowlist/sources/allowlist/allowlist.move

Line 222 in fc0950c

df::add(&mut self.id, collection, true);

we could have key like:

struct CollectionTypeKey { type: TypeName } 

In this way, we can avoid using the same key with other protocols.

Incorrect payment recipient in orderbook

In the settle_funds_with_royalties call in orderbook, the recipient should be seller/owner, not buyer/sender.

https://github.com/Origin-Byte/nft-protocol/blob/main/sources/trading/orderbook.move#L1125

Setup CI

Compile and run tests

Url needs semantic information

OriginByte protocol supports url domain for collection and nft object currently, which works fine for collection and nft launching, but it confuse the client how to read and display the url. NFT's url is used in three different ways to show content as I know.

1. metadata url (most are external ERC721 Metadata JSON)
2. image url
3. animation url

So, if url domain contains some semantic infos will be helpful for client to read and show off.

Cannot Init Warehouse

I am trying to publish a marketplace. I was following https://github.com/Origin-Byte/originbyte-js-sdk/tree/main/examples
I am able to create Fee, create Marketplace, create Listing. But when I try to initInventory method. I am getting

vmverificationordeserializationerror.

Then I tried to call init_warehouse method directly via explorer. Then I encounter with

Transaction failed with the following error. Error executing transaction with request type: Error: RPC Error: The response returned from RPC server does not match the TypeScript definition. This is likely because the SDK version is not compatible with the RPC server. Please update your SDK version to the latest.

My initInventory function:

import { NftClient } from "@originbyte/js-sdk";
import {
  PACKAGE_OBJECT_ID,
  NFT_MODULE_NAME,
  NFT_CLASS_NAME,
} from "../constants.js";

const initInventory = async (signer) => {
  const transaction = NftClient.buildInitWarehouse({
    packageObjectId: PACKAGE_OBJECT_ID,
    nftModuleName: NFT_MODULE_NAME,
    nftClassName: NFT_CLASS_NAME,
  });
  const initWarehouseResult = await signer.executeMoveCall(transaction);
  console.log(
    "initWarehouseResult",
    JSON.stringify(initWarehouseResult, null, 2)
  );
};

export default initInventory;

And these are my constants.

NFT_MODULE_NAME = "suimarines";
NFT_CLASS_NAME = "SUIMARINES";
PACKAGE_OBJECT_ID = "0x5ec4c18d783074abc4ebc71670c521d73b2c7009";

And I tried to call init_warehouse on explorer with this type arg:

0x5ec4c18d783074abc4ebc71670c521d73b2c7009::suimarines::SUIMARINES

Is there a problem with my code or is it about with sui version. What should I do?

Document orderbook events

What info do they contain? When are they triggered?

Should `TransferCap` contain information about whether the NFT is a generic or our type?

Implement RoyaltyDomain

Currently royalty fee calculations are passed as explicit field to Collection.

Should add a RoyaltyDomain as a domain on Collection.

Emit events in orderbook

There are at least 5 events which we should emit for marketplaces to follow state of the orderbook.

Local dependency mismatch error.

While publishing my move module that uses nft-protocol as a dependency it's causing the following issue.

Multiple source verification errors found:

- Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::transfer_policy
- Local dependency did not match its on-chain version at 0000000000000000000000000000000000000000000000000000000000000002::Sui::kiosk

Feature Proposal: Multiple update authorities

What/Why

What are you proposing?

I am proposing that the new NFT standard is build in a way to allow multiple update authorities on the same token. In order for an update to be made on a token, each of the update authorities would need to sign/approve the same message/transaction. This solution would improve the state of mutable tokens in the crypto space.

What users have asked for this feature?

Users are currently faced with the dilemma of not truly owning their NFT if it is mutable, as the update authority could change anything on the NFT when they would like.

https://looksmutable.com/mutable-nfts

What problems are you trying to solve?

With this proposal, we would solve the problem of non consensual updates on users tokens. In order for an authority to update a token, the user would need to approve this. The other way is also true, if a user wishes to update their token, they are able to with the approval of the other update authority(s).

What is the developer experience going to be?

Ideally when a NFT is minted, the user that mints the NFT is added to that NFT as an update authority, or when a NFT is transferred to another wallet.

What is the user experience going to be?

A user would need to use the Origin-Byte SDK or API to make changes on their NFT (unless a front-end is available). The user would receive a notification in their wallet/dapp regarding changes that need to be approved.

Simplify init market interface

Can't call fixed_price slingshot's buy_nft_certificate()

i tried calling buy_nft_certificate() from a fixed_price slingshot at 0x86c81d52b427a8e6ea6e3fe2cc513e2b1c2211ee
with the necessary params as shown here

but for some reason i was getting this error

RPC Error: Could not find the referenced object 0x5283b785eb906160a073748c517a1f556bb6e8e0 at version None.

which is weird as the address is referring to the wallet address, which obviously exists and could be found. I'm quite lost here does anybody knows if I'm calling the method incorrectly.

RFC: HTML domain for display standards

A suggestion for the display standards that came from 4th roundtable: HTML domain which can be parsed by wallets to provide interactivity.

Does it make sense to dedup Bid struct across trading contracts

    Does it make sense to merge this with auction bids?

Originally posted by @Suficio in #97 (comment)

Orderbook mustn't resolve a trade if the both seller and buyer are the same Safe

. /bin/publish.sh is wrong.

root@book:~/code/nft-protocol# ./bin/
[warn] Client/Server api version mismatch, client api version : 1.10.0, server api version : 1.8.2
Unable to find package manifest in '/root/code/nft-protocol' or in its parents

auction::cancel_all_bids endpoint

AuctionMarket only supports auction::cancel_bid but as a convenience should also support auction::cancel_all_bids.

Drop `TradePayment` when Sui supports destruction of shared objects

    Shouldn't this function also drop the `TradePayment`?

Originally posted by @Suficio in #55 (comment)

Display support some nessesary fields

I've been working on the protocol recently, I found that the standard only allows a few fixed fields for now, like adding name / description / url to the collection etc. I have some questions and I would like to provide more fields for the standard, like social media / website etc, some fields I think are necessary. Can these fields be supported.
I also noticed that there is an RFC for display, and it seems like a good solution to use dynamic object as a container for the fields to increase the flexibility of the fields, when will this solution be implemented?

Empty price_level in orderbook should be destoryed

Should check the the price_level is empty or not after removing item from it.
eg: https://github.com/Origin-Byte/nft-protocol/blob/testnet/sources/trading/orderbook.move#L1259

Otherwise this will break the assumption when match_buy_with_ask_
eg: https://github.com/Origin-Byte/nft-protocol/blob/testnet/sources/trading/orderbook.move#L845

Concluding auction may break computational limits

Concluding a large auction may cause computational or working memory limits to be breached.

Implement limited sale_conclude endpoint that awards a limited number of bids and does not cancel the remaining bids.

Consider failing explicitly when calculating royalty for a royalty strategy if that strategy does not exist

Currently if we call the function to calculate royalty for a given strategy the function will calculate the royalty amount of zero instead of failing. This can lead to silent failure anti-pattern where the creator thinks it has created a royalty strategy when it fact it hasn't.

public fun calculate_proportional_royalty(
    domain: &RoyaltyDomain,
    amount: u64,
): u64 {
    if (!contains_royalty_strategy<BpsRoyaltyStrategy>(domain)) {
    // TODO: This is dangerous because it can lead to
    // Silent Failures
    return 0
};

    let strategy = borrow_royalty_strategy<BpsRoyaltyStrategy>(domain);
    royalty_strategy_bps::calculate(strategy, amount)
}

Make `launchpad::inventory_mut` permissioned

Rename `transfer_whitelist` file to `transfer_allowlist`

    Ah I forgot to rename this file

Originally posted by @bausano in #186 (comment)

Protect mutable domains with AttributionDomain

TagDomain, DisplayDomain, etc. should expose mutable API protected by AttributionDomain.

Document where does the `ID` in`trade: Option<ID>` come from

    Where does the `ID` in`trade: Option<ID>` come from? Perhaps we can add some small explanantion on the comment

Originally posted by @nmboavida in #86 (comment)

Sale.tier_index is not documented

Sale.tier_index is not documented in user facing applications but necessary to call market APIs.

Please a branch for localnet, I hate removing published-at and swapping with 0x0 and publishing also the new directory structure requires a lot of work to publish :(

Market slingshot is toggled globally

FixedPrice and Auction markets both call slingshot::sale_off(slingshot); which disables interactions with markets across all sales tiers.

Slingshot should be reworked to toggle only the relevant sales channel and have explicit global toggles.

How to settle the TradePayment in the same Tx when user buy the NFT

I'm trying to simplify the user flow when buy/sell NFTs, and minimize the number of transaction users need to sign.
But I don't know how to get the TradePayment ID without executed and parsed the resut of the buy NFT transaction. This force me to create another transaction to settle the TradePayment.

I notice the "Programmable Transaction" is coming, but it also cannot access new object creation.
MystenLabs/sui#7790 (comment)

Error encountered while interacting with the testnet

I encountered an error while interacting with the testnet. Below is the error message I received:

Failed to build Move modules: Failed to resolve dependencies for package 'test_collection'

Caused by:
    When resolving dependencies for package NftProtocol, conflicting versions of package Permissions found:
    At Allowlist -> Permissions
        Permissions = { git = "https://github.com/Origin-Byte/nft-protocol.git", rev = "testnet", subdir = "contracts/permissions" }
    At Authlist -> Permissions
        Permissions = { local = "../permissions" }.

Steps to Reproduce:

1. Attempt to interact with the testnet.
2. Observe the error message mentioned above.

Expected Behavior:
I expected to interact with the testnet without encountering any errors.

Additional Context:

• This error occurs when attempting to build Move modules.
• It seems there are conflicting versions of the package 'Permissions' within the NftProtocol package.
• Here is the relevant portion of the Move.toml file:

[dependencies.Sui]
git = "https://github.com/MystenLabs/sui.git"
subdir = "crates/sui-framework/packages/sui-framework"
rev = "08119f95e9ccdc926eae3fff8c95e50678f56aed"

[dependencies.NftProtocol]
git = "https://github.com/Origin-Byte/nft-protocol.git"
subdir = "contracts/nft_protocol/"
rev = "testnet"

Possible Solution:
It seems that there might be conflicting versions of the 'Permissions' package. Investigating and resolving this conflict could potentially resolve the issue.

Any assistance in resolving this issue would be greatly appreciated. Thank you!

[Bug] Wrong kiosk owner in `dutch_auction::sale_conclude`

The sale_conclude is exercised by admin, so there is a bug here:

nft-protocol/contracts/launchpad/sources/launchpad/market/dutch_auction.move

Line 280 in c552230

let (kiosk, _) = ob_kiosk::new(ctx);

should be:
let (kiosk, _) = ob_kiosk::new_for_address(owner, ctx);

where the interface?

this so amazing, btw for several people want try this need some upgrade on your work sir, how we can test if UI not show up bro :D

Error Minting from simple.move example

Context
I'm trying to setup a NFT Collection with NFTs and i've managed to successfully deployed simple.move in examples

Commands Executed inside nft-protocol/example_collections/examples/sources

sui move build .
sui client publish --gas-budget 750000 

Which gave the following output
https://gist.github.com/JohnDotOwl/a3353e5b368210f5b751a07059a25401

Correct me if i'm wrong, i have to mint the "NFT" since the contract only creates the collection

sui client call --package 0x0a3285ff7a737c93217657ea9c222b849456b4589445de90ea3b43ad89145b77 --module example_simple --function mint_nft --args \
  "Ding Dong 1" \
  "Simple Ding Dong Collection" \
  "example.com" \
  0xa389b5fcde5f049e9bbe5570adf0ef04f7d4a857b563335d7049ce2b5e96d065 \
  --type-args 0xa3285ff7a737c93217657ea9c222b849456b4589445de90ea3b43ad89145b77::example_simple::SimpleNft --gas-budget 750000

Which will return

Error executing transaction: Failure {
    error: "VMVerificationOrDeserializationError in command 0",
}

The following are my objects
https://gist.github.com/JohnDotOwl/7cb7343e3323a2f6ddf35dd4747c8372

Explorer : https://suiexplorer.com/address/0x13f84db99218661638ddaffabab990dd4b1939f1397f9891de36c45eca6ea01

Any form of advice or support would be greatly appreciated , i would even create a guide once i figure this out so it's easier for people to get started. Thank you so much!

Do we want an endpoint to buy a specific NFT with commission?

Since it can be implemented by a marketplace or a wallet via a batched tx with a simple coin transfer, such an endpoint seems superfluous.

0xc7e5b1eed6ba571103d1f055410a40cd4e9859dd Dependency object does not exist or was deleted

who can help me what's wrong with this when I publish in sui devnet? I'm stuck in it.

New NFT Release Flow

Hitherto, the flow of releasing NFTs to users is mostly based on pre-minting Data objects and then allowing for the launchpad to mint the Nfts to the user (currently, embedded NFTs are pre-minted themselves and transferred them to the Launchpad, but this will be changed and will follow the same flow as the loose NFTs).

Whilst the launchpad is useful for great deal of use cases (mainly all that require some custom primary market solution), there are some use cases that would benefit from not having to use the launchpad. In order to better understand which use cases may not require a launchpad, let us define all the use cases and their release flow pattern:

1. The data is pre-minted on-chain and Users come to the protocol to mint the NFTs (e.g. Digital Art with on-chain attributes can be pre-emptively minted in preparation for the launchpad - similar flow to Solana's Candy Machine)
2. The data is pre-minted on-chain and Creators send the NFTs to users (e.g. For more asynchronous release flows such as the minting of gaming assets which happen when players are playing games)
3. The data is minted on the fly with the NFT and sent to the users where:
   a. The data is defined by the NFT module itself (e.g. for Simple NFTs where the data still remains off-chain, the NFT can be a simple URL where each time a NFT is minted a counter is increase and thus generating a URL for the corresponding image - see this issue for more)
   b. The data is defined by the users themselves (e.g. for Domain Names, the creators cannot possibly pre-emptively mint every single domain name, therefore users are the ones minting the data on the fly with the NFT and there should be a registry implementation that checks if a certain domain name already exists)

For the 1st pattern:

• MintAuthority → Must be a private object owned by the creators
• Launchpad → Must be a shared object

For the 2nd pattern:

• MintAuthority → Must be a private object owned by the creators
• Launchpad → There is no such thing as launchpad, the NFTs are minted directly by the MintAuthority

For the 3rd Pattern:

• MintAuthority → Must be a shared object
• The way data mint must be decided via:
  - some code logic (a)
  - or by the user, subject to set ownership test (via registry which is a probabilistic data structure)

Inventory should restrict buying NFT without deposit into a safe

          I think we could also add an endpoint `buy_nft_into_safe` (or something like that) that takes a reference to a safe that already exists.

Originally posted by @Suficio in #270 (comment)

@bausano:

This sort of leads into a question: how can a collection owner say they want the NFTs to be deposited into safe only. Because that is the royalty guarantee. Would they have to whitelist and build their own endpoint?

Cannot mint NFT due to ExecutionError (InvalidChildObjectArgument)

I am not really sure if it's better to post this issue in the js-sdk repo or this one. But here we go.

What I have done:

1. I generated a NFT smart contract using Gutenberg and then modified it a bit.
2. Reading this doc, I assumed this was still true so I put the contract under /sources directory, along with the existing nft-protocol modules.
3. I did change the addresses field in Move.toml from the existing one you had in your repo into 0x0, or otherwise I was NOT able to deploy it.
4. I was able to deploy it to the devnet doing above. Here is the transaction log (along with the object types I noted if you scroll to the right) to help with the investigation.

----- Transaction Effects ----
Status : Success
Created Objects:

  - ID: 0x0af31b3e465fa6aa9154ba07598fcb0e83373018 , Owner: Object ID: ( 0xf34412a0779ecccd4ab94e1cf9f7cf18eba3fd4a )			fixed_price::FixedPriceMarket | Price: 50 | WL
  - ID: 0x123d032bc405afcd4c07baff9cc7f1e659537d4a , Owner: Object ID: ( 0xa549433fd8c3bdcd1e8f9cffd0122e8f1f31de16 )			royalty::RoyaltyDomain
  - ID: 0x2c0681925d23ca1cb78321181fcb85fc102fee48 , Owner: Object ID: ( 0x6d1ad44fc7fd1d1e3e5b7195ee768c0314ccb230 )			tags::ProfilePicture
  - ID: 0x2e884cf6c2970356578b49351dc4e424dd777c0b , Owner: Object ID: ( 0x776d50ef7e581dfe996d271ab9243b4baf5e992a )			royalty_strategy_bps::BpsRoyaltyStrategy
  - ID: 0x3d61ee56dadda356dbd68ca97028ec166eafd281 , Owner: Object ID: ( 0xc18a8186c7a177dc5359a29135e7c5fdd957d139 )				dynamic_field::Field<0x2::dynamic_object_field::Wrapper<0x2::object::ID>, 0x2::object::ID>
  - ID: 0x3eb3968cd02a9ff3cd6225465de9fa23ad382bd1 , Owner: Object ID: ( 0x474be3d63ecd613cc42515671ced2d75ae462042 )			warehouse::Warehouse
  - ID: 0x474be3d63ecd613cc42515671ced2d75ae462042 , Owner: Object ID: ( 0x63b74833f4f2bf3c951324c098dc948666cb542b )			inventory::Inventory
  - ID: 0x5bf2ee1d9130ba8e192ca56c762c2b92a35c1a72 , Owner: Object ID: ( 0xa549433fd8c3bdcd1e8f9cffd0122e8f1f31de16 )			display::UrlDomain
  - ID: 0x63b74833f4f2bf3c951324c098dc948666cb542b , Owner: Object ID: ( 0xe5dc24013de505f2bfe6cbbe2d6ac7cc1499b187 )				dynamic_field::Field<0x2::dynamic_object_field::Wrapper<0x2::object::ID>, 0x2::object::ID>
  - ID: 0x6c590ef2d18964ea6144cd6ca4fce14265375aeb , Owner: Object ID: ( 0x7a782dd7dc4fdc6d7959a7a4c733b3d93d3ac593 )			venue::Venue | Price: 100 | Non-WL
  - ID: 0x7087e3e2377203d9dcd513ce688869c13c932021 , Owner: Object ID: ( 0xa549433fd8c3bdcd1e8f9cffd0122e8f1f31de16 )			creators::CreatorsDomain
  - ID: 0x7a782dd7dc4fdc6d7959a7a4c733b3d93d3ac593 , Owner: Object ID: ( 0xc18a8186c7a177dc5359a29135e7c5fdd957d139 )				dynamic_field::Field<0x2::dynamic_object_field::Wrapper<0x2::object::ID>, 0x2::object::ID>
  - ID: 0x961b5d0fff47027335dbc348f8fde285a529f21c , Owner: Object ID: ( 0xa549433fd8c3bdcd1e8f9cffd0122e8f1f31de16 )			tags::TagDomain
  - ID: 0xa25c6ca9d3edab04b467e0c8f565908ce1f46dbb , Owner: Object ID: ( 0x694df98ff755b0b8c3c5d7042bb7666d50ad9b65 )				dynamic_field::Field<0x2::dynamic_object_field::Wrapper<0x1::type_name::TypeName>, 0x2::object::ID>
  - ID: 0xa549433fd8c3bdcd1e8f9cffd0122e8f1f31de16 , Owner: Shared											collection::Collection
  - ID: 0xadc450540b8ae8b643d615e5c390696663bfd89b , Owner: Shared											marketplace::Marketplace
  - ID: 0xb13cfd2f6e363f13562479532af98cca97a2d387 , Owner: Object ID: ( 0xa549433fd8c3bdcd1e8f9cffd0122e8f1f31de16 )			display::DisplayDomain
  - ID: 0xbda23b210924e00b2484f5fbe4401357ec9807bc , Owner: Object ID: ( 0x6c590ef2d18964ea6144cd6ca4fce14265375aeb )			fixed_price::FixedPriceMarket | Price: 100 | Non-WL
  - ID: 0xc0576d426c37d0996cc8e837243acf3429d938fb , Owner: Shared											listing::Listing
  - ID: 0xc468803dd47b518c1e90632bb2d7a7aa34e8e664 , Owner: Account Address ( 0xe42d4c5e5fa231009f5d2342461ab877599e5b70 )		mint_cap::MintCap
  - ID: 0xe289fc2252ae6a959a3a3adc08070eda7ea10a69 , Owner: Object ID: ( 0xa25c6ca9d3edab04b467e0c8f565908ce1f46dbb )			flat_fee::FlatFee
  - ID: 0xec64f96d1d707179ed759f118f0309117d294e39 , Owner: Object ID: ( 0xa549433fd8c3bdcd1e8f9cffd0122e8f1f31de16 )			display::SymbolDomain
  - ID: 0xf34412a0779ecccd4ab94e1cf9f7cf18eba3fd4a , Owner: Object ID: ( 0x3d61ee56dadda356dbd68ca97028ec166eafd281 )			venue::Venue | Price: 50 | WL
  - ID: 0xf370d5bec6fc0a781072d3485b73d23689f710e7 , Owner: Object ID: ( 0x6d1ad44fc7fd1d1e3e5b7195ee768c0314ccb230 )			tags::Art
  - ID: 0xf8be87a3546a1558ae81ab3ac7e37615433b8c55 , Owner: Immutable											Package

5. I followed the examples on js-sdk repo. Since the Gutenberg-generated contract already defined marketplace, lising, etc. (hence the lengthy log above), I skipped step 1-4 and jumped to step 5 to mint the nfts.

export const mintNFt = async () => {
  const txs: MoveCallTransaction[] = [];
  for (let i = 1; i <= 10; i += 1) {
    txs.push(
      NftClient.biuldMintNft({ // 'biuld' seems to be a typo!
        name: `Test Planet Logo ${i}`,
        description: "This is a test",
        mintCap: MINT_CAP_ID,
        packageObjectId: PACKAGE_OBJECT_ID,
        warehouseId: WAREHOUSE_ID,
        moduleName: "slimezdevnettest",
        url: "ipfs://QmaH6pizJ6qHyjmAEneC1BVerVaawViiW8aJBbbyW7TUPs",
        attributes: {
          Image: "Planet",
          Text: "Red",
        },
      })
    );
  }
  const chunks = splitBy(
    txs.sort((a, b) => 0.5 - Math.random()),
    100
  );
  await Promise.all(chunks.map((chunk) => mintChunk(chunk)));
  //   const createMarketResult = await signer.executeMoveCall(transaction);
  // console.log('createMarketResult', JSON.stringify(createMarketResult));
};

mintNFt();

6. I encountered the following error:

/home/romeotango/sui-move/originbyte/js-sdk/node_modules/@mysten/sui.js/src/signers/txn-data-serializers/rpc-txn-data-serializer.ts:182
      throw new Error(
            ^
Error: Encountered error when calling RpcTxnDataSerialize for a moveCall transaction for address e42d4c5e5fa231009f5d2342461ab877599e5b70 for transaction {
  "kind": "moveCall",
  "data": {
    "packageObjectId": "0xf8be87a3546a1558ae81ab3ac7e37615433b8c55",
    "module": "slimezdevnettest",
    "function": "mint_nft",
    "typeArguments": [],
    "arguments": [
      "Test Planet Logo 72",
      "This is a test",
      "ipfs://QmaH6pizJ6qHyjmAEneC1BVerVaawViiW8aJBbbyW7TUPs",
      [
        "Image",
        "Text"
      ],
      [
        "Planet",
        "Red"
      ],
      "0xc468803dd47b518c1e90632bb2d7a7aa34e8e664",
      "0x3eb3968cd02a9ff3cd6225465de9fa23ad382bd1"
    ],
    "gasBudget": 10000
  }
}: Error: RPC Error: ExecutionError: ExecutionError { inner: ExecutionErrorInner { kind: InvalidChildObjectArgument(InvalidChildObjectArgument { child: 0x3eb3968cd02a9ff3cd6225465de9fa23ad382bd1, parent: 0x474be3d63ecd613cc42515671ced2d75ae462042 }), source: None } }
    at RpcTxnDataSerializer.<anonymous> (/home/romeotango/sui-move/originbyte/js-sdk/node_modules/@mysten/sui.js/src/signers/txn-data-serializers/rpc-txn-data-serializer.ts:182:13)
    at Generator.throw (<anonymous>)
    at rejected (/home/romeotango/sui-move/originbyte/js-sdk/node_modules/@mysten/sui.js/dist/index.js:73:29)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)

It seems that this has to do with the inventory and warehouse objects. In general, I found the relationships between the two very confusing and there isn't enough documentation explaining them. But from the transaction log above and Sui Explorer, it seems that my inventory object 0x474be3d63ecd613cc42515671ced2d75ae462042 owns a dynamic field that is the warehouse object 0x3eb3968cd02a9ff3cd6225465de9fa23ad382bd1. My guess is that there is some incompatibility between what's generated from Gutenberg and js-sdk regarding these two objects.

Understanding this is a very lengthy issue post already and I tried not to overload information further. If necessary I can provide more info or push my repos to help with replication and investigation. Really have 0 clue on how to even debug this issue so I appreciate your guidance.

Minting of NFTs to the Launchpad - Gas costs accrued by the Deployer

It is rather inefficient to make it so that the module publisher is the one to mint all the collection NFTs to the Launchpad, as the gas costs for a collection 1k, 5k, 10k, would simply be too expensive to be paid by one single entity.

In Solidity, the minting of an NFT is made by each address that wishes to do so and I do believe this should be the case in your NFT standard.

How do I know the object I retrieved is an NFT?

In Ethereum, I can use supportsInterface to check whether the contract follows the NFT standard.

How can I do that in sui?

Where does TagDomain live?

Considering using either `Bag` or associating NFTs with Safe as dynamic objects

    Should this still remain an `ObjectBag`? 

Something like a Table would be a bit simpler for the reasons we went with Bag for domains.

Originally posted by @Suficio in #48 (comment)

Launchpad support for loose NFTs

Invalid module access. Unbound function 'transfer_to_object' in module '(sui=0x2)::transfer'

https://github.com/Origin-Byte/nft-protocol/blob/main/sources/nft/nfts/unique_nft.move#L378

I have been faced error at this line, of course I am checking normal source, just tried to this command $sui move build

error message:
Invalid module access. Unbound function 'transfer_to_object' in module '(sui=0x2)::transfer'

$ sui move build
error[E03003]: unbound module member
┌─ ./sources/nft/nfts/unique_nft.move:378:9
│
378 │ transfer::transfer_to_object(
│ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Invalid module access. Unbound function 'transfer_to_object' in module '(sui=0x2)::transfer'

Failed to build Move modules: "Compilation error".

Sui version: $ sui --version
sui 0.13.2

Rustc version $ rustc --version
rustc 1.64.0 (a55dd71d5 2022-09-19)

Incorrect seller in TradeFilledEvent in the internal call `buy_nft_`

https://github.com/Origin-Byte/nft-protocol/blob/main/sources/trading/orderbook.move#L1353

The seller field should be taken from the owner from Ask

Implement DisplayDomain for NFT and Collection

Implement a set of domains following Suiet recommended metadata standards https://github.com/suiet/standard.

Intersection of Collection and NFT metadata standard gives us:

struct DisplayDomain {
  name: string,
  description: string,
}

struct UrlDomain {
  url: Url,
}

And for NFTs only:

struct CollectionDomain {
  collection_id: ID,
}

UrlDomain separate due to not all NFTs and Collections having Urls

What is MintAuthority

I would like to know for mint authority what should i put as argument for that?

 public entry fun mint_nft<T>(
        name: vector<u8>,
        description: vector<u8>,
        url: vector<u8>,
        attribute_keys: vector<vector<u8>>,
        attribute_values: vector<vector<u8>>,
        max_supply: u64,
        mint: &mut MintAuthority<SAIKHANT>,
        ctx: &mut TxContext,
    ) ```