thirdweb-dev / contracts Goto Github PK

Hi there,

Following the tutorial for creating a marketplace and am trying to create a bid as described here: https://nftlabs.github.io/nftlabs-sdk-ts/sdk.marketplacemodule.createauctionlisting.html

// Data of the auction you want to create
const auction = {
  // address of the contract the asset you want to list is on
  assetContractAddress: "0x...",
  // token ID of the asset you want to list
  tokenId: "0",
  // in how many seconds with the listing open up
  startTimeInSeconds: 0,
  // how long the listing will be open for
  listingDurationInSeconds: 86400,
  // how many of the asset you want to list
  quantity: 1,
  // address of the currency contract that will be used to pay for the listing
  currencyContractAddress: "0x0000000000000000000000000000000000000000",
  // how much people would have to bid to instantly buy the asset
  buyoutPricePerToken: "10",
  // the minimum bid that will be accepted for the token
  reservePricePerToken: "1",
}

await module.createAuctionListing(auction);

I get that currencyContractAddress takes an ERC20 contract address to pay with. My question is can we add the feature to pay with raw ETH (and similarly on other coins as well). I can use wrapped ETH fine but it is annoying for users to pay gas to swap in order to buy.

Thank you for your consideration.

Write test helpers to test common smart contract vulnerabilities across all smart contracts. These tests go beyond basic hardhat tests that are currently under /test.

Example: guiding diagram to map out vulnerability testing:

It would be great to see @thirdweb-dev adopt ERC721A, an improved implementation of the IERC721 standard that supports minting multiple tokens for close to the cost of one.

The goal of ERC721A is to provide a fully compliant implementation of IERC721 with significant gas savings for minting multiple NFTs in a single transaction.

The Azuki team (created by @chiru-labs) created ERC721A for its sale on 1/12/22. There was significant demand for 8700 tokens made available to the public, and all were minted within minutes. The network BASEFEE remained low despite huge demand, resulting in low gas costs for minters, while minimizing network disruption for the wider ecosystem as well.

What's the easiest way to implement ERC721A into thirdweb?

Check out the nft-erc721-collection by @hashlips-lab

The LazyMintERC1155 contract improved upon the ERC721 contract for lazy minting (LazyNFT) in the following ways:

• Gas efficient pattern for lazy minting (no for loops for lazy minting multiple NFTs)
• Clearer usage of 'mint' and 'claim' (e.g. rename setPublicMintConditions -> setClaimConditions)
• Make external/public functions more readable by using internal functions, where each internal function has a defined, single task to perform. So, external/public functions read like pseudo-code. (see claim in LazyMintERC1155)

To-do :

• Re-write LazyNFT as LazyMintERC721 and make changes described above.
• Document the changes that break the interface of the contract so the SDK can be adjusted accordingly.

It would be nice to see when offers are made on marketplace auction listings. This increases transparency. I am willing to submit a Pull Request to add this new feature.

The changed Offer structure would look something like this:

struct Offer {
        uint256 listingId;
        address offeror;
        uint256 quantityWanted;
        address currency;
        uint256 pricePerToken;
        uint256 expirationTimestamp;
        uint256 createdAtTimestamp;
}

If you're required to transfer the $ into the contract for a bid, it seems like you're competing against yourself.
If i have 100 in my wallet, i bid 90 and that get transferred into the contract. The next bid that i make i can only make it up to 10.

Is there a way to pass custom metadata when minting using the NFT contracts? i.e. to accommodate music NFTs as specified in this proposal: https://www.notion.so/Music-NFT-Metadata-Proposal-98871dbe2d934890a36322c638b7b6cc

To fix: unnecessary require checks + the price of a direct listing cannot be edited.

Since miners set block.timestamp, the value of block.timestamp is unpredictable, and so, a user of the Marketplace may not be able to set precise start and end times for their listing.

A design doc for ERC 1155 lazy minting (similar to the existing LazyNFT) - explaining what the contract is, how it works and can be used, and why it is design the way it is.

We want to implement the same signature based we did for ERC721 for ERC1155

Remove timeouts from event tests and use the ethereum-waffle api instead.

Seeing examples of polygon drop collections not being recognized by OS for owning the collection (presearch)

Also seen by mainnet drop with Rarible and mintable (mars swimsuit competition)

We want to expand the Voting Contract to allow for participation via ERC721 or ERC1155 ownership alongside the ERC20 we currently do.

Hi when I run the 2-deploy-drop.js in Buildspace project Build your own DAO with just Javascript in a weekend. I get an error. Could anyone help ? Thanks

Below is the code and the error info.

