@Aboudjem the gap you describe, resolving an agent address to its authorized principal so that compliance checks pass on the right identity, is a real problem and well articulated.
We’ve been working on exactly this. ERC 8226 RAMS defines getActivePrincipal(agentId) which returns the verified principal behind any agent with an active mandate. When a regulated token sees an agent initiated transfer, it resolves the principal, runs its own investor eligibility check on that principal, the token’s compliance module is never bypassed, and then verifies the RAMS mandate validity. Two layers, deterministic resolution, no branching on the token side.
The difference from the 4 function approach you’re sketching is that for regulated assets, knowing who the principal is isn’t enough. You also need to know: is the mandate still valid? Has the financial cap been reached? Is the agent frozen by a regulator? Is the principal still eligible under the token’s own compliance framework? A bare principalOf resolves identity but does not answer any of these, and those are the questions that actually block transactions on permissioned tokens.
RAMS is agnostic to the agent identity system and the token compliance framework. It works with any agent registry, ERC 8004 being a natural fit, and any regulated token with a pre transfer hook, ERC 7943, ERC 3643. It is not vendor specific, it is an open ERC with an active discussion thread and PR on ethereum/ERCs.
@0xvimer the composition between ERC 8118 and RAMS maps cleanly: 8118 handles function level permissions, what can the agent do, RAMS handles compliance delegation, who authorized the agent, under what financial and jurisdictional constraints. Both layers pass then the agent executes. Either fails then revert.
Full spec and discussion: https://ethereum-magicians.org/t/regulated-agent-mandate-standard-rams/28208
GitHub PR: https://github.com/ethereum/ERCs/pull/1679