Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

raribleIngestor #24

Merged
merged 15 commits into from
Aug 27, 2024
Merged

raribleIngestor #24

merged 15 commits into from
Aug 27, 2024

Conversation

s29papi
Copy link
Contributor

@s29papi s29papi commented Jul 5, 2024

Ingestor for Rarible

@s29papi
Copy link
Contributor Author

s29papi commented Jul 10, 2024

@chrismaddern Could you check this out

@chrismaddern
Copy link
Contributor

Thank you for this submission!! 🥳 🙏

We've gotten a little behind on reviewing these, but will be spending some time over the next 48 hours, so look out for some feedback soon! Thank you! 🙏

if (unitMintTokenAddress == '0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE' || unitMintTokenAddress == '0x4200000000000000000000000000000000000006') {
totalPriceWei = unitMintPrice;
} else {
totalPriceWei = await getRaribleMintPriceInEth(unitMintPrice, unitMintTokenAddress);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this common?

FWIW we don't currently support mints for mobile minting in non-native currencies (signer wallets have ETH on Ethereum network chains, and SOL on Solana)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could exclude non ether mints. I observed at the time of making this that there were a handful of non ether mints mostly in degen.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would be fine for now. Love the idea of supporting them in the future, but the Floor signing fleet doesn't know how to pay in Degen yet anyway 🤣

): Promise<string | undefined> => {
const apiKey = process.env.RARIBLE_API_KEY;
if (!apiKey) {
throw new Error('RARIBLE_API_KEY is not defined in the environment variables');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Deployment note -- requires RARIBLE_API_KEY to be set.

Confirming availability of this key.

unitMintTokenAddress: string,
): Promise<any> => {
const apiKey = process.env.OX_API_KEY;
if (!apiKey) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that we likely won't include a 0x key in the project

Is it guaranteed that the result of a conversion on 0x will yield an amount that will be accepted by the contract for the mint here?

This is cool and interesting, but as I mentioned above, likely wouldn't be supported by mobile minting today anyway.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(I'm assuming it would require sending that payment token with the mint?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sticking to only ether based mints, removes the need for an OX api key as this is used for conversion.

mintBuilder.setMintInstructions({
chainId,
contractAddress,
contractMethod: 'claim',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see this method in the ABI?

@chrismaddern
Copy link
Contributor

Thanks for taking the time to share this!

I tried it on a new BASE mint using:

yarn run dry-run rarible url https://rarible.com/collection/base/0x968ca01b5C32234F4d6Bfd44fF079BE14789bA10/drops

I got an RPC error output:
CleanShot 2024-07-16 at 15 50 31@2x

Any idea if I'm doing something wrong if there's an edge case in the ingestor?

(I added a Rarible API key to the environment on the test machine)

@s29papi
Copy link
Contributor Author

s29papi commented Jul 16, 2024

two different mints, two different contract methods:

mint you are testing: https://basescan.org/address/0x968ca01b5C32234F4d6Bfd44fF079BE14789bA10#readContract

mint type my test assumptions were based of: https://basescan.org/address/0xcc3725d7e946d512a6C439E716C7C5A41cCce182#readContract

The error originates from the contract method 'sharedMetadata' which is missing in the new mint type.

The way around this would be to get the metadata stored on ipfs, and to see if it works for both. It should.

@chrismaddern
Copy link
Contributor

Amazing, that sounds smart.

FYI — I've updated the main branch on floor/mobile-minting to add simulation to the test suite for Base.

If you:

  • Merge floor/mobile-minting main into your branch
  • Add SIMULATE_DURING_TESTS=true to your .env
  • Use the basicIngestorTests macro to your test suite (example here)

Then... running it should show you which created mints will actually execute onchain 🥳

One thing I noticed (beyond the fact it will only support Base, not Degen) is that the encoded parameters in the contractParams have been truncated to exponent form - e.g. 1e21, vs. a bigint string form "10000000000...". Unless the contract is explicitly expecting that, I expect that will fail.

Let me know if you'd like to land this, we're holding the bounty spot for this one if you do.

@s29papi
Copy link
Contributor Author

s29papi commented Jul 22, 2024

Hey @chrismaddern, Could the data type for the successUrls be changed from string[] ---> [{url: "wyz.com", block: "0x452395"}, ...]. or block be added to type MintContractOptions or it could be the key while still retaining passing various block.

Currently the simulations blocks is a mapping of chainId to BlockHeight this is not ideal for me as each contract or url has a period of time where minting is valid and after with simulating a transaction fails, and the issue in this case being the key (chainId).

Any change that includes adding the block to the successUrls or key for blocks, it would be feasible to pass various blocks while iterating:

const result = await simulateEVMTransactionWithAlchemy(mintInstructions, simulationBlocks[mintInstructions.chainId]);

@chrismaddern
Copy link
Contributor

Hi @s29papi if you're confident that this is an overlapping blockhash issue vs. a code generation issue then I can take a look at updating the format.

I was hoping that for now we'd be able to find a couple test URLs that were available in the same time window to begin, but it does seem likely we'd need to iterate on this eventually anyway, so.....

@s29papi
Copy link
Contributor Author

s29papi commented Jul 22, 2024

If the direction for now is just mints within the same mint period, it's not a problem I would adjust to that.

@s29papi
Copy link
Contributor Author

s29papi commented Jul 23, 2024

This should be up for review. Regarding the initial issue I raised, I provided an array of objects that include both block height and URL, along with an index that can be manually changed to test all mints with their respective block heights.

mintBuilder.setName(name).setDescription(description).setFeaturedImageUrl(imageURI);
mintBuilder.setMintOutputContract({ chainId: chainId, address: contractAddress });
mintBuilder.setCreator({
name: 'not available',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will show up in the UI which we don't want.

It does look like rarible.org don't include this in the public API with key, but rarible.com do provide it in their API which appears accessible

curl 'https://rarible.com/marketplace/api/v4/profiles/list' \
  -H 'accept: */*' \
  -H 'content-type: application/json' \
  --data-raw '["0xbab964a06fbd884b0ad0efccb86f5931248858cc"]'

This has the name and other details which would make this much better! 🙂

CleanShot 2024-07-23 at 09 57 21@2x

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey, thanks. Been in and out of their telegram chat and couldn't get this endpoint.

@chrismaddern
Copy link
Contributor

This should be up for review. Regarding the initial issue I raised, I provided an array of objects that include both block height and URL, along with an index that can be manually changed to test all mints with their respective block heights.

If there aren't matching mints that we can use in the same time window, I'll go update the tests and commit to main an update to allow specifying a <URL/Contract, Blockhash> pair

@s29papi
Copy link
Contributor Author

s29papi commented Jul 23, 2024

This should be up for review. Regarding the initial issue I raised, I provided an array of objects that include both block height and URL, along with an index that can be manually changed to test all mints with their respective block heights.

If there aren't matching mints that we can use in the same time window, I'll go update the tests and commit to main an update to allow specifying a <URL/Contract, Blockhash> pair

Alright, I would update my test file after you've made the changes.

@s29papi
Copy link
Contributor Author

s29papi commented Jul 26, 2024

@chrismaddern, Took timeout to dig more into this, oops! my apologies, I was able to Find two mints which share same range for active claims within a particular block height. Would two be enough ? Although I had tested 6 mints individually which all passed at with their respective block height.

@s29papi
Copy link
Contributor Author

s29papi commented Aug 12, 2024

Hey @chrismaddern I would like to know what's left to land this I have multiple tests passed, but this is still marked on final approach

@chrismaddern
Copy link
Contributor

Hi @s29papi sorry for the delay!

I was hoping to be able to give you a quick thumbsup, but it seems one of the tests is now not passing?

CleanShot 2024-08-27 at 06 51 06@2x

Can you get that passing and then we can get it merge.

A quick spotcheck with Rarible mint looks great!

yarn dry-run rarible url https://rarible.com/collection/base/0x7a2e753a20ad60a931643ce87aeadb8efbf1caa1/drops

If you can get the tests passing again today, we can get it merged today!

@s29papi
Copy link
Contributor Author

s29papi commented Aug 27, 2024

Hi @chrismaddern. This is fixed, and the tests pass.

Sorry for the oversight.

timestampClaimcondition

Fixed it.

Copy link
Contributor

@chrismaddern chrismaddern left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tests passing locally. Added RARIBLE_API_KEY to workflow and environment secrets

@chrismaddern
Copy link
Contributor

@s29papi merging and sending you an email for bounty claim!! 🥳

@chrismaddern
Copy link
Contributor

/review

Copy link

PR Reviewer Guide 🔍

⏱️ Estimated effort to review: 4 🔵🔵🔵🔵⚪
🧪 PR contains tests
🔒 Security concerns

API key exposure:
The Rarible API key is being used directly in the code in src/ingestors/rarible/offchain-metadata.ts. This could potentially lead to the exposure of sensitive information. It's recommended to use environment variables or a more secure method to handle API keys.

⚡ Key issues to review

Error Handling
The error handling in the createMintTemplateForUrl and createMintForContract methods could be improved. Consider adding more specific error types and handling them separately.

API Key Security
The Rarible API key is being used directly in the code. Consider using environment variables or a more secure method to handle API keys.

Error Handling
The error handling in the raribleContractMetadataGetter function could be improved. Consider adding more specific error types and handling them separately.

@chrismaddern chrismaddern merged commit 31d6265 into floornfts:main Aug 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants