Open Issues
This page is the OIP open issues registry for v0.5. It records what OIP v0.5 deliberately does not resolve. Each item is identified, classified, and tied to a downstream resolution path. The page is published as part of the official specification because the explicit listing of what remains open is part of the specification itself.
Implementers use this page to understand which surfaces of v0.5 may shift before v1.0 and to plan integration accordingly. The list also serves as the queue for v0.6 and subsequent versions.
What the items in this page are not: they are not bugs, ambiguities, or known specification errors. Issues of that kind are corrected through Changelog entries against the version in which they appear. The items here are structural: v0.5 fixes the framing, but the concrete formalization is intentionally scheduled for a later stage.
Classification
Every item on this page falls into one of three classes.
- Deferred: v0.5 intentionally does not address the item; resolution is scheduled for a specific later phase. The item is not under active definition during v0.5.
- Pending Definition: v0.5 establishes the skeleton (types, abstract interfaces, framing language), but the concrete formalization (exact signatures, parameter values, threshold conditions) is left to a downstream specification or implementation phase.
- Future Research: The item depends on external standards, ongoing research, or empirical evidence not yet available. The resolution timeline is conditional on external progress.
Items are organized below by topical area. Within each area, the order reflects relative priority and dependency where applicable.
Canton Driver Integration
Multi-Signatory Authority Field
Classification: Pending Definition
v0.5 assumes a single Signatory when populating the authority field on a STATE_SYNC message originating from Canton. DAML contracts can have multiple Signatories, and the specification does not yet fix how the authority field is populated when several Signatories are jointly authoritative.
Open questions cover three cases: (1) how to represent the authority field when all Signatories are jointly the message originator, (2) how priority is established among Signatories when one must be selected as the authority’s representative, and (3) how partial-consent cases are handled when only some Signatories have signed.
Interim handling: v0.5 supports only the single-Signatory case explicitly. Multi-Signatory cases can be worked around by having the Canton Driver select the highest-authority Signatory and include that selection in the attestation.
Resolution timeline: Phase 2 Canton Driver interface definition (Mock Canton simulator stage). Production formalization at Phase 5 with the live Canton integration.
Canton Driver Key Rotation and Bootstrap
Classification: Future Research
v0.5 registers Canton Drivers through the D-quencer governance whitelist. A Driver’s signing key is fixed at registration time, with no specified rotation procedure.
Open questions: routine and incident-response key rotation procedures, bootstrap procedure for new Driver instances entering operation, immediate revocation mechanism for compromised Drivers, and handling of in-flight messages during rotation.
Interim handling: Driver key rotation can be performed in v0.5 as a two-step GOVERNANCE sequence: revoke the existing Driver, then register a new one. The procedure is operationally heavy and does not specify in-flight message treatment.
Resolution timeline: Phase 4–5, formalized alongside the Driver slashing mechanism.
Party–OCID Mapping Invalidation
Classification: Pending Definition
v0.5 defines Party-to-OCID mapping changes through GOVERNANCE messages, but the procedure for declaring an existing mapping invalid (death, merger, identity change) is not specified.
Open questions: invalidation procedure for the various triggering events, post-invalidation OCID re-mapping for affected assets, and treatment of pre-invalidation asset state and transaction history.
Resolution timeline: Phase 3, alongside the RWA Registry deployment.
RWA Registry Interface
RWA Registry Solidity Signatures
Classification: Deferred
v0.5 defines the abstract skeleton of the RWA Registry event interface (in ERC-TRUST–independent abstract form) but does not fix the concrete Solidity event signatures or function signatures.
Skeleton fixed in v0.5: the event interface (“RWA state change events with cross-domain effects” in ERC-TRUST–independent form), the OIPDispatchCall interface for state-change dispatch from OSS to RWA Registry, and the four self-defense verification obligations on the RWA Registry side.
Open questions: precise Solidity event signatures (indexed topics, event data layout), function signatures, ABI encoding for OIP context, and the precise matching rules between event emission and OSS subscription.
Resolution timeline: Phase 3 RWA Registry contract deployment. May appear as an appendix during the v0.5 → v0.6 transition.
ERC-TRUST Integration Interface
Classification: Future Research
By the ERC-TRUST self-containment principle, v0.5 does not assume any ERC-TRUST interface or implementation. The RWA Registry skeleton is defined in ERC-TRUST–independent form.
Open questions: the integration interface between OIP and ERC-TRUST once ERC-TRUST progresses, the IComplianceModule interface for external compliance modules, and the mapping between ERC-TRUST’s six regulatory actions and OIP’s RegulatoryActionType values (the names match, but the signatures may differ).
Resolution timeline: Tracks ERC-TRUST specification work. Dependent on the EIP standardization schedule.
Asset Model
Inter-Asset Dependency Race Conditions
Classification: Deferred
v0.5 specifies asset-level locking only. Dependencies between assets (synthetic assets depending on underlying assets, derivatives depending on underliers) are not addressed at the OIP level.
Open questions: representation of how a state change on asset B affects asset A when the two are in a dependency relationship, atomic processing of transactions that modify multiple assets simultaneously (v0.5 only avoids deadlock through asset-id-ordered locking), and cycle detection in the dependency graph.
Interim handling: v0.5 implementations handle inter-asset dependencies at the application layer. The OIP message layer assumes a single-asset model.
Resolution timeline: Post-Phase 5. Asset model extension to be evaluated during OracleMint integration.
Token Standard Extensions (BOND, DERIVATIVE)
Classification: Future Research
The AssetType enumeration includes BOND, STOCK, DERIVATIVE, and others, but per-type metadata schemas are not defined.
Open questions: standard metadata for bonds (maturity, coupon, issuer credit rating), derivatives (underlier, strike, expiry, option type), and per-type validation rules (such as auto-LIQUIDATE on bond maturity).
Resolution timeline: Phase 5 OracleMint integration. Per-asset-type metadata standards may proceed in parallel with ERC-TRUST.
Restricted DSL Extensions
Classification: Future Research
v0.5 admits only a narrow set of operators in Restricted DSL: comparison operators (==, !=, <, >, <=, >=), logical operators (AND, OR, NOT), variable references (assetState.field, currentTime, actionState.field), and literal values. Arbitrary function calls, external queries, and loops are not part of v0.5; this is deliberate, to keep evaluation deterministic and Turing-incomplete.
Open questions: which extensions warrant inclusion (limited mathematical functions, hash functions, predefined oracle queries, bounded iteration over fixed-size lists), how to preserve cross-node determinism with extended operators, gas/cost models for evaluating extended expressions, and the boundary between conditions safe for protocol-level evaluation versus those that should be relegated to application-layer logic.
Interim handling: Conditions requiring extensions beyond the v0.5 operator set are expressed at the application layer rather than in conditionExpression, autoUnfreezeCondition, or scheduled-action conditions. Application-layer evaluation does not benefit from the cross-node determinism guarantees provided by Restricted DSL.
Resolution timeline: v0.6 or later. The extension is independent of the v0.6 wire-format work and may be addressed separately.
Operational Mechanisms
Message Size Limits and Fragmentation
Classification: Deferred
v0.5 does not specify wire-level message size limits. Under JSON serialization, a STATE_SYNC message representing a large asset portfolio can grow without bound.
Open questions: maximum message size, fragmentation protocol for messages that exceed the limit, and reassembly rules with idempotency guarantees on fragmented delivery.
Resolution timeline: Decided at the v0.6 wire-format refinement, where fragmentation can be addressed at the byte-format layer.
Network Propagation Mechanism
Classification: Deferred
v0.5 does not specify the inter-node propagation mechanism (gossip vs direct, transport choice). Once routing has decided where a message should go, the actual transport is implementation-defined.
Resolution timeline: Protocol extension work in a later research cycle. GossipSub-based design is the current direction.
Dynamic Routing Table Updates
Classification: Deferred
v0.5 defines routing table updates only through explicit GOVERNANCE messages. Automatic mechanisms are scheduled for later.
Open questions: automatic node discovery (mDNS, Kademlia DHT), gossip-based routing table propagation, and automatic isolation of failed nodes.
Resolution timeline: Phase 6 Mainnet Beta. The limits of explicit governance procedures are expected to surface as node count crosses 100, at which point dynamic mechanisms become necessary.
CRITICAL Priority Authority System
Classification: Pending Definition
v0.5 establishes the skeleton: a four-level Authority Hierarchy with scope restrictions and a five-step verification procedure. The exact authority registration procedure, verification key management, and operational anomaly detection thresholds are scheduled for separate formalization.
Open questions: precise contract interface for the Authority Registry, governance vote thresholds for authority registration, suspension and revocation procedures, anomaly detection thresholds for unusual CRITICAL grant frequency, alert routing for anomaly events, and any delegation or proxy relationships between authorities.
Resolution timeline: Phase 4 D-quencer integration. Formalized alongside staking and governance contracts.
Phase Timeout Governance Adjustment
Classification: Pending Definition
v0.5 specifies recommended phase timeouts for cross-chain coordination: prepareTimeoutMs = 5000, commitTimeoutMs = 10000, finalizeTimeoutMs = 5000. These values are operational parameters that may need adjustment as network conditions, target chain finality times, or message volumes change. The procedure for adjusting them through governance is not formalized in v0.5.
Open questions: which GOVERNANCE sub-type carries phase-timeout updates, whether timeout values are global or per-target-chain, the activation policy (immediate vs scheduled epoch boundary), and the rollback procedure if an adjusted value produces operational problems.
Interim handling: v0.5 implementations use the recommended values as defaults. Operators that need to adjust them coordinate the change off-protocol and apply it through node configuration.
Resolution timeline: Phase 4 D-quencer integration. Formalized as a new GOVERNANCE sub-type or as part of a broader operational-parameter governance layer.
DLQ Alert Threshold Governance
Classification: Pending Definition
v0.5 defines DLQ alerting parameters (alertThreshold for routine alerts and criticalThreshold for immediate escalation) as governance parameters that cannot be adjusted unilaterally by an operator. The reasoning is that a tampered threshold could mask systemic delivery failures. The governance procedure for adjusting these thresholds is not formalized in v0.5.
Open questions: the GOVERNANCE sub-type carrying threshold adjustments, the granularity (per-network global vs per-implementation), the vote threshold for adjustment, and audit retention of threshold changes.
Interim handling: v0.5 implementations apply default thresholds and document any operator-side overrides. The Conformance page treats the thresholds as governance parameters; deviations are recorded for post-Phase 4 reconciliation.
Resolution timeline: Phase 4 D-quencer integration. Likely consolidated with Phase Timeout Governance Adjustment under a single operational-parameter governance mechanism.
RWA Registry – Authority Registry Integration
Classification: Pending Definition
The second of the four RWA Registry self-defense obligations (authority verification) does not have its concrete implementation fixed. The specification recommends one of the three options below; the formalization is downstream work.
| Option | Behavior | Trade-off |
|---|---|---|
| (a) RWA Registry holds a local copy | RWA Registry mirrors Authority Registry contents and queries locally | Lower gas cost per call, faster reads; synchronization overhead and copy-staleness risk |
| (b) External Authority Registry call | RWA Registry calls a separate Authority Registry contract for each verification | Single source of truth; per-call gas cost, external contract dependency |
| (c) Verification proof in OIP context (recommended) | OSS attaches authority verification proof to OIPDispatchCall; RWA Registry verifies the proof rather than the registry |
Gas-efficient and consistent with self-defense; requires formalization of proof format and OSS-side verification responsibility |
Open questions on option (c) (the recommended path): the precise proof format (signature vs Merkle proof), the data-sharing model between OSS and RWA Registry for Authority Registry contents, the handling of stale verification proofs after Authority Registry updates, and authority verification on the Force Inclusion path where the OIP context is absent.
Resolution timeline: Phase 3 RWA Registry contract deployment. Formalized in conjunction with the CRITICAL priority authority system and the RWA Registry Solidity signatures.
Cross-chain Reconciliation Procedure Detail
Classification: Pending Definition
v0.5 specifies that DIVERGED coherence triggers a Reconciliation flow that forces every participating chain back to the primaryFinalityRecord‘s state. The mechanism by which Reconciliation issues system-level STATE_SYNC messages, the conditions under which the asset returns to SYNCED, and the failure handling if Reconciliation itself diverges, are specified at an abstract level.
Open questions: the precise message format Reconciliation uses (system-issued STATE_SYNC with a special authority claim, or a dedicated message subtype), the convergence criterion (every chain matches the primary record vs majority match with operator approval), the timeout for Reconciliation completion, and the escalation path if Reconciliation fails repeatedly (governance escalation, asset isolation, manual intervention).
Interim handling: v0.5 implementations treat Reconciliation as a privileged internal operation triggered by the OSS coordinator. The exact message format and convergence rules follow the implementation’s State Management module.
Resolution timeline: Phase 5 Public Testnet operational experience. Formalized as part of the cross-chain operational specification update.
Long-Term Storage Strategy for Primary Finality
Classification: Future Research, Operational
The pending sync queue invariants require long-term preservation of the primary finality record. The specification permits compression, archiving, Merkle root truncation, and distributed storage, provided that verifiability is preserved. The concrete operational strategy is downstream work.
Open questions: hot/cold tiering criteria (asset termination, age-based, access-frequency-based), compression algorithm choice (Zstd, LZ4, with or without determinism requirements for verification), archival infrastructure (S3 Glacier, IPFS, Arweave) with cost-versus-availability trade-offs, Merkle root truncation thresholds and the cases for which Merkle proof alone suffices for reconciliation, distributed storage quorum (minimum count of full-data-holding nodes), and a storage cost projection model parameterized by asset count, message frequency, and retention period across Phase 5/6/7+ node counts.
Reference options under consideration: simple operation (every node retains full data permanently), single-tier with compression, hot/cold with Merkle root truncation (large-scale operation), and distributed storage with index-vs-full-data node separation and asset-level sharding (very large-scale operation with strong decentralization).
Resolution timeline: Phase 5 Public Testnet operational experience plus Phase 6 Mainnet Beta deployment. Likely subject of a separate operational specification or a v0.6/v0.7 specification update.
Operational Tooling
DLQ Automated Analysis
Classification: Deferred
v0.5 defines DLQ recovery as a four-step protocol (notification, analysis, decision, recording) with the analysis step assumed to be operator-driven.
Open questions: automatic classification of DLQ messages (transient vs permanent, pattern recognition across messageId and error code), identification of automatically retryable cases (especially for time-variant errors such as LEGAL_BASIS_EXPIRED_OR_NOT_YET_VALID and APPEAL_PERIOD_NOT_EXPIRED), automated impact-scope analysis (assets, parties, jurisdictions), and the boundary between automated decisions and required operator review.
Resolution timeline: Post-Phase 5 operational tooling.
Driver Slashing Mechanism
Classification: Future Research
v0.5 registers Drivers through a whitelist. The handling of malicious behavior (Drivers issuing false attestations) is not specified.
Open questions: Driver stake requirements, false-attestation detection mechanism, slashing procedure and rate, and the boundary of Driver operator liability.
Resolution timeline: Phase 4–5, alongside D-quencer staking formalization.
Slashing-Eligible Error Pattern Detection
Classification: Future Research
v0.5 marks two error codes (INVALID_SIGNATURE, INVALID_THRESHOLD_SIGNATURE) as slashing-eligible signals. The Conformance page recommends that conformant implementations surface these patterns to the consensus layer for slashing review. The detection thresholds, aggregation windows, and the consensus-layer slashing decision procedure are not specified in v0.5.
Open questions: failure-rate thresholds that trigger review (per node, per signer set, per asset), aggregation window length, the relationship between OIP-layer pattern signals and the consensus layer’s own attestation verification, the slashing decision authority (D-quencer governance, separate slashing committee), and the slashing rate calibration relative to economic incentives.
Interim handling: v0.5 implementations may emit pattern signals to local logs or to a per-implementation alerting channel. Cross-implementation slashing coordination awaits the consensus-layer specification.
Resolution timeline: Phase 4–5, formalized alongside the Driver Slashing Mechanism and broader D-quencer slashing logic.
Security
Quantum-Resistant Signatures
Classification: Future Research
v0.5 uses ECDSA, Ed25519 (SINGLE), and BLS (THRESHOLD), all of which are vulnerable to quantum attacks.
Open questions: choice of quantum-resistant signature algorithm (CRYSTALS-Dilithium and equivalents), migration strategy (gradual vs single-step), and the coexistence period between quantum-resistant signatures and the existing baseline schemes.
Resolution timeline: After NIST quantum-resistant standards are finalized. Reviewed in v1.0 or later.
Time-Skew Attack Defense
Classification: Pending Definition
v0.5 handles clock skew through a simple 5-second NTP tolerance. Detailed defense against malicious clock manipulation is treated as an operational concern rather than a protocol concern.
Open questions: the precise clockSkewTolerance value, time-synchronization verification mechanism (multi-source time comparison), and the procedure for isolating nodes that violate the skew tolerance.
Resolution timeline: Phase 4 D-quencer integration.
Evidence Hash Verification Mechanism
Classification: Pending Definition
v0.5 requires regulatory-action Evidence structures to carry documentHashes, witnessSignatures (optional), and externalReferences. The validation step that produces EVIDENCE_HASH_INVALID verifies the integrity of the supporting documentation, but the precise verification procedure is not formalized.
Open questions: which hash algorithm and serialization the documentation uses (SHA-256 over canonical JSON, IPFS CID, custom Merkle structure), how the receiver retrieves the original document for hash comparison (off-chain via externalReferences, on-chain via document storage contract), the trust relationship for witness signatures (are witnesses regulator-vetted, or self-claimed), and the cache and revocation model for documents whose external location changes after the action is recorded.
Interim handling: v0.5 implementations enforce hash-equality only when the document is locally available. Hash verification is treated as best-effort when the document must be retrieved over a network path that may be unavailable at validation time.
Resolution timeline: Phase 3 RWA Registry contract deployment, jointly with the regulatory-action audit interface.
Specification Process
Error Code Category Extension Process
Classification: Future Research
The Error Reference page’s Extension Policy permits new codes within the seven existing categories at minor versions, but introducing a new category requires a major version increase. The procedure governing such additions (proposal, review, vote) is not formalized in v0.5.
Open questions: who proposes new error codes (implementers, governance, OSS operators), the review process for proposed additions (technical review, semantic-overlap check with existing codes, prefix-conflict check), the vote threshold for a new category, and the documentation update schedule (concurrent with the version increase or as a separate operational changelog).
Interim handling: v0.5 implementations encountering an unknown error code from a peer fall back to category-prefix handling per the Error Reference Extension Policy. New codes proposed during the v0.5 lifetime are recorded in the Changelog rather than added to the v0.5 specification.
Resolution timeline: v0.6 specification process formalization, alongside the broader EIP-style proposal procedure.
v0.5 Interoperability Testing
Classification: Deferred
Wire-level interoperability test vectors are not defined for v0.5. Publishing such vectors against a wire format that has not yet been frozen would produce vectors that v0.6 would have to invalidate.
What v0.5 provides instead: the semantic conformance contract on the Conformance page, exercised through the self-check list against an implementation’s own test corpus.
Resolution timeline: v0.6 .proto refinement. The interoperability test suite work begins with the public release of the oraclizer/oip-spec repository.
Summary by Phase
The table below cross-indexes the open issues by their resolution phase, for readers tracking the v0.5 → v1.0 trajectory. Phases correspond to development phases on the project roadmap; specific calendar dates are operational matters and not part of this specification.
| Phase | Open Issues to Be Resolved |
|---|---|
| Phase 2 | Multi-Signatory authority field (skeleton, Mock Canton) |
| Phase 3 | Party–OCID mapping invalidation; RWA Registry Solidity signatures; RWA Registry – Authority Registry integration; Evidence hash verification mechanism |
| Phase 4 | CRITICAL priority authority system (incl. anomaly detection); time-skew attack defense; Phase timeout governance adjustment; DLQ alert threshold governance; Driver slashing (begins); slashing-eligible error pattern detection (begins) |
| Phase 5 | Multi-Signatory authority field (production); Driver key rotation and bootstrap; Driver slashing; slashing-eligible error pattern detection; long-term storage strategy (begins); cross-chain reconciliation procedure detail |
| Phase 6 | Dynamic routing table updates; long-term storage strategy |
| v0.6 wire-format work | Message size limits and fragmentation; v0.5 interoperability testing; error code category extension process |
| v0.6 or later (independent) | Restricted DSL extensions |
| Tracks ERC-TRUST | ERC-TRUST integration interface |
| Tracks NIST PQC | Quantum-resistant signatures (v1.0 or later) |
| Operational tooling (post-Phase 5) | DLQ automated analysis |
| Post-Phase 5 / Future | Inter-asset dependency race conditions; token standard extensions |
The schedule is indicative. Items may move earlier as upstream dependencies clear, or later if downstream phases reveal that the current framing needs revision. Each material change is recorded in the Changelog.
Related Pages
- OIP Overview establishes the v0.5 versioning trajectory and the boundary OIP draws.
- Conformance defines what an implementation MUST satisfy to claim v0.5 compatibility, including the deferred status of wire-level interoperability tests.
- Data Model defines the type structures that several open issues will refine.
- State Management defines the pending sync queue invariants whose long-term storage strategy is open.
- Validation defines the RWA Registry self-defense whose authority verification implementation is open.
- Regulatory Actions defines the regulatory action set whose Restricted DSL extensions and evidence verification are open.
- Cross-chain Protocol defines the staged coordination whose phase timeout governance and reconciliation detail are open.
- Fault Tolerance defines the DLQ whose alert threshold governance and automated analysis are open.
- Error Reference defines the extension policy whose category-extension process is open.
- Routing defines the routing table whose dynamic update mechanism is deferred.
- Changelog records material changes to v0.5 and the eventual v0.6 release.