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

In 2025, tokenized funds really made the leap from being just experiments to full-on production. BlackRock’s BUIDL is now working across various chains and is being recognized as institutional collateral. Meanwhile, Franklin Templeton’s BENJI is showing that regulated money market funds can exist right on public ledgers without a hitch. So now, the big question isn’t “if” we can make it happen, but rather “how” to smoothly handle fund administration directly in contracts--safely, transparently, and in a way that works well with others. (prnewswire.com)

---

Who should read this

• Asset managers are rolling out tokenized money market funds, credit funds, interval funds, or multi-asset strategies.
• Corporate treasurers are on the lookout for on-chain liquidity with T+0 settlement.
• Product and engineering leaders are taking a hard look at whether to build or buy for fund operations.

---

The design goal: operational certainty onchain

Fund Admin 2.0

Fund Admin 2.0 revolves around two key promises that smart contracts can deliver more effectively than traditional spreadsheets:

• Price certainty: The NAV is calculated and verified consistently every day, using clear inputs and a secure, tamper-proof trail.
• Flow certainty: When it comes to subscriptions and redemptions, they’re either handled all at once or clearly timed apart, with a trackable process and reliable settlement times.

Here’s a closer look at the reference architecture and the implementation details we provide to our clients.

---

Core building blocks

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

• Go ahead and use ERC‑4626 for share accounting (you know, the whole assets↔shares conversion thing). It'll help exchanges, custodians, and all those DeFi legos to jump on board from day one. It's basically the go-to standard for tokenized vaults. Check it out here: (eips.ethereum.org).
• Keep in mind that real-world assets usually don’t settle right away. So, it’s a great idea to implement ERC‑7540 for handling those asynchronous subscriptions and redemptions (you know, requests that’ll be claimable later). This is super important for T+1 bond settlements, bank wires, or any cut-off processing you might need. Learn more about it here: (eips.ethereum.org).
• Lastly, if your fund is open to multiple deposit assets (like USDC, USDT, or EURC) or has different entry points, don’t forget to add ERC‑7575 (the multi-asset extension). It keeps things simple by maintaining one share token across various asset adapters. Dive into the details here: (eips.ethereum.org).

Practical Notes

• Make sure to add preview functions and per-epoch limits on ERC‑4626. For async paths, stick to ERC‑7540's guideline that previewDeposit/previewMint should revert. Remember that once Requests become claimable, you need to follow the standard deposit/mint/redeem/withdraw rules. Check it out here.
• If your investors might need to cancel any pending Requests--like in a situation where the market temporarily halts--consider looking into ERC‑7887 for cancellation options. More details can be found here.

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

Why Reliable NAV Onchain Matters

When it comes to fund tokens, having a solid on-chain Net Asset Value (NAV) is what really sets them apart from being just a bearer IOU. To navigate this effectively, we suggest using a tiered approach:

1. Basic Tier: Start with getting a clear and accurate NAV on-chain. This builds the foundation of trust and transparency for your token.
2. Intermediate Tier: Enhance visibility by using oracles to fetch real-time data, ensuring that your NAV reflects the latest market conditions.
3. Advanced Tier: Go a step further and implement automated auditing processes. This can help maintain accuracy and keep everything in check, adding another layer of reliability.

By following this tiered strategy, you can ensure that your fund token truly delivers on its promises and stands out in the market!

• First-party market data: Check out the Pyth Core/Pro feeds for getting reference asset pricing on things like USTs, repo, and FX. They’ve got clear Feed IDs and a reliable update schedule. A lot of funds find the Hermes-powered updates super handy, especially with that pull-oracle setup, since you can batch multiple feeds in one transaction. Plus, Pyth offers direct NAV feeds (like Apollo credit NAV), proving that this approach is tried and true. (docs.pyth.network)
• Institutional data standardization: You can’t go wrong with Chainlink’s Data Standard (ODP), which has got your back with NAV/PoR “SmartData” along with price feeds and streams. This is particularly great when your administrator or custodian needs to publish the official end-of-day NAV complete with signed proofs. (docs.chain.link)
• Optimistic verification: If you’re dealing with complex NAVs (like private credit marks or level-3 inputs), check out UMA’s Optimistic Oracle. Here’s how it works: the admin claims the NAV, then there’s a configurable time window for disputes, and if someone raises a challenge, UMA’s DVM steps in to arbitrate. It’s pretty popular, with typical waiting times ranging from 2 hours to 2 days, and if it gets escalated, DVM resolution usually takes about 2 to 4 days. (docs.uma.xyz)

