Problem Statement / Feature Objective
Cross-contract calls in the current system use raw env.invoke_contract() without authentication checks, meaning any contract can call any other contract's entry points. This creates a security vulnerability where a compromised or malicious contract could invoke privileged operations (minting tokens, modifying tariffs). A cross-contract authentication framework must be built that implements a capability-based security model: each contract declares which other contracts are authorized to call each of its entry points, using a shared registry contract that issues and verifies capability tokens.
Technical Invariants & Bounds
- Capability token:
(issuer_contract: Address, target_contract: Address, entry_point: Symbol, expiration_ledger: u32, nonce: u64).
- Token issuance: the registry contract issues tokens signed by the issuer contract's Ed25519 key.
- Token verification: at the start of each entry point, call
auth.verify_capability(token) which checks (1) token not expired, (2) caller address matches token's issuer_contract, (3) token nonce not revoked.
- Token revocation: registry maintains a BitVec of revoked nonces per
(issuer_contract, target_contract) pair; revocation costs 100 gas.
- Migration path: existing entry points should add a
#[cfg(feature = "capability-auth")] guard that checks capability before execution; backward-compatible mode skips check for legacy callers.
- Performance target: token verification < 2000 gas.
Codebase Navigation Guide
contracts/auth-registry/src/lib.rs — new capability token registry contract.contracts/auth-registry/src/token.rs — capability token data structure and serialization.contracts/auth-registry/src/revocation.rs — nonce-based revocation BitVec.contracts/*/src/auth.rs — each contract adds capability verification macro/guard.
Problem Statement / Feature Objective
Cross-contract calls in the current system use raw
env.invoke_contract()without authentication checks, meaning any contract can call any other contract's entry points. This creates a security vulnerability where a compromised or malicious contract could invoke privileged operations (minting tokens, modifying tariffs). A cross-contract authentication framework must be built that implements a capability-based security model: each contract declares which other contracts are authorized to call each of its entry points, using a shared registry contract that issues and verifies capability tokens.Technical Invariants & Bounds
(issuer_contract: Address, target_contract: Address, entry_point: Symbol, expiration_ledger: u32, nonce: u64).auth.verify_capability(token)which checks (1) token not expired, (2) caller address matches token'sissuer_contract, (3) token nonce not revoked.(issuer_contract, target_contract)pair; revocation costs 100 gas.#[cfg(feature = "capability-auth")]guard that checks capability before execution; backward-compatible mode skips check for legacy callers.Codebase Navigation Guide
contracts/auth-registry/src/lib.rs— new capability token registry contract.contracts/auth-registry/src/token.rs— capability token data structure and serialization.contracts/auth-registry/src/revocation.rs— nonce-based revocation BitVec.contracts/*/src/auth.rs— each contract adds capability verification macro/guard.