A pull request to Movement's Aptos Core repository has fixed a significant bug in token royalty lookups that exposed two critical failure modes affecting NFT marketplaces and royalty distribution.
The bug existed in the `token::royalty` function, which falls back to a collection's royalty when a token carries none of its own. The original implementation re-derived the collection address using `collection::create_collection_address(creator, collection_name)`. However, since collection names are mutable via `collection::set_name`, renaming a collection breaks this derivation and causes lookups to fail.
This resulted in two observable problems: First, if no collection under that creator held the new name after a rename, the view function would abort with `EOBJECT_DOES_NOT_EXIST`, causing marketplace operations that call `tokenv2::royalty()` to fail completely and unrecoverably. Second, if the creator had registered another collection under the original name, the derivation would incorrectly point to that second collection, misdirecting royalty payouts even for collections without mutable royalty references.
The fix, detailed in PR #416, reads the `Object<Collection>` reference stored directly on the token at mint time rather than re-deriving it. This field is written once and remains unaffected by renames. Four regression tests were added covering token royalty fallbacks after rename, name collision scenarios, royalty behavior when absent, and precedence rules. All 87 tests in the full `aptos-token-objects` suite pass after the fix.