Merge pull request #11 from CMTA/update-v3.3.0

Update v3.3.0

Author: rya-sge

README.md

@@ -2,16 +2,16 @@
 
 ## Introduction
 
-**This project turns a CMTAT security token into a token whose compliance rules live in swappable on-chain policies that Chainlink ACE evaluates on every operation.** It lets a token issuer change _who can do what, and under which conditions_ (KYC/allowlists, sanctions screening, transfer and volume limits, trading-hours windows, pause, reserve-backed minting) by reconfiguring policies, **without redeploying or changing the token's business logic**.
+This project integrates a **CMTAT** security token with **Chainlink ACE** so that the token's compliance rules are defined in on-chain policies, which the policy engine evaluates on each protected operation. An issuer can adjust who can transact and under which conditions (KYC/allowlists, sanctions screening, transfer and volume limits, trading-hours windows, pause, reserve-backed minting) by reconfiguring those policies, rather than redeploying or modifying the token's business logic.
 
 ### The problem it solves
 
-Regulated tokens (**security tokens, real-world assets (RWA), and stablecoins**) must enforce compliance rules (eligibility, limits, freezes, pauses) that **change over time** as regulation, jurisdictions, or counterparties evolve. Baking those rules into the token means a contract upgrade or redeploy for every change, which is slow and risky. This integration moves the rules out of the token and into a policy engine, so compliance becomes a **configuration** concern instead of a code concern.
+Regulated tokens (security tokens, real-world assets (RWA), and stablecoins) need to enforce compliance rules such as eligibility, limits, freezes, and pauses, and those rules change over time as regulation, jurisdictions, or counterparties evolve. When the rules are embedded in the token, each change requires a contract upgrade or redeploy. This integration keeps the rules in a separate policy engine, so updating compliance is a configuration change rather than a code change.
 
 ### The two building blocks
 
 - **CMTAT (CMTA Token)** — an open security-token framework from the [Capital Markets and Technology Association](https://www.cmta.ch/). It provides the ERC-20 token plus compliance modules: conditional transfers, account freeze / enforcement (ERC-7943), forced transfer & recovery, pause, in-contract documents, cross-chain mint/burn, and lifecycle controls.
-- **Chainlink ACE (Automated Compliance Engine)** — a `PolicyEngine` that, for a protected function call, runs a configurable chain of **policies** (small contracts that approve or reject based on the call's parameters) and returns a decision. Policies are added, removed, and reordered by governance at runtime.
+- **Chainlink ACE ([Automated Compliance Engine](https://chain.link/automated-compliance-engine))** — a `PolicyEngine` that, for a protected function call, runs a configurable chain of **policies** (small contracts that approve or reject based on the call's parameters) and returns a decision. Policies are added, removed, and reordered by governance at runtime.
 
 ### How it works
 
@@ -211,7 +211,7 @@ Guidance for issuers:
 - `TransferValidationPolicy` — Chainlink ACE policy that validates transfers using CMTAT's `IRule` interface (see [TransferValidationPolicy](#transfervalidationpolicy) below)
 - `ERC20TransferFromExtractor` — Extractor that produces 4 parameters (`spender`, `from`, `to`, `amount`) for `transfer()` and `transferFrom()`
 - `CrossChainMintBurnExtractor` — Extractor that maps `crosschainMint` / `crosschainBurn` into the `[from, to, amount]` layout so the same `IRule` rules can screen cross-chain issuance/redemption
-- `CCTVersionModule` — overrides CMTAT's `VersionModule` so the token's `version()` returns the CMTAT-ACE integration release (currently `0.2.0`) instead of the underlying CMTAT framework version
+- `CCTVersionModule` — overrides CMTAT's `VersionModule` so the token's `version()` returns the CMTAT-ACE integration release (currently `0.2.0`) instead of the underlying CMTAT framework version. The `version()` view follows the ERC-3643 and ERC-8303 (Contract Version) convention; see [`doc/ERCSpecification/erc-8303.md`](./doc/ERCSpecification/erc-8303.md)
 
 ## Compliance Policies
 

doc/ERCSpecification/erc-8303.md

@@ -0,0 +1,131 @@
+---
+eip: 8303
+title: Contract Version
+description: Interface for exposing a contract implementation version string
+author: Ryan Sauge (@rya-sge)
+discussions-to: https://ethereum-magicians.org/t/erc-8303-contract-version/28795
+status: Draft
+type: Standards Track
+category: ERC
+created: 2026-02-12
+---
+
+## Abstract
+
+This ERC defines a minimal interface to expose a contract version string through a standardized `version()` view function. The design is based on the version pattern used by [ERC-3643](./eip-3643.md), while remaining token-agnostic and applicable to other smart contract domains, including DeFi applications such as lending protocols.
+
+## Motivation
+
+Integrators frequently need a simple, on-chain way to identify which contract implementation they interact with. A standardized version function improves:
+
+- integration safety (feature gating by version),
+- operations (faster incident triage),
+- governance and migration tracking (upgrade visibility),
+- ecosystem tooling interoperability.
+
+It is also useful for end-users, developers, and security auditors to identify which version of a codebase is currently used by a deployed contract.
+
+The same requirement appears in permissioned token systems ([ERC-3643](./eip-3643.md)) and in DeFi systems where contracts evolve over time.
+
+## Specification
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119) and [RFC 8174](https://www.rfc-editor.org/rfc/rfc8174).
+
+### Interface
+
+```solidity
+interface IERC8303 {
+    /// @notice Returns the implementation version string.
+    /// @return The version value (for example "1.0.0").
+    function version() external view returns (string memory);
+}
+```
+
+### Required Behavior
+
+1. **Version read**
+   - `version()` MUST be a view function.
+   - `version()` MUST NOT revert under normal operation.
+   - `version()` MUST return a non-empty string.
+
+2. **Version meaning**
+   - Returned values SHOULD be stable and machine-comparable by off-chain tooling.
+   - Returned values SHOULD follow a Semantic Versioning 2.0.0-like format: `MAJOR.MINOR.PATCH` using decimal integers (for example `1.0.0`, `3.2.1`).
+   - The canonical recommended pattern is `^[0-9]+\.[0-9]+\.[0-9]+$`.
+   - Implementations MAY define their own versioning policy, but SHOULD document it publicly.
+
+3. **Deployment model compatibility**
+   - This interface is compatible with immutable deployments and proxy-based upgradeable deployments.
+   - In upgradeable systems, `version()` SHOULD reflect the active implementation seen by users and integrators.
+
+### [ERC-165](./eip-165.md)
+
+Implementations SHOULD support [ERC-165](./eip-165.md) interface discovery for this interface.
+
+If an implementation supports [ERC-165](./eip-165.md), `supportsInterface(type(IERC8303).interfaceId)` MUST return `true`.
+
+- The interface id for `IERC8303` is `0x54fd4d50`.
+
+### Compatibility Note for ERC-3643 Integrations
+
+Integrators MAY treat legacy ERC-3643 token contracts exposing a compatible `version()` function as implementing this ERC even if they do not advertise ERC-165 support.
+
+## Rationale
+
+- **Minimal scope**: A single function maximizes adoption and keeps gas/runtime complexity negligible.
+- **ERC-3643 alignment**: Reuses a proven pattern already used in regulated token implementations.
+- **Token-agnostic design**: The interface applies to token contracts and non-token contracts alike.
+- **Optional ERC-165**: ERC-165 support is recommended but not required, lowering the adoption barrier for contracts that do not implement interface discovery. When ERC-165 is supported, advertising this interface is mandatory to ensure consistent detection by integrators.
+- **`string` over `bytes32`**: A human-readable string is preferred to a fixed-size bytes32 for legibility in explorers and tooling, at the cost of marginally higher gas for the return value.
+
+## Backwards Compatibility
+
+This ERC is fully additive. Contracts already exposing `version()` are naturally compatible if they match the interface signature.
+
+## Test Cases
+
+The following test cases apply to any conforming implementation.
+
+1. `version()` MUST NOT revert.
+2. `version()` MUST return a non-empty string.
+3. `version()` MUST return the version string declared by the implementation (e.g. `"1.0.0"`).
+4. If the contract supports [ERC-165](./eip-165.md), `supportsInterface(0x54fd4d50)` MUST return `true`.
+5. If the contract supports [ERC-165](./eip-165.md), `supportsInterface(0xffffffff)` MUST return `false`.
+
+## Reference Implementation
+
+Reference implementations are provided in the assets folder: the [interface](../assets/erc-8303/src/IERC8303.sol) and a [base implementation](../assets/erc-8303/src/ERC8303.sol), along with usage examples for [ERC-20](../assets/erc-8303/src/examples/ERC20VersionedExample.sol) and [ERC-721](../assets/erc-8303/src/examples/ERC721VersionedExample.sol) tokens. These examples are provided for educational purposes only and are not audited.
+
+```solidity
+// SPDX-License-Identifier: CC0-1.0
+pragma solidity ^0.8.0;
+
+import "./IERC8303.sol";
+import "@openzeppelin/contracts/utils/introspection/ERC165.sol";
+
+contract ERC8303Example is IERC8303, ERC165 {
+    function version() external pure override returns (string memory) {
+        return "1.0.0";
+    }
+
+    function supportsInterface(bytes4 interfaceId)
+        public
+        view
+        override
+        returns (bool)
+    {
+        return interfaceId == type(IERC8303).interfaceId
+            || super.supportsInterface(interfaceId);
+    }
+}
+```
+
+## Security Considerations
+
+- `version()` is metadata and must not be used as a sole authorization primitive.
+- In upgradeable systems, governance controls remain the trust anchor; version reporting does not prevent malicious upgrades.
+- Integrators should combine version checks with other trust signals (governance model, audits, deployment provenance).
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).