Onchain Fund Admin 2.0: Smart-Contract Patterns for NAV, Subscriptions, and Redemptions

In 2025, tokenized funds crossed the line from pilot to production. BlackRock’s BUIDL now spans multiple chains and is accepted as institutional collateral, while Franklin Templeton’s BENJI continues to prove that regulated money market funds can live natively on public ledgers. The question is no longer “if,” but “how” to implement fund administration directly in contracts—safely, transparently, and interoperably. (prnewswire.com)

Summary: This post distills the concrete, production-ready smart-contract patterns 7Block Labs uses to implement Fund Admin 2.0 onchain: deterministic NAV pipelines, ERC-4626/7540 vault flows for async subscriptions/redemptions, and compliance rails (EAS+ERC‑3643) that plug into today’s custody, oracle, and settlement ecosystems.

---

Who should read this

• Asset managers launching tokenized MMFs, credit funds, interval funds, or multi-asset strategies
• Corporate treasurers seeking onchain liquidity with T+0 settlement
• Product and engineering leaders evaluating build-vs-buy for fund operations

---

The design goal: operational certainty onchain

Fund Admin 2.0 is about two guarantees that smart contracts can enforce better than spreadsheets:

• Price certainty: NAV is computed and signed the same way every day, with verifiable inputs and a tamper-evident trail.
• Flow certainty: subscriptions/redemptions are either atomic or explicitly asynchronous with an auditable lifecycle and predictable settlement windows.

Below we break down the reference architecture and implementation details we deliver for clients.

---

Core building blocks

1) Shares: ERC‑4626 vaults, with async flows via ERC‑7540

• Use ERC‑4626 for share accounting (assets↔shares conversion) so exchanges, custodians, and DeFi legos integrate you day one. It’s the canonical standard for tokenized vaults. (eips.ethereum.org)
• Real-world assets rarely settle atomically; implement ERC‑7540 to handle asynchronous subscriptions/redemptions (Requests that become Claimable later). This is key for T+1 bond settlements, bank wires, or cut-off processing. (eips.ethereum.org)
• If your fund accepts multiple deposit assets (e.g., USDC, USDT, EURC) or has multiple entry points, add ERC‑7575 (multi-asset extension) to keep one share token across multiple asset adapters. (eips.ethereum.org)

Practical notes:

• Expose preview functions and per-epoch limits on ERC‑4626; for async paths, follow ERC‑7540’s rule that

  previewDeposit/previewMint

  revert and claim must use the base

  deposit/mint/redeem/withdraw

  semantics once Requests are claimable. (eips.ethereum.org)
• Consider ERC‑7887 (cancelation) if investors need to cancel pending Requests (e.g., after a market-wide halt). (eips.ethereum.org)

2) NAV: deterministic oracle pipelines (pull, push, optimistic)

Reliable NAV onchain is the difference between a fund token and a bearer IOU. We recommend a tiered approach:

• First-party market data: Use Pyth Core/Pro feeds for reference asset pricing (USTs, repo, FX) with explicit Feed IDs and verifiable update cadence. For many funds, Hermes-powered updates with pull-oracle semantics are ideal (batch multiple feeds per tx). Pyth also supports direct NAV feeds (e.g., Apollo credit NAV), showing the pattern is battle-tested. (docs.pyth.network)
• Institutional data standardization: Chainlink’s Data Standard (ODP) supports NAV/PoR “SmartData” alongside price feeds and streams—useful when your administrator (or custodian) must publish official end-of-day NAV with signed proofs. (docs.chain.link)
• Optimistic verification: For non-trivial NAVs (private credit marks, level-3 inputs), implement UMA’s Optimistic Oracle: the admin asserts NAV, there’s a configurable liveness window for dispute, and UMA’s DVM arbitrates if challenged. It’s widely used, with typical liveness from 2 hours to 2 days and DVM resolution in ~2–4 days if escalated. (docs.uma.xyz)

Operational safeguards we implement:

• NAV medianization: aggregate multiple sources (e.g., two administrators + custodian) and require a threshold of matching signatures before publishing NAV.
• Circuit breakers: pause claims if NAV deviates beyond X basis points from a TWAP of reference assets or if any source halts.
• Sequencing: publish preliminary intraday iNAV for indicative flows; finalize EOD NAV post-cutoff.

