Add co-creator revenue split so teams can share creator fees automatically on every trade

[Chucks1093]

Summary

Many creators work in teams or with collaborators. Currently the entire creator fee goes to one address. A co-creator split lets the creator register a partner address and a split percentage at registration so the contract automatically divides the creator fee between them on every buy and sell — no manual sharing needed.

Scope

• Add optional co_creator: Option<CoCreatorConfig> to register_creator
  • CoCreatorConfig { address: Address, share_bps: u32 }
  • share_bps is the co-creator's share of the creator fee (e.g. 3000 = 30%)
  • share_bps must be between 1 and 9999 inclusive
• On every buy and sell, split the creator fee: share_bps portion to co-creator, remainder to creator fee recipient
• Add get_co_creator(creator_id) -> Option<CoCreatorConfig> view function
• Emit CoCreatorFeeEarned { creator_id, co_creator, amount, ledger } on each trade where a co-creator receives a fee
• Co-creator config is immutable after registration
• None means all creator fees go to the creator fee recipient as before

Acceptance Criteria

• Co-creator receives correct share of creator fee on buy and sell
• Remaining creator fee goes to the creator fee recipient
• Split sums to 100% of the creator fee with no leakage
• get_co_creator returns correct config
• CoCreatorFeeEarned event emitted on every qualifying trade
• Invalid share_bps (0 or 10000+) reverts at registration

ETA: 24 hours

---

Coordinate on Telegram

[shinzoxD]

Hi maintainers, I would like to take this issue if it is available.

I would add the optional CoCreatorConfig at creator registration, validate share_bps in the 1..=9999 range, preserve the existing None behavior, and split creator fees on both buy and sell without leakage. I would add the get_co_creator view, emit CoCreatorFeeEarned, and cover valid split math, invalid bps, immutable config, and no-co-creator backwards compatibility in tests.

I will wait for assignment or GrantFox confirmation before opening a PR.

[KodeSage]

Hi Maintainers, please assign this issue to me. I have experience implementing smart contract payment distribution, access control, and event-driven state management. My approach would be to extend register_creator with an optional immutable CoCreatorConfig, validating that share_bps is within the allowed range (1–9999). During every buy and sell, the creator fee will be deterministically split between the co-creator and the creator fee recipient according to the configured basis points, ensuring the full creator fee is distributed without any leakage.

I'll implement the get_co_creator(creator_id) view function, emit the required CoCreatorFeeEarned event whenever a co-creator receives a payout, and preserve the current behavior for creators without a co-creator configuration. I'll also add comprehensive tests covering valid and invalid registration, buy/sell fee distribution, correct fee accounting, immutable configuration, event emission, and all acceptance criteria.

ETA: 3 hours.

[nomsoscript]

Hi maintainers!
I’d love to help out with this issue. I’ve checked the current codebase/documentation and know exactly what needs to be updated to make this clearer. I will ensure everything aligns perfectly with your existing contribution guidelines.

[grantfox-oss]

🦊 GrantFox — @nomsoscript has been assigned to this issue as part of the Official Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #516)
2. Your PR will be reviewed by the accesslayerorg maintainers

Good luck! Track your progress on GrantFox.