Operational Safeguards We Use:

• NAV Medianization: We take data from a couple of different sources (like two different administrators and a custodian) and only publish the NAV when we have a certain number of matching signatures.
• Circuit Breakers: If the NAV strays too far beyond X basis points from a time-weighted average price (TWAP) of our reference assets, or if one of our data sources stops working, we hit pause on claims.
• Sequencing: We put out a preliminary intraday iNAV to give a sense of flows, and then we wrap things up with a finalized end-of-day NAV after the cutoff.

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

• Default subscription currency: USDC--it's fully reserved and super well-integrated with custody options and on/off-ramps. Plus, it's natively issued on lots of chains and supports CCTP v2 for lightning-fast cross-chain settlements. This really helps cut down on those annoying “wrong chain” mix-ups and makes onboarding a whole lot smoother. Check it out on (circle.com).
• If you’re looking to distribute across different ecosystems or use it on a specific chain, think about deploying extra share classes instead of relying on bridges. BlackRock’s BUIDL did just that by rolling out new share classes across various blockchains. This method really minimizes the risk that comes with canonical bridges. You can read more about it here: (prnewswire.com).
• Now, if you absolutely have to bridge shares or settlement assets, it’s best to go for bank-grade interoperability--think Chainlink CCIP with solid audited risk controls. Also, using off-exchange collateral models can help you steer clear of hot-wallet risks. Recent examples of production usage and custody-integrated collateralization really show where things are heading. More info here: (chain.link).

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

• Token-layer controls: If you’re working with permissioned funds, check out ERC‑3643 (T‑REX). This ERC‑20-compatible standard makes sure everything’s in check with identity registry verifications, transfer pre-checks, freezing/pausing options, and lets agents control forced transfers and recoveries. It’s basically the gold standard for a “regulated RWA” token interface. (eips.ethereum.org)
• Lightweight restrictions: Looking for some straightforward limits? Whether it’s holder counts, lockups, or whitelists, ERC‑1404 is a sleek, minimalist option that can do the trick without needing a full identity registry. (github.com)
• Attestation backbone: For anchoring KYC/KYB/accreditation attestations on-chain, EAS has you covered. It operates seamlessly across major L1/L2s, allows for custom schemas, and has already handled millions of attestations--perfect for “prove-eligible” gating while keeping your personal info under wraps. (attest.org)

---

What leading funds are signaling (and what to copy)

• Multi-chain distribution and the use of collateral are really taking off. BUIDL’s growth across different chains and its role as off-exchange collateral on top-tier platforms show that fund tokens can become essential market building blocks--assuming price discovery and compliance are on point. (prnewswire.com)
• It’s pretty cool to see regulated money funds working on public chains: Franklin’s BENJI operates under the 1940 Act, boasting one on-chain token for every fund share. This proves that strict compliance can go hand in hand with public blockchains. (news.franklinresources.com)
• Administrators are getting on the same page with oracle inputs: Securitize has picked RedStone as the go-to oracle for major issuers, hinting at a future where NAV and fund data are easy for machines to process and integrate. (theblock.co)

---

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

A) Subscription (USDC into shares)

1. Pre-trade checks

• The investor kicks things off by submitting EAS attestations, which include KYC, accreditation, and jurisdiction info. Then, the contract takes a look and runs “isEligible()” against the current policy. For those permissioned funds, it also runs the ERC‑3643 canTransfer checks when minting. (eips.ethereum.org)

2) Price Context

• Contract queries reference prices like UST bills and FX through Pyth using Feed IDs. It checks if the prices are fresh (you know, under 90 seconds old) and then takes a snapshot of the iNAV. If there's an official NAV from the administrator (like the Chainlink Data Standard "NAV"), that takes precedence during the subscription cut-off. If not, we stick with the iNAV for indicative allotment. You can find more details in the docs at Pyth Network.

3) Funds-in

• An investor sends USDC to the vault adapter on chain X. If the treasury team needs to operate on chain Y, kick off the CCTP v2 migration (which wraps up in just seconds) with a cap per request and an on-chain receipt. After that, make sure to emit FundsReceived(requestId, amount, chainSrc, chainDst). You can check out more details here.

4) Request Lifecycle (ERC-7540)