3) Settlement rails: stablecoins first, multi-chain second

• Default subscription currency: USDC—fully reserved, widely integrated with custody and on/off-ramps, natively issued on many chains, and with CCTP v2 for near-instant cross-chain settlement. This reduces “wrong chain” issues and funding friction in onboarding. (circle.com)
• For cross-ecosystem distribution or chain-local utility, deploy additional share classes rather than bridges. BlackRock’s BUIDL expanded via new share classes across multiple blockchains—this is the cleanest pattern to avoid canonical-bridge risk. (prnewswire.com)
• If you must bridge shares or settlement assets, prefer bank-grade interoperability (e.g., Chainlink CCIP with audited risk controls) and off-exchange collateral models to avoid hot-wallet exposure. Recent production usage and custody-integrated collateralization illustrate the trajectory. (chain.link)

4) Compliance rails: programmable KYC/KYB, transfer rules, and attestations

• Token-layer controls: For permissioned funds, implement ERC‑3643 (T‑REX)—an ERC‑20-compatible standard that enforces identity registry checks, transfer pre-checks, freezing/pausing, and agent-controlled forced transfers and recovery. This is the most complete “regulated RWA” token interface. (eips.ethereum.org)
• Lightweight restrictions: If you need simple limits (holder counts, lockups, whitelists) without full identity registry, ERC‑1404 is a minimalist, composable alternative. (github.com)
• Attestation backbone: Use EAS to anchor KYC/KYB/accreditation attestations onchain. EAS runs across major L1/L2s, supports custom schemas, and has processed millions of attestations—ideal for “prove-eligible” gating without exposing PII. (attest.org)

---

What leading funds are signaling (and what to copy)

• Multi-chain distribution and collateral utility are here. BUIDL’s expansion across chains and its acceptance as off-exchange collateral on tier-1 venues show how fund tokens can become core market primitives—if price discovery and compliance are solid. (prnewswire.com)
• Regulated money funds can operate on public chains: Franklin’s BENJI runs under the 1940 Act, with one onchain token per fund share—evidence that strict compliance and public blockchains are compatible. (news.franklinresources.com)
• Administrators are standardizing oracle inputs: Securitize’s selection of RedStone as a primary oracle for major issuers points to a future where NAV and fund observables are machine-readable and composable. (theblock.co)

---

End-to-end flow patterns (with precise details)

A) Subscription (USDC into shares)

1. Pre-trade checks

• Investor submits EAS attestations (schema: KYC, accreditation, jurisdiction). Contract verifies “isEligible()” against current policy. For permissioned funds, ERC‑3643

  canTransfer

  checks are also run on mint. (eips.ethereum.org)

1. Price context

• Contract queries reference prices (UST bills, FX) via Pyth by Feed IDs, validates staleness thresholds (e.g., < 90s), and snapshots iNAV. If an official administrator NAV exists (Chainlink Data Standard “NAV”), it overrides iNAV during subscription cut-off; otherwise, iNAV is used for indicative allotment. (docs.pyth.network)

1. Funds-in

• Investor transfers USDC to the vault adapter on chain X. If treasury ops require chain Y, initiate CCTP v2 migration (seconds-level finality) with a per-request cap and onchain receipt, then emit

  FundsReceived(requestId, amount, chainSrc, chainDst)

  . (theblock.co)

1. Request lifecycle (ERC‑7540)

• Contract records

  requestDeposit(investor, assets)

  with status Pending.
• At cut-off (e.g., 16:00 UTC), admin publishes NAV; if optimistic, assert NAV via UMA with a 6‑hour liveness. If undisputed, it finalizes; disputes pause claims until DVM resolution (2–4 days). (docs.uma.xyz)
• When Claimable, investor calls

  deposit()

  to mint shares at the finalized NAV; the contract may automatically call

  deposit()

  in a batch job to minimize UX friction.

Controls we add:

• Anti-front-running: per-investor min/median price guardrails; reject if mid-price moved > X bps since request.
• Liquidity gates: per-epoch hard cap and “soft cliffs” to protect portfolio transition costs.
• Cancelation (optional): if Requests remain Pending beyond SLA, enable ERC‑7887 cancel to return assets. (eips.ethereum.org)

