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.