• The contract keeps track of requestDeposit(investor, assets) and marks it as Pending.
• When it hits the cut-off time (like 16:00 UTC), the admin steps in to publish the NAV. If everything looks good, they'll assert the NAV via UMA, allowing for a 6-hour window for any disputes. If no one challenges it, they finalize it; but if there are disputes, claims will be on hold until the DVM sorts things out, which usually takes about 2 to 4 days. (docs.uma.xyz)
• Once it's Claimable, the investor can hit up deposit() to mint shares based on the finalized NAV. Plus, the contract might even take care of calling deposit() automatically in a batch job to make things easier for everyone.

Controls We’re Implementing:

• Anti-Front-Running: We’re setting up some protective measures for each investor. This means we’ll have minimum and median price guardrails in place. If the mid-price changes by more than X basis points since the request, we’ll reject it.
• Liquidity Gates: We’ll introduce a hard cap for each epoch and some "soft cliffs" to help manage those portfolio transition costs. It’s all about keeping things smooth and secure.
• Cancellation (Optional): If any requests are still hanging around in Pending status beyond the SLA, you’ll be able to use ERC‑7887 to cancel and get your assets back. Check it out here: (eips.ethereum.org).

B) Redemption (shares into USDC)

1. Request and lock

• The investor calls requestRedeem(shares). At this point, the shares get locked, and the status changes to Pending. If you're using ERC‑3643, just make sure that any freezes don't prevent redemptions from going through, except for those required by regulations.

2) Portfolio Settlement

• The fund manager pulls in some cash offchain (through repo unwind or selling T-bills). In the meantime, the contract:
  • Keeps an eye on reference prices using Pyth and pauses claims if the deviation exceeds the circuit threshold.
  • Takes an official NAV or cash price from Chainlink Data Standard once settlement details are clear. (docs.chain.link)

3) Claim and Payout

• When it's time to claim, the redeem() function will burn shares and hand out USDC. If the investor opted for a cross-chain payout, just use CCTP v2 along with on-chain proofs and keep a daily limit per address in mind.

4) Partial Fills and Gates

• Set up pro-rata partial claims, like 30% today and 70% at T+1, while ensuring 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 has the flexibility to work with Pyth (which pulls updates), Chainlink (which pushes updates through a DON), or UMA (using optimistic assertions).
• Every pricing read makes sure to enforce staleness and drift limits.
• For the claim functions, they require finalized == true after the cut-off unless your strategy permits intraday claims.

---

NAV pipeline patterns (what actually runs in production)

1. Pull-oracle NAV (reference-backed)

• Grab prices from Pyth for all reference assets at the end of the day snapshot; then, aggregate the NAV on-chain in a single transaction. Store it as (navPS, version, timestamp). With feed IDs and Hermes updates, it’s easy to repeat this process. Check out more details in the docs.pyth.network.

2) Push-oracle NAV (administrator-of-record)

• The fund administrator gives the thumbs up to the NAV offchain, and then a decentralized oracle network (like Chainlink) gets the job done by posting that value to NavOracle.finalize(). We’re also introducing some multi-signer requirements and a PoR-style checksum for the holdings file. Check out more details here.

3) Optimistic NAV (complex marks)

• Admin confirms NAV using UMA’s OO, which has a liveness of 6-12 hours. If no one challenges it, it automatically finalizes. We suggest tying bonding rules to the TVL and having emergency stops ready if there’s a sudden uptick in disputes. Check out more details here.

Best practice:

• Always share both the iNAV (indicative) and the official NAV; just a heads-up, only the official NAV can unlock Claims.
• Make sure to generate a hash of the holdings report and materiality thresholds--trust me, auditors appreciate this.
• Have a "last-good NAV" fallback ready so you can manage redemptions smoothly if the feeds go down.

---

Compliance and identity: two proven blueprints

• Full-permissioned: The ERC‑3643 share token along with an Identity Registry and EAS attestations as claims in the registry (like “KYC‑OK,” “Professional Investor,” “US‑QIB”) make this system robust. Before any transfer, the canTransfer() checks are in place to guarantee that every transaction sticks to the guidelines. Plus, the Agent role has the power to carry out forced transfers when needed for regulatory purposes. (eips.ethereum.org)
• Light-permissioned: Think of the ERC‑4626 share token combined with ERC‑1404 overlays--perfect for straightforward whitelists, lockups, and holder caps. The EAS handles eligibility proofs, but keep in mind, there’s no complete identity registry in the mix. This setup works great for LP-only or employee funds that have a limited distribution but still need that onchain enforcement and logging. (github.com)

