I am curious where the Royalty Registry data is sourced from and if it’s cached…
Here is an example token -
On the registry it says one thing but on etherscan, another
Contract address - 0xd90829c6c6012e4dde506bd95d7499a04b9a56de tokenID 48
Here is the transaction that is setting the royalties - 0x1cdd58a699e6670076527d9262df1126fe2a63cbc71095c811a7218cb2eb3793
It looks like you initialized the RoyaltyEngineV1 with the zero address…
https://etherscan.io/tx/0xce1ba0aaf101ddd1afbf4ebc106e4a467419c8ed950160ca66c30011483cf9bc
https://etherscan.io/address/0xD388d812c1cE2CE7C46D797684BA912De65CD414#readContract
Ah nevermind, I see the proxy pattern there.
That said - I wrote a unit test to take a deeper look here…
Looks like when the contract was deployed some sort of royalty splitter and royalty override was also deployed alongside it -
https://etherscan.io/tx/0x63a3a5dccce3bd655fa3ed7272e13301a0b7452327a6ece89a64580fb5dfdbf6
Ok I guess this all makes sense. The token contract was deployed with an override contract for royalties. So the source of truth is that override contract rather than the token contract.
@wilkins.eth sound about right?
Sounds about right. You could remove the override.
Will give it a shot. Just can’t remember the context. Must have been some marketplace was turning off royalties at the time.
Hey Wilkins,
We’re running into another issue… this is what it says in Studio -
Any idea what’s going on? I think something must just be out of sync here…
@wwhchung any ideas?
