Gathering Feedback: Permissionless Revenue Tokens in Royalty Module

Proposals
1

There is a question under consideration:

Should the Royalty Module allow permissionless revenue tokens?

On one hand, this would allow projects to use the Royalty Module without having to sell the project native token to buy $IP token. This creates less sell pressure for ecosystem project’s native tokens.

On the technical side - it may be possible too - with a few thoughts to consider:

  1. We may want to use wrapped tokens instead of the original token to prevent tokens with malicious logic inside the protocol - this could be abstracted away from the user and protocols integrating by wrapping and unwrapping when project token enters or exits the PoC smart contracts.
  2. We may want to check in PoC where are there loops by revenue token address and make adjustment in those loops as they would get big and were originally thought for just a small amount of whitelisted tokens. For example:
  • Revenue debt updates on transfer: We may reconsider debt updates on transfer. It is too gas intensive to have too many revenue tokens’ debt being updated on a royalty token transfer. So perhaps only few tokens or none would be updated on transfer and for the other revenue tokens users must claim revenue tokens before transferring royalty tokens.
  1. PoC treasury would get filled a long tail of tokens unless there is a swap at the royalty payment moment itself. If PoC needs to swap the royalty fee: where to fetch the swap price? The long tail of project native tokens may not have oracles so what is the trustworthy price source in that case - would need further review.

This is shared with the intent of hearing the community’s feedback and thoughts about this feature.

Thank you in advance!

13 Likes
2

I understand that the intellectual property (IP) revenues will be generated externally and then distributed within the Story blockchain. Therefore, I assume that the asset flow—when using IP—would initially involve buying the token, followed by its distribution. It’s likely that investors might later exchange it back into their preferred currencies.

With this in mind, I believe that using IP would have a net positive effect on the token, as it would create initial buy pressure, and not all distributed tokens would necessarily be sold afterward.

While abstracting the token can improve user experience, I believe it could be detrimental to the token if the goal is to build an economy around it. An alternative could be for the project to issue its own stablecoin, or even reach an agreement with an existing stablecoin to help capture and retain value within the ecosystem

2 Likes
3

I think moving toward permissionless revenue tokens is a strong long-term goal aligned with Chainflow’s accessibility values, but we shouldn’t rush into it without considering the global legal implications this could have for Story. A phased approach, starting with a permissioned system to test economic behavior and legal exposure, paired with clear review timelines before transitioning to a fully permissionless system, could strike the right balance.

Wrapping tokens to protect the PoC from malicious logic makes sense, especially if the system is going to be more open. Abstracting that process away from users and integrations is the right approach, but only if we’re confident it won’t introduce new risks or clunky UX. It might be worth looking at standards like ERC-4626, not because it’s a 1:1 fit, but because it tackles a similar design challenge: safely wrapping external assets into a predictable interface that isolates logic and simplifies integration. That kind of model could help inform how PoC handles third-party revenue tokens.
Looking into ERC-4626 also raised the question of vaults versus wrappers. Initially, wrappers feel like the more straightforward and more intuitive solution, especially if we can abstract them away from the user. However, as we move closer to a fully permissionless system, vaults may offer a cleaner way to handle diverse token behavior safely and modularly. My main concern is the UX tradeoff, so wrappers seem like the right place to start, with vault logic possibly emerging as the protocol matures.

If PoC starts receiving project-native tokens that aren’t widely traded, the big question becomes how to value those tokens reliably. Swapping them at the moment of royalty payment might work, but without solid oracles, pricing gets tricky. It might make sense to establish some minimum liquidity or price discovery requirements before allowing a new token to be listed.

Also agree with @Jesus that the priority should be reinforcing the utility and value of $IP first.

Quick question, could you confirm that “revenue debt” refers to the accounting record of how much revenue is owed to a user, but hasn’t yet been claimed or withdrawn? Just want to make sure I’m interpreting that correctly.

Lastly, if PoC starts accepting a wider set of tokens, we’ll need to make sure the system doesn’t bog down. Updating revenue debt on every transfer could get expensive fast. I like the idea of limiting automatic updates to a smaller set of tokens and requiring manual claims for others, it feels like a smart tradeoff between flexibility and efficiency.

Just our 2 cents, excited to see where this idea goes!

1 Like