---

Interop and distribution: share classes, not bridges

• It's better to go for discrete on-chain share classes (like Mainnet, BNB Chain, Aptos, Optimism) instead of just bridging one single token. This is how BUIDL managed to broaden its distribution while keeping things clear in terms of compliance and updates on Net Asset Value (NAV) for each chain. If you're looking for cross-chain liquidity, you can connect them at the admin layer using CCIP or custody-based collateral models. (prnewswire.com)

---

Audit hotspots we flag early

• ERC‑7540 State Machine: Think of it as moving through stages: Pending → Claimable → Claimed. It's got built-in replay protection and ensures that request IDs are unique. Check it out here: (eips.ethereum.org)
• Staleness/Heartbeat: When you're accepting NAV, make sure to keep an eye on those source heartbeats. If any Feed ID is stale beyond what's allowed in the policy, just reject it. The Pyth docs lay out specific heartbeat and deviation parameters for each chain, so be sure to take a look: (dev-forum.pyth.network)
• Oracle Bonds and Liveness (Optimistic NAV): You’ll want to set these up based on Total Value Locked (TVL). Also, don’t forget to document your escalation paths and timelocks so everyone knows what to do. More details can be found here: (docs.uma.xyz)
• ERC‑3643 Agent Powers: It's important to log any forced actions and keep admin keys separate from operations keys. Make sure to map them to SOC2 controls as well. You can read more about it here: (eips.ethereum.org)

---

KPIs and ops dashboards that matter

• Oracle health: We're keeping an eye on things like staleness, deviation, dispute rate (UMA), signer availability (thanks, Chainlink DON!), and how well different asset classes are covered. Check out more details here.
• Cut-off SLA: This looks at the time from cut-off to when the NAV finalization happens and the percentage of requests that get claimed within that target window.
• Liquidity gates: Here, we’re looking at the percentage of requests that are partially filled and the average number of tranches for each redemption.
• Compliance posture: We’ll assess how fresh the attestations are (EAS), the number of failed canTransfer() attempts, and how they’re distributed across different jurisdictions. For more information, head over to attest.org.

---

What we’re shipping at 7Block Labs

• Check out our ERC‑4626/7540 vault kit, which comes packed with:
  • Async Requests, partial fills, and cancelation hooks to keep things smooth
  • A versatile INavOracle that's pluggable with options like Pyth, Chainlink, and UMA
  • Features like per-epoch caps, price drift guards, and circuit breakers to keep everything in check
• We’ve got some cool compliance modules too:
  • Integration with the ERC‑3643 identity registry for easy management
  • EAS schemas to handle KYC/accreditation and per-investor caps
  • ERC‑1404 overlays for those looking for lighter compliance regimes
• And don’t forget about our settlement adapters:
  • USDC/CCTP v2 for super speedy cross-chain funding in just seconds
  • An optional CCIP to handle share-class messaging and custody-based off-exchange collateral flows

This stack reflects what leaders are already demonstrating in the real world. We’ve got BUIDL’s multi-chain share classes and collateral adoption, Franklin stepping up with its regulated on-chain MMF footprint, and admins working on standardizing NAV feeds for better composability. Fund Admin 2.0 isn’t just a concept; it’s actual software you can roll out this quarter. (prnewswire.com)

---

Appendix: implementation checklist

• Standards
  • For vaults, check out ERC‑4626; if you're dealing with async operations, look at ERC‑7540; for multi-asset support, go with ERC‑7575; and if you need cancellation options, then ERC‑7887 is your friend. (eips.ethereum.org)
• Oracles
  • Use Pyth Feed IDs for all your reference prices, and make sure to follow the Chainlink Data Standard for the official NAV. For optimistic assertions and handling disputes, UMA OO has got you covered. (docs.pyth.network)
• Compliance
  • Depending on your distribution model, consider ERC‑3643 or ERC‑1404; also, make sure to wire EAS schemas and attestations into your pre-checks. (eips.ethereum.org)
• Settlement
  • Stick with USDC as your base currency, and for cross-chain transactions, CCTP v2 is the way to go; don't forget to outline cut-offs, establish liveness, and create those exception playbooks. (theblock.co)

---

7Block Labs is all about creating and checking these patterns on EVM L1s/L2s and a few chosen alt-L1s. If you're looking for Fund Admin 2.0 that will earn approval from regulators, custodians, and your CIO, we’re here to lend a hand.