Digital Asset Operations & Compliance Infrastructure

Prime broker due diligence asks the same questions it asks every counterparty. Your operations need to answer them.

On-chain settlement, WORM audit trail, maker-checker enforcement, and books-and-records support in one system. The same control framework that governs examination-ready securities operations: running from the digital rail outward.

The challenge for digital asset firms seeking institutional capital is not on-chain settlement capability. Every credible digital asset firm can settle on-chain. The gating factor is operational credibility: the ability to demonstrate, to a Tier-1 prime broker or an LP doing Operational Due Diligence (ODD), that the firm's controls infrastructure meets the same standard expected of any serious counterparty.

ODD evaluations ask specific questions: What does your audit trail cover, and can you export it? How do you enforce maker-checker for settlement instructions? What is your segregation-of-duties model? Can you show me the approval chain for this specific token transfer, including who authorized it and when? These are not crypto-specific questions. They are institutional counterparty questions applied to an on-chain operating environment.

Legacy post-trade systems were built for traditional rails and retrofitted for digital assets. The result is an architecture where on-chain events live in a separate log, controls documentation exists outside the operational record, and producing an ODD package requires assembling evidence from multiple systems.

Devancore inverts this. On-chain settlement and traditional settlement are two expressions of the same operational framework — not a primary system with a digital asset bolt-on.

The institutional bridge. Devancore provides the control evidence required to onboard Tier-1 prime brokers who have previously avoided digital asset counterparties due to gaps in supervisory rigor. A complete maker-checker trail, a WORM event log covering on-chain and traditional events, and a configurable segregation-of-duties model: this is what ODD reviewers are looking for.

Institutional audit trail for digital asset operations: one log, every rail

A Tier-1 counterparty evaluating a digital asset firm's operations asks a version of the same question prime brokers ask every counterparty: whether the firm can produce the complete record for a given transaction: who initiated it, who approved it, what state the position was in before and after, and what the settlement outcome was. The question is not new. The difficulty arises when the answer requires pulling records from two separate systems.
  • Unified event log

    Devancore's event log is designed as a unified audit record for both traditional and on-chain events. A token transfer on Ethereum, a stablecoin settlement instruction on Arc Network (Circle's institutional settlement infrastructure), a smart contract execution on Polygon, and a DTC equity delivery: each is an attributed lifecycle event in the same log with the same five-attribute structure: who, what, when, where, and source. The DTC instruction and the token transfer share columns. The evidence structure is the same.

  • BD vs non-BD: books-and-records and ODD evidence

    For digital asset firms that are registered broker-dealers, the WORM design properties of this event log are designed to support books-and-records requirements under SEC Rules 17a-3 and 17a-4: covering both on-chain and traditional settlement events without separate digital asset recordkeeping infrastructure. Full Rule 17a-4 compliance requires additional elements (duplicate storage, written undertakings, examiner access); the event log is designed to support the records foundation. For non-BD firms, the same log provides the operational evidence record that ODD reviewers and institutional counterparties request, without implying automatic SEC examination coverage.

  • Exam-ready export

    You can evidence on-chain events from Devancore's log without relying on ad-hoc blockchain explorer screenshots. The log is the record. The export is exam-ready.

Maker-checker and segregation of duties for on-chain settlement: Devancore as the policy engine

On-chain operations create a specific controls vulnerability: the settlement instruction can, depending on the custody model, be authorized and executed by a single actor who holds the relevant key or wallet credential. The cryptographic signing happens at the custody layer. But the decision to send the instruction, and the supervision of that decision, happens upstream of the custody layer.
  • Institutional policy engine

    This is the design gap that Devancore closes. While the custody layer handles cryptographic signing, Devancore operates as the institutional policy engine: no on-chain instruction is released to the signer without a verified maker-checker event in the audit log. The maker submits the instruction, the checker reviews and approves, and the approval event is recorded; only then is the instruction passed to the custody layer for execution.

  • Supervisory standards and ODD

    For firms operating under supervisory standards, including FINRA members and equivalently supervised entities, single-actor release of material instructions creates obvious segregation-of-duties weaknesses that ODD reviewers will identify immediately. The maker-checker design addresses this as a structural property of the workflow, not as a documented policy that depends on human adherence. The maker-checker matrix is configured in the system's RBAC layer: which roles can make, which can check, and which constitute the escalated-access role for time-critical situations. Emergency action under the escalated-access role still requires a second authorized actor, and every step is logged. The speed of blockchain settlement does not compress the supervisory control requirement.

  • Segregation of duties at the role level

    A user authorized to create on-chain delivery instructions cannot authorize them. A user authorized to authorize them cannot create them. The role model encodes the SoD requirement structurally — not as an access control list that can be inadvertently expanded.

