@CantonForge Great question, let me share what i understood in the protocol level
On cross-validator usage
FeaturedAppRight is bound to a Party ID, and that party is tied to the participant (Validator A). Since choices like FeaturedAppRight_CreateActivityMarker require that party to exercise them, you won’t be able to use the FA from Validator B unless that same party is available there.
One thing you can explore is multi-hosting the party:
-
Add Validator B as a participant for the same Party ID via topology
-
That way you keep the FA and can operate from B
It’s doable, but comes with operational + governance overhead.
On migration
As far as I know, there’s no in-place update for FeaturedAppRight in the current DSO governance — it’s issued against a specific party and that binding is fixed.
What I’d do
If multi-hosting isn’t worth the complexity:
-
Revoke existing FA (Validator A)
-
Re-grant FA for the new Party ID on Validator B
Cleaner, and avoids weird topology edge cases later.
Also worth noting: with recent changes around activity markers (CIP-0104), some of the FA mechanics are shifting, so double-check if your flow depends on manual marker creation.
Curious if others have tried multi-hosting FA parties in production.