June-30 committed scope

The June-30 build moves Ascend from a demonstrative model toward a compliant, securities-only institutional credit platform. The committed scope for this milestone is organized around three themes.

Two further themes — rehypothecation via a vToken escrow, and DeFi exercise destinations — are architectural direction only and are captured in the Beyond June-30 section; they are not in this milestone's build.

The document is layered so you can stop at the depth you need.

Each committed item is written as a requirement with an acceptance criterion. Identity and KYC are presented at the requirements level against the commodity ERC-3643 / ONCHAINID stack OZ already knows, not as deep implementation.

Requirements are written against the code as it stands today. The ERC-3643 and ONCHAINID dependencies are already present in ascend-contracts (@erc3643org/erc-3643, @onchain-id/solidity), and AuthorityWithIdentityRegistry already integrates ERC-3643 by forwarding canCall to a primary authority with a per-(target, selector) Identity Registry fallback — the natural home for a single registry instance. The platform side has an indexing pipeline (subgraph → ingester → sink → event-relay → platform-service → projections → API → frontend) and React frontends (apps/admin, apps/client) where a Wizard, DDF, Reserve, margin-account, and credit-facility views already exist. The dependencies are already installed, so the gap is deployment, wiring, and the UI slice, not new dependencies.

Part A covers the onchain protocol work. The June-30 contract scope centers on four items: identity and compliance wired into the Credit Facility (A1, A2, A3) — which gates the borrower-lifecycle path — four ERC-3643 mock assets for end-to-end validation (A4), collateral deposit-pause controls (A7), and a focused subset of admin/operator controls (A8 subset). The lender-gated Liquidity Module (A5) and the remaining items (A6, A9, A10, and the rest of A8) are forward-looking direction, collected in the Beyond June-30 section; for A5 we invite OZ's proposed approach. All June-30 work targets the Sepolia testnet.

Simplified contracts view: current → target

