-
Notifications
You must be signed in to change notification settings - Fork 8
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
raribleIngestor #24
Conversation
@chrismaddern Could you check this out |
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! 🙏 |
src/ingestors/rarible/index.ts
Outdated
if (unitMintTokenAddress == '0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE' || unitMintTokenAddress == '0x4200000000000000000000000000000000000006') { | ||
totalPriceWei = unitMintPrice; | ||
} else { | ||
totalPriceWei = await getRaribleMintPriceInEth(unitMintPrice, unitMintTokenAddress); |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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'); |
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?)
There was a problem hiding this comment.
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.
src/ingestors/rarible/index.ts
Outdated
mintBuilder.setMintInstructions({ | ||
chainId, | ||
contractAddress, | ||
contractMethod: 'claim', |
There was a problem hiding this comment.
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?
Thanks for taking the time to share this! I tried it on a new BASE mint using:
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) |
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. |
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:
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. |
Hey @chrismaddern, Could the data type for the successUrls be changed from string[] ---> [{url: "wyz.com", block: "0x452395"}, ...]. or block be added to type 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:
|
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..... |
If the direction for now is just mints within the same mint period, it's not a problem I would adjust to that. |
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. |
src/ingestors/rarible/index.ts
Outdated
mintBuilder.setName(name).setDescription(description).setFeaturedImageUrl(imageURI); | ||
mintBuilder.setMintOutputContract({ chainId: chainId, address: contractAddress }); | ||
mintBuilder.setCreator({ | ||
name: 'not available', |
There was a problem hiding this comment.
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! 🙂
There was a problem hiding this comment.
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.
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. |
@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. |
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 |
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? Can you get that passing and then we can get it merge. A quick spotcheck with Rarible mint looks great!
If you can get the tests passing again today, we can get it merged today! |
Hi @chrismaddern. This is fixed, and the tests pass. Sorry for the oversight. Fixed it. |
There was a problem hiding this 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
@s29papi merging and sending you an email for bounty claim!! 🥳 |
/review |
PR Reviewer Guide 🔍
|
Ingestor for Rarible