B) Redemption (shares into USDC)

1. Request and lock

• Investor calls

  requestRedeem(shares)

  . Shares are locked; status Pending. If ERC‑3643 is used, ensure freezes don’t block redemptions beyond regulatory holds.

1. Portfolio settlement

• The fund manager raises cash offchain (repo unwind, T-bill sale). Meanwhile the contract:
  • Monitors reference prices via Pyth, halting claims if deviation > circuit threshold.
  • Accepts an official NAV or cash price from Chainlink Data Standard once settlement is known. (docs.chain.link)

1. Claim and payout

• When Claimable,

  redeem()

  burns shares, pays USDC. If the investor requested cross-chain payout, use CCTP v2 with onchain proofs and a per-address daily limit.

1. Partial fills and gates

• Configure pro-rata partial claims (e.g., 30% today, 70% at T+1) with clear eventing:

  PartialClaim(requestId, tranche, pct, navRef)

  .

---

Reference contract skeletons (Solidity-like pseudocode)

interface INavOracle {
  function latestNav(uint256 fundId) external view returns (
    uint256 navPerShare,  // 1e18
    uint256 timestamp,
    bytes32 version,      // e.g., EOD_2025-12-01
    bool finalized
  );
}

contract FundVault is ERC4626, ERC7540 /* + ERC7575 if multi-asset */ {
  INavOracle public nav;
  uint256 public cutoff; // daily UTC cutoff

  struct Request { address user; uint256 assets; uint256 shares; uint64 t; uint8 state; }
  mapping(bytes32 => Request) public requests;

  // SUBSCRIBE
  function requestDeposit(uint256 assets, address receiver) external returns (bytes32 rid) {
    _preCheckEligibility(receiver);                // EAS/3643 gate
    _checkStaleness(_pullReferencePrices());       // Pyth feeds; stale if > 90s
    _pullUSDC(assets, msg.sender);                 // possibly via CCTP v2 receipt
    rid = _storeRequest(receiver, assets);         // Pending
  }

  function deposit(uint256 assets, address receiver) public override returns (uint256 shares) {
    // Only allowed when request is Claimable
    (uint256 navPS,, , bool fin) = nav.latestNav(FUND_ID);
    require(fin && block.timestamp > cutoff, "NAV not finalized");
    shares = _convertToShares(assets, navPS);
    _mint(receiver, shares);
  }

  // REDEEM
  function requestRedeem(uint256 shares, address receiver) external returns (bytes32 rid) {
    _lockShares(msg.sender, shares);
    rid = _storeRedeem(receiver, shares);          // Pending
  }

  function redeem(uint256 shares, address receiver, address owner) public override returns (uint256 assets) {
    require(_isClaimable(owner, shares), "Not claimable");
    (uint256 navPS,, , bool fin) = nav.latestNav(FUND_ID);
    require(fin, "NAV not finalized");
    assets = _convertToAssets(shares, navPS);
    _burn(owner, shares);
    _payoutUSDC(receiver, assets);                 // optional cross-chain delivery
  }
}

Key notes:

• INavOracle

  can abstract Pyth (pull updates), Chainlink (push via DON), or UMA (optimistic assertions).
• All pricing reads enforce staleness and drift limits.
• Claim functions demand

  finalized == true

  after cut-off unless your strategy allows intraday claims.

---

NAV pipeline patterns (what actually runs in production)

1. Pull-oracle NAV (reference-backed)

• Prices from Pyth for all reference assets at EOD snapshot; NAV aggregated onchain in a single tx; store

  (navPS, version, timestamp)

  . Feed IDs and Hermes updates make repeatability straightforward. (docs.pyth.network)

1. Push-oracle NAV (administrator-of-record)

• The fund admin signs NAV offchain; a DON (e.g., Chainlink) posts the value to

  NavOracle.finalize()

  . We add multi-signer requirements and require a PoR-style checksum over the holdings file. (docs.chain.link)

1. Optimistic NAV (complex marks)

• Admin asserts NAV via UMA’s OO with 6–12h liveness; if undisputed, it finalizes automatically. We recommend bonding rules proportional to TVL, with emergency halts if dispute rate spikes. (docs.uma.xyz)

Best practice:

