Identity and Access Control
Identity and access control determine who may hold, transfer, or interact with a tokenised asset. In decentralized RWA tokenisation, this must be enforced without turning the protocol into an identity registry or custodial gatekeeper.
The model used here focuses on eligibility, roles, and permissions, not personal identity.
Identity vs Eligibility
A key distinction is separating who someone is from what they are allowed to do.
Identity
A real-world person or entity
Not required
Eligibility
Permission to interact with an asset
Required
Role
Scope of allowed actions
Explicit
Access
Enforcement of rules
Deterministic
The protocol enforces eligibility, not identity.
Credential-Based Access Model
Access control is based on credentials, not accounts.
Credentials may represent:
investor class (e.g. accredited, institutional)
jurisdictional eligibility
role (issuer, custodian, investor)
compliance status
Credentials are:
issued off-chain
verified on-chain
scoped to specific assets
They can be revoked or updated without rewriting token logic.
Access Control Flow
At a high level, access control is evaluated at the moment of interaction.
No background permissions exist. Every action is checked explicitly.
Roles and Permissions
The protocol distinguishes between roles to avoid authority overlap.
Investor
Hold, transfer, redeem
Issuer
Initiate issuance events
Custodian
Provide attestations
Operator
Trigger lifecycle updates
Governance
Modify rule sets
Roles are asset-specific, not global. Holding a role for one asset does not imply authority over another.
Transfer Eligibility Enforcement
Transfers are gated by eligibility checks on both sides.
Formally:
Transfer Allowed=Esender∧Erecipient∧Rasset\text{Transfer Allowed} = E_{sender} \land E_{recipient} \land R_{asset}Transfer Allowed=Esender∧Erecipient∧Rasset
Where:
EEE = eligibility status
RRR = asset-level rules
If any condition fails, the transfer does not execute.
Privacy-Preserving Verification
In many cases, it is sufficient to prove eligibility without revealing identity.
The system supports:
boolean eligibility proofs
credential hashes
zero-knowledge proofs (where applicable)
This allows statements like:
“This wallet is eligible to hold this asset”
without disclosing:
name
jurisdiction
financial details
Credential Scope and Lifetime
Credentials are not permanent.
They may be:
time-bound
usage-bound
asset-specific
Expiry
Prevent stale eligibility
Scope
Limit cross-asset reuse
Revocation
Respond to changes
Expired or revoked credentials immediately invalidate access.
Handling Eligibility Changes
Eligibility can change due to:
regulatory updates
investor status changes
compliance events
When eligibility changes:
new transfers may be blocked
existing holdings remain recorded
escalation or redemption paths apply
The protocol avoids forced erasure or silent reclassification.
No Central Identity Registry
The protocol does not:
store personal data
maintain user profiles
link wallets to identities
Identity providers, credential issuers, and legal verification remain external and replaceable.
This reduces:
privacy risk
regulatory surface area
systemic lock-in
Auditability and Transparency
While identity is not stored, access decisions are auditable.
Observers can verify:
which rules applied
whether a transfer passed or failed
when rule sets changed
This enables regulatory review without exposing user data.
Why This Model Matters
Traditional RWA platforms often:
centralize identity management
require accounts and approvals
mix custody with access control
This model avoids those pitfalls by:
enforcing rules, not identities
keeping access explicit and scoped
preserving privacy while remaining enforceable
Access control becomes deterministic infrastructure, not discretionary policy.
Identity and Access Control Summary
Identity storage
None
Eligibility
Credential-based
Enforcement
On-chain, deterministic
Privacy
Preserved
Authority overlap
Prevented
Last updated