`import { AddressZero } from "@ethersproject/constants";
import sdk from "./1-initialize-sdk.js";
import { readFileSync } from "fs";

(async () => {
try {
const editionDropAddress = await sdk.deployer.deployEditionDrop({
// The collection's name, ex. CryptoPunks
name: "shushuDAO Membership",
// A description for the collection.
description: "A DAO for fans of SHUSHU.",
// The image that will be held on our NFT! The fun part :).
image: readFileSync("scripts/assets/1.png"),
// We need to pass in the address of the person who will be receiving the proceeds from sales of nfts in the contract.
// We're planning on not charging people for the drop, so we'll pass in the 0x0 address
// you can set this to your own wallet address if you want to charge for the drop.
primary_sale_recipient: AddressZero,
});

// this initialization returns the address of our contract
// we use this to initialize the contract on the thirdweb sdk
const editionDrop = sdk.getEditionDrop(editionDropAddress);

// with this, we can get the metadata of our contract
const metadata = await editionDrop.metadata.get();

console.log(
  "✅ Successfully deployed editionDrop contract, address:",
  editionDropAddress,
);
console.log("✅ editionDrop metadata:", metadata);

} catch (error) {
console.log("failed to deploy editionDrop contract", error);
}
})();`

failed to deploy editionDrop contract FetchError: FETCH_FAILED: Failed to get upload token
at zt.getUploadToken (D:\tt\buildspace-dao-starter\node_modules@thirdweb-dev\sdk\dist\index.js:15:1748)
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at async zt.uploadBatchWithCid (D:\tt\buildspace-dao-starter\node_modules@thirdweb-dev\sdk\dist\index.js:15:3119)
at async zt.batchUploadProperties (D:\tt\buildspace-dao-starter\node_modules@thirdweb-dev\sdk\dist\index.js:15:2723)
at async zt.uploadMetadataBatch (D:\tt\buildspace-dao-starter\node_modules@thirdweb-dev\sdk\dist\index.js:15:2098)
at async zt.uploadMetadata (D:\tt\buildspace-dao-starter\node_modules@thirdweb-dev\sdk\dist\index.js:15:2002)
at async pa.deploy (D:\tt\buildspace-dao-starter\node_modules@thirdweb-dev\sdk\dist\index.js:15:249292)
at async Pn.deployBuiltInContract (D:\tt\buildspace-dao-starter\node_modules@thirdweb-dev\sdk\dist\index.js:15:252554)
at async Pn.deployEditionDrop (D:\tt\buildspace-dao-starter\node_modules@thirdweb-dev\sdk\dist\index.js:15:251978)
at async file:///D:/tt/buildspace-dao-starter/scripts/2-deploy-drop.js:7:32 {
innerError: undefined

A markdown document detailing what the v2 market contract is, and the rationale for why it's designed the way it is.

There are no bids in the case of a direct listing, so no funds related to direct listings are escrowed in the Marketplace. 

However, there is a possible vulnerability with 'offers to direct listings'. 



Problem
Say there are 2 listings: L_1 which accepts currency A and L_2 which accepts currency B. Both are selling 1 NFT, and have the same price per token.

The same buyer makes an offer of amount x to L_1 in currency A, and L_2 in currency B. This means the buyer has approved the Marketplace to transfer x currency A and x currency B.

If L_2 edits its 'currency accepted' to currency A, then the lister of L_2 can accept the buyer's offer on L_2, since the Marketplace has the buyer's approval to transfer x currency A from the buyer's offer to L_1. However, the buyer may not have intended to buy from L_2 with currency A. This is an issue. 



Solution — Store an offer's intended currency in the Offer struct, so a buyer makes an offer with an offer amount and a currency specified.

See the case described in (3), in this this discussion.

Bug

Two separate issues pointed out:

1. An auction creator can make a winning bid in the auction, but the auction cannot be closed for the auction creator as the wining bidder. In this snippet if _closeFor is both targetBid.tokenOwner and targetBid.offeror, then _closeAuctionForBidder never gets called.

2. We need a one-step, more gas efficient way to handle the case described above in (3).

• Change nextValidTimestampForClaim to timestampOfLastClaim
• Add separate setClaimConditions and updateClaimConditions (as in here)

https://discord.com/channels/922584461680443402/922627365107032104/926574674484277318

Hello,
I am reporting a bug on Close auction and execute sale if there's a buyout price and incoming offer amount is buyout price.

BUG

you are not collecting incoming bid

Expected

Collect incoming bid after _closeAuctionForBidder so that you have funds to pay the auction creator

I have included the ref below

How to reproduce:

• Create and auction with a buyoutPricePerToken > 0
• try to bid the auction from another address (user A) with a buyoutPricePerToken that >= to the buyoutPricePerToken price above
• now close the auction from user A who is the buyer, this works ✔️
• now try to close the auction with user B who is the auction creator, the tx reverts ❌
• Execution will revert coz there are no funds to to pay the auction creator
  sometime it reverts with just execution reverted or Error: VM Exception while processing transaction: reverted with reason string 'ERC20: burn amount exceeds balance