On-chain settlement finality: probabilistic to practically irreversible, re-org risk quantified

A transaction broadcast to the mempool is pending — not confirmed. A transaction included in one block is provisionally confirmed, but subject to re-org risk if the chain reorganizes. A transaction that has reached the configured block depth threshold (calibrated to the rail's consensus mechanism) is practically irreversible. These are different states of the same transaction, and they produce different risk exposures.
  • Phantom settlements

    Most digital asset operations systems do not distinguish these states formally in the position record. The result is phantom settlements: positions that appear confirmed on the operations ledger but remain probabilistic on the chain. In a volatile market, this matters for liquidity allocation: a firm treating a one-block confirmation as final is allocating against a position that could, in adversarial conditions, be reversed.

  • Finality status by rail

    Devancore's finality model assigns a finality status to on-chain positions: Probabilistic during block accumulation (re-org risk present), transitioning to a sufficiently confirmed threshold state when configured block depth is reached. The transition point is defined per rail and per risk tolerance, not assumed from the asset class. Arc's finality is computed against Arc's consensus parameters. Ethereum's is computed against the configured block depth threshold. Internal ledger transfers are final upon posting. The ops team does not monitor block explorers for confirmation counts. Devancore surfaces the current finality status of every on-chain position in the same view as traditional settlement finality: one operational picture, three rail types.

  • Ops Copilot, Devancore's explain-only AI assistant

    Ops Copilot serves a specific function here: it acts as a blockchain-to-English translator for compliance and risk stakeholders who are not blockchain-native. Ops Copilot explains the chain state (for example, why an on-chain position is showing probabilistic finality, or whether the situation is re-org risk or network congestion) in terms the CCO and risk team understand, standard trade/settlement/position nomenclature, without requiring them to interpret raw block data. Every Ops Copilot session is logged as part of the operational record.

Stablecoin settlement and digital asset net capital: haircut framework for every firm type

Capital adequacy is the final institutional credibility gate. How a firm treats its digital asset positions in its capital computation, and how it can demonstrate that treatment to a prime broker or investor, is a function of whether the right haircut framework is applied to every position type.
  • For registered broker-dealers

    Digital asset positions are subject to capital treatment under applicable SEC guidance and Rule 15c3-1. Most digital assets currently attract a 100% haircut as non-allowable assets. The GENIUS Act (enacted July 2025, effective date pending implementing regulations) will establish the stablecoin issuer compliance framework. For payment stablecoin positions, SEC Trading and Markets staff has indicated it would not object if a broker-dealer applies a 2% haircut for purposes of Rule 15c3-1, subject to the conditions described in the staff FAQ. Devancore's haircut table supports this treatment as a configuration within the net capital computation. Firms should confirm the applicable conditions with legal counsel. For the 15c3-3 customer protection framework: where a registered BD holds customer securities that include tokenized assets subject to the rule, Devancore's finality-aware position tracking provides operational input supporting the possession or control determination. The compliance function applies the full 15c3-3 analysis; Devancore supports the operational data layer.

  • For non-BD digital asset firms

    Capital adequacy obligations are set by counterparty requirements, LP agreements, and equivalent internal risk standards, not by Rule 15c3-1 directly. The same haircut framework logic applies as a capital management tool: distinguishing asset types, applying risk weights, and computing net exposure across the portfolio with consistent methodology. Devancore's FinOps layer supports this whether or not the firm is a registered BD.

  • Real-world asset (RWA) exposure

    For firms holding tokenized real-world assets, tokenized Treasuries, tokenized credit instruments, on-chain real estate vehicles, the same capital treatment framework applies: asset classification, applicable haircut, and net position exposure tracked in the same computation as traditional and digital-native positions. No separate RWA capital worksheet.

The digital asset firm use case is the on-chain-first entry point to a system designed for both rails simultaneously. The controls and audit infrastructure that provide the institutional credibility argument are the same controls that broker-dealers and asset managers use. The difference is the entry point — not the framework.

For the technical foundation