ourzora / ocs-hackathon-24

Zora Onchain Summer Hackathon 24 Guide
7 stars 0 forks source link

Creating a token on an existing 1155 contract & IPFS json #12

Open vitorjaguat opened 6 days ago

vitorjaguat commented 6 days ago

Hello everyone,

I am one of the developers of The Anarchiving Game (https://anarchiving.thesphere.as/, repo https://github.com/vitorjaguat/anarchive ). We are currently working on implementing a /create path that will allow users to create their own tokens within an existing collection on Zora: 0xe5a192aaf911c35fb47de1342e768ef01c84fa09.

This feature would be incredibly valuable, especially since we rely on attribute names being consistent across all tokens for our data visualization graph to function correctly. We realized we should have a custom create, also because the inclusion of token attributes on Zora’s UI has been removed (although it’s still possible to add attributes on token’s Settings tab, pushing a metadata update on a second transaction).

While reading the Zora SDK documentation, we noticed that one of the properties on the options parameter required for the creatorClient.create1155({}) function is tokenMetadataURI, which should point to an IPFS hash or an HTTP-hosted JSON.

Our understanding is that we need to provide the IPFS address of a JSON file that is already uploaded to IPFS. Is this correct? We are currently stuck at this step and would greatly appreciate any advice on how to proceed. Should we sign up for a service like Infura or Pinata, or are there any other services or workflows you would recommend? Or even, could we use the same hosting that allows users to upload their media on Zora when creating new tokens at https://zora.co/create?

Thanks in advance for your assistance.

Best regards, Vitor

oveddan commented 6 days ago

similar issue to #11

oveddan commented 6 days ago

will provide sample instructions shortly

oveddan commented 3 days ago

ok we have some updated sdk helper methods and guides, check them out here: https://docs.zora.co/protocol-sdk/metadata/token-metadata

vitorjaguat commented 3 days ago

Thank you, @oveddan . In the meantime, we've already figured out this part of the process, but the improvements in the methods and guides will be very useful for the rest of the community.

As a suggestion, it would be helpful to have more details on constructing the creatorClient.create1155() options object. I noticed that some properties, such as maxSupply and mintToCreatorCount, are particularly useful for minting tokens to the creator's account immediately after creation in the same transaction.

We are almost ready to finalize our /create path, and soon our users will be able to use it. Thanks a lot!

oveddan commented 3 days ago

thx for the feedback on surfacing those parameters. will def look to adding that in. maybe we can follow the format of the vite docs where they explicitly lay out props/return types: https://viem.sh/docs/contract/writeContract

vitorjaguat commented 2 days ago

Thank you, @oveddan . Yes, this is a good way to explain how the sdk works, as this can make devs intuitively understand what each method or config property does.

One more question please. As I told you, we are trying to make a /create page in our webapp, and deliver more or less the same options for token creation as in zora.co/create page. I noticed that the option object that is passed to .create1155 has a type like this:

export interface CreateNew1155TokenProps {
  maxSupply?: bigint | number;
  tokenMetadataURI: string;
  royaltyBPS?: number;
  salesConfig?: SalesConfigParamsType;
  createReferral?: Address;
  mintToCreatorCount?: number;
  payoutRecipient?: Address;
}

and SalesConfigParamsType is...

export type SalesConfigParamsType = {
  // defaults to 0 
  pricePerToken?: bigint;
  // defaults to 0, in seconds
  saleStart?: bigint;
  // defaults to forever, in seconds
  saleEnd?: bigint;
  // max tokens that can be minted per address
  maxTokensPerAddress?: bigint;
  // if an erc20 mint, the erc20 address.  Leave null for eth mints
  currency?: Address;
}

I already figured out how to pass a price for token (salesConfig.pricePerToken property) and also how to automatically mint the first copy of the token after creation of token (mintToCreatorCount property). I already have set the split with 0xsplit sdk, working fine.

My question is about zora.co/create "Minting duration" option. I tried to set an option for the user to choose between, for example, FOREVER OPEN and 1 WEEK OPEN. For FOREVER OPEN, i passed saleStart: BigInt('0') and saleEnd: BigInt('604800') (which is one week in seconds).

My train of thought was that saleStart manages when the token will be available to mint (0 meaning that it is immediately mintable after creation), and that saleEnd manages when the token becames unavailable for mint. Is it right? I guess it is not, because the tokens with these values for one week duration didn't become available for mint. Here is a test made directly from anarchiving.thesphere.as/create : https://zora.co/collect/zora:0x8e038a4805d984162028f5978acd894fad310b56/39

When I passed BigInt('0') for both properties (SaleStart and SaleEnd), the token becomes immediately available for mint after creation. But I found no way to configure this option...

I hope you can help me with that. In case you need some more feedback with the SDK documentation, don't hesitate to tell me. Thanks a lot!

oveddan commented 1 day ago

hey @vitorjaguat thats a great question there are some nuanced differences between creating 1155 regularly vs premint - duration is an option only available when creating premints - in the mintDuration property. Premints have a mintStart (which is the earliest time the token can be brought onchain). Once the token is brought onchain, the mintDuration kicks off. For non-premint (standard onchain token creation) - the time parameters are mintStart and mintEnd