feat(auth): Implement Role-Based Access Control (RBAC) for Protocol Administration

[grantfox-oss]

Context and Motivation

Currently, the TradeFlow-Core administrative functions likely rely on a simple single-administrator/owner pattern. However, for an institutional-grade RWA (Real World Asset) and factoring protocol, relying on a single key represents a critical single point of failure and a significant security risk. We need to implement a decentralized, Role-Based Access Control (RBAC) system.

Different operational roles—such as upgrading contracts, altering fee structures, whitelisting KYC'd addresses, and triggering emergency pauses—must be separated and assignable to different multi-sig wallets or administrative entities.

Technical Specification

The contributor must design an RBAC module in Rust for the Soroban smart contracts.

1. Define Roles: Implement a robust way to identify roles (e.g., using BytesN<32> hashes for roles like DEFAULT_ADMIN_ROLE, FEE_MANAGER_ROLE, PAUSER_ROLE, KYC_MANAGER_ROLE).
2. Storage: Utilize Soroban's Instance storage to map (Address, Role) => bool.
3. Modifiers/Auth: Create reusable authorization logic (fn require_role(env: &Env, role: BytesN<32>, account: Address)) that calls account.require_auth().
4. Admin Functions: Implement external functions to grant_role, revoke_role, and renounce_role. Only accounts holding the DEFAULT_ADMIN_ROLE should be able to grant or revoke other roles.

Acceptance Criteria

• RBAC logic is encapsulated in a reusable module or trait.
• Critical state-mutating functions (like fee adjustment or pausing) are protected by specific role checks rather than a global admin check.
• Comprehensive unit tests in src/test.rs demonstrating role granting, revoking, and unauthorized access rejections.
• Storage lifecycle (extend_ttl) is properly managed for role mappings.

[Ebenezer199914]

can i work on this issue

[Rocket1960]

Single-admin patterns are a liability that institutional clients will flag immediately during due diligence, so this is the right upgrade to prioritize. I have experience designing RBAC systems for on-chain protocols where operational roles — upgrades, fee changes, KYC whitelisting, emergency pauses — carry meaningfully different risk profiles and need to be held by different keyholders or multi-sigs accordingly. I can model the role hierarchy cleanly, ensure role assignment and revocation are themselves gated behind appropriate authority, and make sure the emergency pause path is fast enough to be useful in a crisis without being so permissive it becomes an attack surface. The goal is a system that satisfies an institutional security review, not just one that technically avoids a single private key.

[senmalong]

Hello Maintainer,

Please I’d love to take this issue on. I’m a smart contract and full-stack developer with experience across OnlyDust, Drips Waves

My stack includes Rust, Soroban, Cairo, Solidity, and TypeScript. I can deliver a clean, tested, and well-documented solution within 24 hours of assignment.

Happy to start immediately. Thank yOU

[grantfox-oss]

🦊 GrantFox — @Rocket1960 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 #170)
2. Your PR will be reviewed by the BETAIL-BOYS maintainers

Good luck! Track your progress on GrantFox.