flowchart LR
  subgraph Current["Current — ascend-contracts"]
    H1["Hub"] --> CF1["CreditFacility (clone)"]
    CF1 --> M1["Modules: Liquidity, Valuation,
Risk, Fee, Metadata, Freezer"]
    CF1 --> DA1["DistressedAssetsAuction"]
    AWI1["AuthorityWithIdentityRegistry
(ERC-3643 fallback path)"] -.-> CF1
  end

  subgraph Target["Target — June-30 additions"]
    H2["Hub"] --> CF2["CreditFacility (clone)"]
    CF2 --> M2["Modules (existing)"]
    CF2 --> DA2["DistressedAssetsAuction"]
    CF2 -. "initialize / hooks" .-> IR["A2: Identity Registry
+ claim topics (KYC,
Qualified Lender)"]
    CF2 -. "installHook" .-> CMP["A3: ModularCompliance
+ rule modules"]
    CF2 -. "direction" .-> PLM["A5: Permissioned Liquidity
Module (beyond June-30)"]
    IR --> OID["A1: ONCHAINID suite"]
    CMP --> IR
    PLM --> IR
    A4T["A4: 4 ERC-3643
mock assets"] --> IR
    A4T --> CMP
    AWI2["AuthorityWithIdentityRegistry
(single registry — reconciled)"] -.-> IR
  end

  Current ==>|"A1, A2, A3, A4 + A7/A8 controls"| Target
  classDef add stroke-width:2px
  class OID,IR,CMP,A4T add
      

The target keeps the existing Hub → CreditFacility → modules + DistressedAssetsAuction shape and adds the identity, compliance, and permissioned-liquidity layer on top. Consumers (the facility, the liquidity module, the mock assets) hold pointers to the Identity Registry and Compliance, and the registry resolves the ONCHAINID. The single-registry reconciliation (one IdentityRegistry, not two) is the connective change.

Identity and compliance — requirements summary

Stated as requirements and acceptance against the commodity ERC-3643 / ONCHAINID stack.

Claim topics in scope for June-30: KYC (identity verified, AML/sanctions cleared — required of all participants including every lender) and Qualified Lender (qualified/accredited or institutional status — the Qualified-Lender / accredited claim model is seeded for June-30, while lender-side enforcement via the Permissioned Liquidity Module (A5) is forward direction). Country (jurisdiction/residency, enforced via the A3 Country rule module) is the deferrable cut-line.

Part B covers the platform's offchain services and UI: the indexing pipeline (subgraph to projections to API) and the two frontend apps (admin and client). For June-30, the focus is a curated UI slice that lets the end-to-end borrower / credit story render convincingly on Sepolia testnet, with the admin / operator controls surfaced, and the reserve and distressed-asset views populated. The forward-looking items (vToken, rehypothecation, the “Exercise” DeFi flows) are summarized in the Beyond June-30 section, as direction rather than committed scope.

These items are architectural direction, not committed June-30 scope. They are recorded here so the June-30 build leaves clean extension points. None should be implemented or production-flagged without separate sign-off and external audit.

Contracts

Platform

This is the committed scope for the 30 June 2026 demo on Sepolia testnet. It is a ceiling, not a starting point: the borrower / credit story end-to-end (deposit ERC-3643 collateral → onboard via ONCHAINID → borrow stablecoins → effects surfaced in the admin app), plus the admin/operator controls and the supporting platform pages.

Four workstreams map to the contract and platform items above. The acceptance column is the heart of “demo-ready” — it is what we will check against on 30 June.

Suggested sequencing (dependency-ordered, indicative)

A light sequencing suggestion, not a fixed contract — sequence to your own dependency read.

The floor — non-negotiables if a workstream slips

These apply across the contract items and are worth fixing once, centrally.

These are the build-relevant points we would like to settle together before grooming tickets. None blocks starting the deploy/wiring work; all affect the exact shape of what ships.

Appendix A — ERC-3643 (T-REX) component glossary

Appendix B — required claim topics (initial)

Appendix C — key file references

For the engineering team, the existing code touchpoints each workstream builds on.

Appendix D — contracts: current → target

The current ascend-contracts shape grows toward the target by adding the identity and compliance layer. The additions (ONCHAINID + Identity Registry, and ModularCompliance + rule modules) are the 30 June contract scope — A1/A2 and A3. The permissioned-liquidity layer (A5) is shown as forward direction, not committed June-30 scope.

flowchart TB
    subgraph current["Current — ascend-contracts"]
        Hub1["Hub
(cloneDeterministic + initialize)"]
        CF1["CreditFacility
(ERC-721 margin accounts)"]
        MOD1["Modules:
Liquidity, Valuation, Risk,
Fee, Metadata, Freezer"]
        DAA1["DistressedAssetsAuction"]
        AUTH1["AuthorityWithIdentityRegistry
(ERC-3643 fallback)"]
        Hub1 --> CF1
        CF1 --> MOD1
        CF1 --> DAA1
        CF1 -.-> AUTH1
    end

    subgraph target["Target — 30 June additions (highlighted)"]
        Hub2["Hub"]
        CF2["CreditFacility
(identity + compliance wired via initialize / hooks)"]
        MOD2["Modules
(existing)"]
        DAA2["DistressedAssetsAuction"]
        OID["ONCHAINID
(per-participant claims)"]
        IR["Identity Registry
(+ ClaimTopics, TrustedIssuers, Storage)"]
        MC["ModularCompliance
(rule-module catalog:
Trading Hours, Size, Frequency,
Country, Rate-limit, Sanctions,
Credit-draw, Credit Rating)"]
        PLM["Permissioned Liquidity Module
(direction — beyond June-30)"]
        Hub2 --> CF2
        CF2 --> MOD2
        CF2 --> DAA2
        CF2 --> PLM
        CF2 --> MC
        CF2 --> IR
        IR --> OID
        MC --> IR
        PLM --> IR
    end

    current ==>|"A1/A2 · A3"| target
    classDef add stroke-width:2px
    class OID,IR,MC add
      

The target keeps the existing Hub → CreditFacility → modules + DistressedAssetsAuction shape and adds the identity, compliance, and permissioned-liquidity layer on top. Consumers hold pointers to the Identity Registry and Compliance, and the registry resolves the ONCHAINID. The single-registry reconciliation (one IdentityRegistry, not two) is the connective change.

This is the confirmed roles-and-permissions reference noted as pending against the abstract AccessManager implementation. It is written as a specification for the setTargetFunctionRole wiring and the role-admin graph in ascend-contracts — the roles the protocol needs and how they nest — not an implementation dump. Roles tied to the permissioned Liquidity Module (A5) are marked forward direction, consistent with the body descope.

E.1 — The access model: one authority, two onboarding paths

Ascend is an onchain tri-party agent: the neutral custodian-bank role of a classic tri-party arrangement is disintermediated into the Hub and its modules, while a licensed Clearing & Settlement Broker-Dealer carries the regulatory wrapper. Three economic parties — Borrower, Lender (cash), and the Agent / Operator (the broker-dealer running the Hub) — interact through one access authority.

E.2 — Identity layer: the parties and their ONCHAINID claims

Each verified party holds an ONCHAINID in the Identity Registry, checked on every ERC-3643 transfer. Claims are issued offchain by a Trusted Issuer (ClaimIssuer). Claim topics for the product set: KYC · Qualified Lender · Country. Credit Rating is enforced as a Compliance rule module (A3), not an identity claim.

The product model carries the fuller claim set above. A demo harness may stand in a coarser eligibility check for borrower verification and a single lender liquidity claim topic; the demo proves the mechanism, not the final claim schema.

E.3 — Operator / Agent roles (AccessManager)

The agent functions a tri-party custodian traditionally performs, encoded as roles in ascend-contracts. June-30 core unless marked forward. Granularity is per-selector (setTargetFunctionRole), but the role set is deliberately coarse — Operator absorbs collateral, pause, hooks, fees, freeze, and risk params rather than splitting into many granular roles.

Margin-account ops gate on the NFT owner, not the raw caller — an approved operator acts only while the owner still qualifies under role-or-identity.

E.4 — Governance: OWNERS + timelock

Cross-cutting configuration is not a single unilateral key. The model is OpenZeppelin AccessManager with role separation, execution delays / timelocks, and two-owner OWNERS change control on cross-cutting config, with a full audit trail of configuration changes (the enforceable governance admin requirement). There is no single unilateral upgrade path — this is the answer to “who holds the keys / upgrade-rug risk.”

E.5 — Machine roles (contracts, not granted to humans)

Implementation wiring, not operator grants. The Hub itself is the facility factory.

E.6 — Forward direction: permissioned liquidity Not June-30

These gate the permissioned Liquidity Module, which is forward direction, not June-30 committed scope (see A5 — OZ to propose its approach). Listed so the access graph is coherent end-to-end.

E.7 — Excluded: scaffolding, not product roles

For a clean spec boundary, the following are deploy-time test scaffolding, not roles to model in the product access graph:

E.8 — Mapping to the June-30 scope