erc1155 with lazy minting. similar to Drop (ERC-721)
whitelisting based minting

Hello team,

• I'm trying to create + deploy an ERC-1155 contract to Rinkeby testnet following the guide from Buildspace.

• However, when I run my script "scripts/2-deploy-drop.js" I get the following error below.

• "failed to deploy editionDrop contract TypeeERROR: failed to execute 'append on 'FormDate': parameter 2 is not of type 'Blob'"
  

• This is a screenshot of the code within the script below:
  

• Any suggestions on how to resolve this error would be greatly appreciated, thanks.

https://opensea.io/BurnAddress (0x000000000000000000000000000000000000dead) is much more common to burn NFTs than https://opensea.io/NullAddress (0x0000000000000000000000000000000000000000)

We should support both.

runs github actions to run hardhat tests and security tests on every PR.

Implement Shoyu's IERC2981 royalty pattern. This pattern handles the case where the contract implementing the ERC 2981 interface implements royaltyInfo incorrectly.

hey
whats up

Example : https://github.com/nftlabs/nftlabs-protocols/tree/v2-market/test/v2/Market/offerAuctionListing

https://twitter.com/OpenZeppelin/status/1460333672389742594

The EIP-4907 standard makes it possible for tokens created with the ERC721 standard to be used in rental transactions. In this way, the owner and user of tokens can be separate wallets. For example, an NFT collection distributes ERC20 tokens to its users through passive staking, a user who does not yet have an NFT leases one and becomes the user of NFT. Thus, the user can earn ERC20 tokens.

This Ethereum improvement proposal helps with separating user and ownership. Although it is not a very common usage yet, it may be useful to have this option available for use among ready-to-use contracts.

The explanation of the relevant EIP is given in the link below:
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-4907.md

Re: v2/MarketWithAuction

To maintain a consistent interface throughout the contract, we’ll change the Offer struct code to use pricePerToken instead of totalOfferAmount, and implicitly calculate the ‘total offer amount’ as price per token offered * quantity of tokens wanted.

Hello ! im try to use Remix to deploy Marketplace smart contract but i get invalid tuple value from remix what im doing wrong?

params_ = { assetContract: '0x455136fb85bA2b6378B9Ad34750440B508194a95', tokenId: '5', startTime: 0, secondsUntilEndTime: 86400, quantityToList: 1, currencyToAccept: '0x0000000000000000000000000000000000000000', buyoutPricePerToken: '10', reservePricePerToken: '1', listingType: 2, }

remix error: transact to Marketplace.createListing errored: Error encoding arguments: Error: invalid tuple value (argument="tuple", value="{ assetContract: '0x455136fb85bA2b6378B9Ad34750440B508194a95', tokenId: '5', startTime: 0, secondsUntilEndTime: 86400, quantityToList: 1, currencyToAccept: '0x0000000000000000000000000000000000000000', buyoutPricePerToken: '10', reservePricePerToken: '1', listingType: 2, }", code=INVALID_ARGUMENT, version=abi/5.5.0)

When a drop contract has restrictedTransfer set to true, you can still transfer the tokens on open sea

Here's the related PR: https://github.com/nftlabs/console/pull/423

Here's a discord message with more info: https://discord.com/channels/922584461680443402/922627376330973265/92486322661

Hello team,
The listings method here: https://github.com/thirdweb-dev/contracts/blob/main/contracts/marketplace/Marketplace.sol#L88
works well for getting listing by listingId

However, it would be really helpful to also include get all listings function in the contract.

Support sales with native tokens (e.g. ETH on Ethereum mainnet) and test sales with native tokens.

Customer need : an end user must be able to mint an NFT without the thirdweb customer having to pay gas to mint or lazy mint the NFT beforehand.

To-do :

• Write a design doc documenting the high level strategy for writing the smart contract that enables the mentioned customer need.
• Write the interface for the mentioned smart contract.

Hi

i'm curious how to run the tests?
When I run npm run tests or yarn tests it seems to do something silently but at the end it states "0 passing":

❯ npm run test

> @thirdweb-dev/[email protected] test
> hardhat test

No need to generate any newer typings.
✅ Generated documentation for 120 contracts


  0 passing (0ms)

The marketplace contract is set up in a way that allows someone to buy their own NFT. Would it be better if from the get go no person was able to buy a listed NFT that they own?

An ERC20 version of the thirdweb 'Drop' module (i.e. /contracts/lazy_mint/), where a module admin can set claim conditions, and relevant ERC20 tokens can be claimed according to those claim conditions.