• Publish both iNAV (indicative) and official NAV; only official NAV unlocks Claims.
• Emit a hash of the holdings report/materiality thresholds—auditors love this.
• Keep a “last-good NAV” fallback to allow controlled redemptions if feeds are down.

---

Compliance and identity: two proven blueprints

• Full-permissioned: ERC‑3643 share token + Identity Registry + EAS attestations as claims within the registry (e.g., “KYC‑OK,” “Professional Investor,” “US‑QIB”). Pre-transfer

  canTransfer()

  checks ensure every movement respects the rulebook; Agent role can execute forced transfers for regulatory actions. (eips.ethereum.org)

• Light-permissioned: ERC‑4626 share token + ERC‑1404 overlays for simple whitelists, lockups, holder caps. EAS stores eligibility proofs, but there’s no full identity registry. This suits LP-only or employee funds with narrow distribution where you still want onchain enforcement and logs. (github.com)

---

Interop and distribution: share classes, not bridges

• Prefer discrete onchain share classes (e.g., Mainnet, BNB Chain, Aptos, Optimism) over bridging a single token. That’s how BUIDL widened distribution while maintaining clarity in compliance and NAV updates per chain. If you need cross-chain liquidity, wire them together at the admin layer with CCIP or custody-based collateral models. (prnewswire.com)

---

Audit hotspots we flag early

• ERC‑7540 state machine: Pending→Claimable→Claimed transitions, replay protection, and request ID uniqueness. (eips.ethereum.org)
• Staleness/heartbeat: NAV acceptance must check source heartbeats; e.g., reject if any Feed ID is stale beyond the policy. Pyth docs provide concrete heartbeat/deviation parameters per chain. (dev-forum.pyth.network)
• Oracle bonds and liveness (optimistic NAV): parameterize by TVL; document escalation paths and timelocks. (docs.uma.xyz)
• ERC‑3643 agent powers: log forced actions and separate admin keys from operations keys; map them to SOC2 controls. (eips.ethereum.org)

---

KPIs and ops dashboards that matter

• Oracle health: staleness, deviation, dispute rate (UMA), signer availability (Chainlink DON), and feed coverage per asset class. (docs.chain.link)
• Cut-off SLA: time between cut-off and NAV finalization; percent of Requests claimed within target window.
• Liquidity gates: % of requests partially filled; average tranche count per redemption.
• Compliance posture: attestations freshness (EAS), failed

  canTransfer()

  attempts, jurisdictional distribution. (attest.org)

---

What we’re shipping at 7Block Labs

• An ERC‑4626/7540 vault kit with:
  • Async Requests, partial fills, cancelation hooks
  • Pluggable

    INavOracle

    (Pyth, Chainlink, UMA)
  • Per-epoch caps, price drift guards, and circuit breakers
• Compliance modules:
  • ERC‑3643 identity registry integration
  • EAS schemas for KYC/accreditation and per-investor caps
  • ERC‑1404 overlays for lighter regimes
• Settlement adapters:
  • USDC/CCTP v2 for seconds-level cross-chain funding
  • Optional CCIP for share-class messaging and custody-based off-exchange collateral flows

This stack mirrors what leaders are already proving in production—BUIDL’s multi-chain share classes and collateral adoption, Franklin’s regulated onchain MMF footprint, and administrators standardizing NAV feeds for composability. Fund Admin 2.0 isn’t theoretical; it’s software you can deploy this quarter. (prnewswire.com)

---

Appendix: implementation checklist

• Standards
  • ERC‑4626 for vaults; ERC‑7540 for async; ERC‑7575 if multi-asset; ERC‑7887 if cancelation needed. (eips.ethereum.org)
• Oracles
  • Pyth Feed IDs for all reference prices; Chainlink Data Standard for official NAV; UMA OO for optimistic assertions and dispute handling. (docs.pyth.network)
• Compliance
  • ERC‑3643 or ERC‑1404 per distribution model; EAS schemas and attestations wired to pre-checks. (eips.ethereum.org)
• Settlement
  • USDC as base currency, CCTP v2 for cross-chain; define cut-offs, liveness, and exception playbooks. (theblock.co)

---

7Block Labs builds and audits these patterns across EVM L1s/L2s and select alt-L1s. If you want Fund Admin 2.0 that regulators, custodians, and your CIO will all sign off on, we’re ready to help.