Inquiry Regarding the Migration and Cross-Validator Usage of a Featured App Right Party ID

Hi everyone,

We have encountered a situation regarding the management of a Featured App Right (FA) in our project, Tiva, and we are looking for some guidance from the community.

We recently had our proposal for the “Tiva” Featured App Right approved by the DSO. During the initial proposal, the FA was granted to a specific Party ID that is hosted on Validator A. Due to recent architectural changes, we haven’t utilized this FA yet, but our plan now is to operate the core business of Tiva out of a different validator, Validator B.

[Core Questions]

1. Cross-Validator Usage: Is it possible to retain the FA with its originally granted Party ID (hosted on Validator A), but somehow utilize its benefits (e.g., fee mechanisms, traffic purchasing, activity markers) for business logic and parties hosted on Validator B?

2. FA Party ID Migration/Update: If cross-validator usage is not feasible or goes against best practices, does the current Splice DSO governance framework support updating or migrating the Party ID associated with an already granted Featured App Right? Essentially, changing the beneficiary party from one on Validator A to one on Validator B.

[Alternatives] If neither of the above is currently supported by the protocol, does this mean our only path forward is to propose a RevokeFeaturedAppRight for the current FA, and subsequently submit a completely new GrantFeaturedAppRight proposal using the new Party ID from Validator B?

Any insights or recommended best practices would be greatly appreciated.

Thank you!

@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:

1. Revoke existing FA (Validator A)

2. 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.

Thanks a lot