Building StableYield: Connecting On-Chain Vaults to Real-World Settlement

In brief

Tokenizing a real-world investment is not the same as issuing an ERC-20. The hard part is connecting on-chain ownership and controls to the eligibility, valuation, custody and settlement processes that still happen off-chain and remain subject to regulation.

StableYield is a vault-based protocol designed for that connection. It uses asynchronous settlement, records external decisions rather than making them, separates responsibilities among authorized parties, and refuses to finalize ownership or payment until the required evidence is present.

The core architecture works with today’s regulated fund processes and does not depend on the Stablecoin Act being in force. Any production deployment would still need to comply with the rules applicable to the selected fund, service providers and settlement asset.

The goal is not to pretend real-world settlement is instantaneous or trustless. It is to make the dependencies explicit, keep the workflow observable, and support regulated money-market products that can accept Canadian-dollar stablecoins.

Real-world asset tokenization is more than issuing a token

Issuing a token on the Ethereum blockchain is easy. Pick a name, a symbol and the number of decimal places, grab an ERC-20 contract template and deploy it. Start to finish, this can be done in an afternoon and you have a token available on-chain ready for minting. The most basic example is a meme token, where its value is largely in the eye of the beholder.

This isn’t the case when tokenizing real world assets or issuing stablecoins. Value comes from the rights that ownership of the token gives you in the real world. While a blockchain transaction record can tell you who holds the token it doesn’t tell you what legal rights you have and how you can enforce them in the real world.

Those factors will be totally dependent on whether your protocol has complied with real-world legal and regulatory requirements with respect to the protocol’s procedures for investor KYC/KYB, issuance and redemptions, valuation and custody. As a result, it is extremely important that these real-world constraints and requirements are reflected in the protocol’s design.

On March 26, 2026, Canada’s Stablecoin Act received Royal Assent. When brought into force, it will prohibit stablecoin issuers from paying interest or yield to holders. This means that holding QCAD, CADD or CADC will not itself generate a return. A holder seeking a money-market return must move into a separate investment product, which today may require off-ramping to fiat or converting into a US-dollar product and accepting foreign-exchange risk. I started designing StableYield to remove that friction by allowing Canadian-dollar stablecoins to be used to subscribe for tokenized money-market fund shares. The stablecoin remains the settlement rail; the return comes from the underlying fund.

In this post I would like to share how real world legal and regulatory requirements are reflected in the architecture and operational design of the StableYield protocol and how the designed on-chain ownership and controls connect to the money market fund’s regulated activities - some of which need to take place off-chain.

A tokenized investment can still be a security.

Canadian securities regulators have made clear that securities legislation can apply to token offerings and tokenized securities. Whether it applies, depends on the rights represented by the token and the complete structure of the offering - not simply the technology or terminology used.

What are tokenized vaults?

The vault standards used by StableYield

ERC-4626 defines a common interface for tokenized vaults that accept one underlying ERC-20 asset and issue shares.

ERC-7540 extends that model with asynchronous deposit and redemption requests. An investor can submit a request, wait while pricing and settlement take place, and claim the resulting shares or assets once the request becomes claimable.

StableYield uses ERC-4626 as the foundation for its tokenized vault and ERC-7540 to support deposit and redemption requests that settle asynchronously.

For readers new to DeFi and tokenization, some definitions may be useful.

Smart contract: Code compiled and deployed to a blockchain address. It can hold and transfer tokens that conform to supported Ethereum standards. Users and other contracts can call its public functions, subject to the permissions the contract enforces.

Protocol: A collection of smart contracts that together provide application-like functionality for a particular use case. Governance may be controlled by designated operators, multisignature accounts, token-holder voting or a combination of these arrangements.

Tokenization: The process of representing an asset with on-chain tokens that can be minted and burned. When the asset’s value depends on real world rights, external legal, regulatory and data requirements must still be satisfied for the token to carry that value.

There has been a lot of recent media attention around blockchain vaults. Several major infrastructure providers (Aave and Morpho) now offer products that let investors earn yield on their digital assets using vault-based smart contracts.

A simple ERC-20 token can represent ownership of a real world asset, such as a stablecoin or a security. Once a protocol needs to accept deposits, issue proportional shares, enforce eligibility, and settle investment and redemption requests that may take time to clear, a vault smart contract becomes the natural place to put that logic.

The bank vault analogy

Most people understand a physical bank vault. You sign a contract with your bank, receive a key to a safety-deposit box, and place your valuables inside. Other customers do the same with their own boxes. You cannot access their assets, and if you lose your key the bank can probably arrange a replacement.

A vault smart contract works on a similar principle, but control is exercised differently. Blockchain assets are controlled through wallets and smart contracts rather than a physical key. An investor may control a wallet directly, authorize another wallet or smart contract to act on specific assets, or use a custodian that controls the signing keys. The contract can also contain logic that programmatically invests deposited assets according to rules encoded in the code.

In practice a simple vault usually exposes three core functionalities:

1. Deposit: Accepts a specified asset, validates the amount, and issues shares representing the investor’s proportional claim on the pool.

2. Redeem: Allows the investor to return shares and receive the corresponding underlying assets, adjusted for any gains or losses.

3. Investment: Optionally deploys the pooled collateral into other on-chain assets, other vaults, or tokenized real-world assets. Any returns must come back in a form that can be converted into the original deposit asset. This is the part of the contract an investor must check most carefully against the advertised strategy and governance rules.

Where the analogy stops working

A smart contract vault is not a collection of individual safety deposit boxes. Investor assets are normally pooled; the investor receives shares that represent a proportional interest in that pool. A wallet key authorizes the investor’s on-chain instructions, but it does not necessarily give direct control over every underlying asset. In a real world asset vault the securities themselves may still be held by an external custodian, and redemptions may depend on eligibility checks, valuation and settlement processes that occur off-chain.

The architecture of an RWA vault is therefore more involved than a pure crypto-native vault. Compliance requirements, custody arrangements and delayed settlement all have to be reflected in the protocol’s design.

With that basic picture of a vault in place, the next section examines where StableYield draws the boundary between the protocol and the regulated institutions around it.

Where StableYield draws the on-chain/off-chain boundary

Recording a decision is not the same as making it.

StableYield protocol does not independently perform KYC, calculate the fund’s NAV, or inspect assets held at a custodian. Authorized external parties perform those functions. The protocol records their attestations, verifies that they relate to the correct vault and settlement cycle, and prevents the workflow from proceeding until the required evidence is present.

StableYield is meant to let an on-chain investor earn a money-market style return without pretending that compliance and settlement can be performed entirely by smart contracts. The protocol moves selected parts of the control, accounting and record-keeping workflow onto the blockchain. It does not take over the underlying functions performed by the fund manager, administrator, transfer agent, custodian or bank.

Once submitted, an investor request becomes an observable object with a recorded status. The protocol records share issuance and redemption, role-based permissions, approved eligibility and valuation decisions, and the existence of settlement or custody attestations. It can then prevent ownership or payment from being finalized until the required conditions are satisfied.

Identity documents, legal agreements, portfolio management, asset purchases, banking and custody remain outside the protocol. StableYield connects the institutions responsible for those activities to the workflow that records and enforces their decisions. Each authorized party can supply only the information or take the actions that fall within its responsibility, so no single party should control every input required to complete settlement.

Investor identification and compliance

A smart contract can see which wallet is interacting with a vault, but it cannot determine who controls that wallet, where the person or entity is resident, whether they are subject to sanctions, or whether they meet the eligibility rules of a particular product.

KYC, KYB and related compliance reviews therefore remain off-chain. Once those reviews are complete, an authorized party records the resulting eligibility decision so the protocol can enforce it. The protocol itself does not prescribe a single compliance standard. Different issuers may apply different requirements.

The vault never needs the underlying personal information. It only needs a reliable answer to the question of whether a given wallet is permitted to interact with the product. In that sense the compliance process functions as an oracle: it takes real-world decisions and supplies the protocol with a result it can act on.

Fund management, valuation and asset purchases

The choice of which assets the fund should hold remains with the real world fund manager. StableYield does not select investments, run a portfolio strategy, or decide whether any particular security is suitable.

Valuation is likewise an off-chain responsibility. The fund administrator determines and approves the Net Asset Value according to the applicable accounting policies. That approved figure is then made available to the protocol so that share issuance and redemption amounts can be calculated. The protocol can check that the information comes from an authorized source, but it cannot verify every underlying input used by the administrator.

Once subscriptions have been accepted, the purchase of the underlying assets still occurs through the existing financial system. The same is true in reverse when assets must be sold to meet redemptions. The protocol’s role is limited to recording the investor’s request, applying the relevant controls, and ensuring that transaction finalization cannot occur until the necessary external evidence has been supplied.

Custody, banking and legal records

The underlying securities are held by an authorized custodian outside the blockchain. A smart contract can observe on-chain movements of stablecoins, but it cannot inspect a custodian’s books or independently confirm that the fund has received final ownership of the corresponding real world assets. StableYield therefore depends on authorized attestations that the required external steps have been completed.

Banking arrangements and stablecoin issuance also sit outside the protocol. It does not issue the settlement asset, control any issuer’s reserves, or operate the banking rails that move value between the stablecoin issuer, the fund and the custodian.

The legal rights represented by the vault shares are created by the fund’s legal structure, its offering documents and the subscription agreements signed by investors. The blockchain provides an auditable record of ownership. Whether that record is recognized as conferring those legal rights depends on the terms of those legal documents.

These dependencies are treated as explicit parts of the trust model. Because the external parties and the banking system do not operate continuously, the protocol is built around asynchronous, business-day settlement rather than the assumption that a real-world investment can always be completed inside a single blockchain transaction.

Why real world settlement is asynchronous

One of the major differences between a crypto-native DeFi transaction and an investment in a real world asset is the time required to complete the transaction.

A conventional on-chain swap can be completed atomically. The tokens are exchanged in a single blockchain transaction and either the entire transaction succeeds or none of it does. The smart contract has access to the assets being exchanged and can determine the result without waiting for a bank, custodian or fund administrator.

A real world investment does not operate in the same way. An investor may submit a request on-chain at any time, yet the underlying fund may process subscriptions and redemptions only at defined cutoff times. The NAV must still be calculated and approved, money may need to move through external settlement rails, and a custodian may need to confirm that the corresponding assets have been received or released.

These steps often span multiple systems and involve parties that do not operate continuously. It is therefore unrealistic for the vault to accept a request and immediately issue final shares at a price that has not yet been determined.

StableYield accommodates this reality through an asynchronous request and settlement process. A submitted request remains in a pending state while the necessary external conditions (eligibility, pricing and settlement evidence) are completed. Only when those conditions are satisfied does the protocol allow the request to be finalized.

If required information is delayed, missing or inconsistent, the request simply stays pending. The protocol does not finalize ownership or payment on the assumption that the external steps will eventually occur.

The pending state is intentional. It represents the period during which the real-world parts of the transaction are still being completed. Rather than issuing shares or releasing proceeds immediately and hoping settlement follows, the protocol waits until the necessary external evidence is available. This protects both sides of the transaction: stablecoins moving on-chain do not prove the fund has obtained the corresponding real-world assets, and locking or burning shares does not guarantee that the assets have been sold or that redemption proceeds have arrived.

Asynchronous settlement also gives the protocol a controlled way to respond when something does not proceed as expected. In those cases the request remains pending until the issue is resolved or the request is withdrawn under the applicable process.

Pending does not mean lost.

A pending request remains visible on-chain with an observable status. In appropriate circumstances it may be possible for the investor to withdraw the request before it has been committed to external settlement, or for a pending request to be moved to another eligible holder. Any such arrangements remain subject to eligibility rules, transfer restrictions and applicable securities laws.

Attestations: connecting StableYield to the real world

Some of the most important factual information relied upon by StableYield originates outside the blockchain. The design therefore needs to address both the integrity of that information and the availability of the external parties and systems that provide it.

StableYield connects to external processes through authorized records and attestations. These may include an investor eligibility decision, an approved NAV, or confirmation that required settlement activity has been completed.

The protocol checks that the information comes from a source authorized for that purpose and that it relates to the relevant product and period. If required information is missing, stale or inconsistent, the settlement workflow cannot proceed.

An attestation does not independently prove that the underlying real world event occurred. It records that an authorized party reported the event and accepted responsibility for that statement. StableYield can control how the statement is used, but it cannot inspect a custodian’s books or reproduce a fund administrator’s valuation process.

This is the central trust boundary. StableYield does not eliminate reliance on the fund administrator, compliance provider, custodian or settlement operator. It limits the information each party can supply, records the actions taken, and prevents settlement from advancing when the necessary evidence is absent or inconsistent.

Attestations and oracles are not the same thing.

An attestation is the statement being provided. For example, that a NAV was approved or that assets were received by a custodian. An oracle or reporting service is the mechanism used to authenticate and publish that statement on-chain.

Where the responsible institution signs the original statement, the protocol can verify its source and the oracle primarily acts as a delivery mechanism. Where the oracle transforms or signs the information itself, the protocol also depends on the oracle for the integrity of the report.

That brings us to the next question: which parties does StableYield continue to trust, what authority does each of them have, and what happens if one of them provides incorrect information?

The StableYield trust model

The term “trust model” describes the assumptions that must remain true for a system to operate correctly. In simple terms, it identifies who and what StableYield still relies on, what those parties are permitted to do, and what could happen if they fail to perform their responsibilities.

Blockchain protocols are often described as trustless, but that description does not apply neatly to real world assets. A smart contract can execute its programmed rules without relying on a person to maintain an internal ledger, yet it cannot eliminate the institutions responsible for issuing, managing, valuing and custodying the underlying investment.

So the goal is not to remove every source of trust. It is to explicitly recognize the protocol’s trust dependencies, provide role-based limits on what a participant can do and leave an observable record of how the authority gets used.

The principal trust dependencies

StableYield’s principal trust dependencies can be grouped into five categories:

Dependency	What StableYield relies on	What the protocol can do	What remains outside the protocol
Fund and legal structure	The vault shares represent valid rights in an investment operated according to its mandate	Enforce the configured issuance, redemption and transfer workflow	Create the legal rights or manage the underlying investments
Compliance and valuation	Eligibility decisions, NAV and accounting information are accurate and current	Enforce recorded decisions and restrict inputs to authorized sources	Independently identify an investor or reproduce the complete valuation process
Custody and settlement	Reported assets exist and the required external transactions have been completed	Require authorized evidence before the on-chain workflow proceeds	Inspect a custodian’s books or force a bank, issuer or custodian to complete a transaction
Technology and infrastructure	The blockchain, smart contracts, oracle and reporting infrastructure, and any protocol-provided wallet or access services operate correctly and remain available	Enforce permissions, validate configured reports, protect settlement accounting and record governed actions	Eliminate contract defects, compromised keys, provider outages, integration failures or blockchain disruption
Governance and administration	Authorized roles, configuration changes, upgrades and emergency actions are exercised appropriately	Restrict actions to configured roles and record changes on-chain	Prevent every instance of key compromise, operator collusion or misuse of legitimately granted authority

The wallet dependency will depend on the final access model. If investors use their own non-custodial wallets, StableYield does not control their private keys or recovery process. If a production pilot uses embedded wallets, account recovery or managed signing infrastructure, those services become additional technology and trust dependencies.

StableYield also relies on the parties and systems involved remaining available. A fund administrator may publish information late, a custodian may delay confirmation or a payment may be interrupted. In those circumstances, the protocol can prevent an incomplete settlement from being finalized, but it cannot force an external institution to complete its work. The design therefore prefers delayed settlement over settlement without the required evidence, while investors remain exposed to operational delays involving the fund and its service providers.

Technical trust and legal accountability

Not every trust dependency can be addressed through smart contract code. Where StableYield relies on external parties such as a fund administrator, custodian, compliance provider or settlement operator, the production operating model can also rest on real world legal agreements.

Those agreements can set out the responsibilities of each party, the expected standard of care, timing and evidence requirements, and the consequences of providing incorrect information or failing to perform. This changes the nature of the reliance: even if the protocol cannot independently verify every entry in a custodian’s books, the service provider can be contractually accountable for the accuracy of its reports and subject to audit rights and agreed remedies.

The StableYield trust model therefore combines the technical controls enforced by the protocol with the legal and operational framework that surrounds the parties providing critical real world services.

What moving the workflow on-chain changes

Moving these controls on-chain does not guarantee that every participant will behave correctly. It changes the way their authority is exercised.

Actions can be limited to specific roles, required to follow a defined order, and recorded in a form that investors, operators and auditors can observe. Missing or inconsistent information can stop the settlement process before ownership or payment is finalized. This reduces reliance on private records and the risk of proceeding on incomplete evidence, although it does not remove the underlying operational or counterparty risk.

Trust is restricted, not eliminated.

StableYield can restrict who is permitted to provide an input, what that input can affect, and when it can be used. It cannot independently guarantee that every real world statement is accurate or that every external party will remain available.

The remaining question is how the protocol protects these roles, investor assets and settlement processes from unauthorized actions, operational failures and errors. That is the subject of the security and governance protections that follow.

Security and operational protections

Security for a real-world asset protocol cannot be treated solely as a smart-contract problem. The contracts may operate exactly as intended while an external administrator supplies an incorrect NAV, a custodian fails to complete settlement, or an authorized signing key is compromised.

StableYield therefore relies on several layers of protection. The protocol restricts what can happen on-chain. The governance and operating model control who is authorized to act. Legal agreements and insurance can provide additional protection where the protocol depends on external service providers.

None of these protections removes risk completely. The objective is to prevent a single error or unauthorized action from silently progressing through the system and becoming a finalized investor loss.

Current implementation status

StableYield’s current demonstration implements and tests the core on-chain workflow. It uses simulated assets and reporting sources and does not represent a live integration with a fund administrator, custodian, compliance provider or stablecoin issuer.

Protocol safeguards

Responsibility for different parts of the workflow is deliberately separated. Each role is intended to hold only the authority required for its function. This works only if the separation is also reflected in the operating model. Assigning multiple critical roles to the same person, organization or key reduces the protection.

The protocol records changes in authority and maintains accounting controls that prevent a request from being finalized unless the necessary on-chain assets and external evidence are present. External information must come from a source authorized for the relevant purpose. If required information is missing, stale or inconsistent, the affected process is stopped. The protocol does not silently fall back to older data or proceed on incomplete evidence.

A stopped settlement cycle is a protection.

A circuit breaker may delay a subscription or redemption, but completing settlement with inconsistent valuation or custody information would create a more serious risk. Preserving the request and requiring correction or review is preferable to forcing the transaction through.

Authorized parties can pause affected activity if a protocol-level incident is detected. The appropriate recovery path depends on how far the affected requests have progressed and whether any external transaction has already been initiated.

Pausing is only one element of incident response. The operating model must also define who investigates, how compromised authority is removed, and what review is required before normal operations resume. Some contracts are designed to be upgradable so that defects can be corrected and the protocol can adapt to regulatory or operational change. Upgradability introduces a governance dependency; material changes should therefore require appropriate authorization and review.

Requirements for production use

Production use will be partner-dependent. Integrations will need to reflect the approved processes of the selected fund manager and service providers. The final operating model will also need appropriate governance, key management and incident-response procedures.

Development includes automated testing of the core investor and settlement workflows, access controls and failure-handling paths. Automated testing alone does not prove the absence of defects. Before production use, the contracts, configuration and operational assumptions should receive independent review by an experienced security firm. Material later changes should be assessed to determine whether further review is required.

The live system should be monitored for significant administrative actions, delayed or inconsistent external information, and interruptions to settlement. Monitoring is useful only when it is connected to a documented response process and people who can act.

Smart-contract controls cannot compel an external service provider to perform its real-world duties correctly. Those relationships need due diligence, contractual agreements and ongoing oversight. Agreements can define responsibilities, evidence and timing requirements, audit rights, incident-notification duties, continuity arrangements and the consequences of failure. Insurance may provide an additional financial layer for some losses, subject to its limits, exclusions and conditions. Neither contracts nor insurance make failure impossible or guarantee recovery.

Remaining risks

Even with the protections described above, StableYield cannot eliminate every risk that accompanies a real-world investment. Investors continue to rely on the fund’s legal structure, the underlying assets, the fund manager, administrator, custodian, settlement asset, blockchain and smart contracts.

The purpose of the security model is to make those dependencies visible, to restrict how authority is exercised, and to prevent missing or inconsistent evidence from being used to finalize settlement without review. This does not make the investment risk-free. It provides a more controlled and auditable connection between on-chain investor ownership and the institutions responsible for the underlying real-world asset.

Potential benefits of this architecture

The benefit of StableYield is not simply that fund shares can be represented on a blockchain. The protocol can provide a common operating layer between investors, fund managers, administrators, custodians, compliance providers and stablecoin settlement rails. It is designed to work with regulated investment products as they operate today while allowing more of the underlying assets, custody and settlement processes to move on-chain over time.

Supporting existing regulated workflows

StableYield does not assume that securities regulation, fund administration, banking or custody will be redesigned around blockchain technology. It can accept investor instructions on-chain while respecting the fund’s existing eligibility rules, dealing cut-offs, NAV process, custody arrangements and settlement timetable. The specific fund structure, distribution model and regulatory requirements will still need to be established with the relevant partners and legal advisers. The protocol provides a workflow through which external decisions can be recorded and configured on-chain rules can be enforced.

A modular approach to external data

The core vault and settlement logic is separated from the systems that supply compliance, valuation, custody and settlement information. This allows an approved service provider to continue using its own internal processes while delivering the result the protocol needs. Partner-specific integrations can change without replacing the underlying request and settlement lifecycle, although every new integration still requires technical assessment, testing and appropriate governance approval.

More consistent operating records and continuous access

Traditional fund operations often record the same subscription or redemption in several systems. A shared on-chain record can give investors, operators and auditors a common view of the request and its status. The protocol can also require that specified conditions are satisfied before the request advances. This may reduce inconsistent or out-of-sequence processing, but the benefit will depend on real integration with the fund’s books and service providers. Placing an additional record on-chain does not by itself eliminate reconciliation.

Investors can submit instructions without being limited to the operating hours of a traditional portal. Requests can be collected continuously and assigned to the appropriate business-day settlement cycle. The fund can still maintain its approved NAV process, dealing cut-offs and liquidity controls. Continuous access does not mean immediate liquidity or settlement; it gives investors clearer visibility while the required real-world work is completed.

Potential rather than guaranteed benefits

These advantages are not automatic consequences of using a blockchain. Reduced reconciliation depends on integration with the administrator, custodian and settlement rails. More continuous processing depends on those parties remaining available. Broader access continues to depend on securities law, distribution arrangements and investor eligibility.

The central benefit is flexibility. StableYield can support a model in which investor ownership and workflow controls are on-chain while the underlying assets remain externally administered and held in custody. It also leaves a practical path toward a future in which more of the investment and settlement process occurs directly on-chain.

Demo: following one investment lifecycle

The accompanying short demonstration follows an investor from eligibility and submission of a subscription through the pending settlement period to the receipt of vault shares and shows the information available to the investor and fund manager while each request is being processed.

The demonstration uses simulated assets and reporting sources. Its purpose is to show how the parts of the workflow connect; it is not presented as a production fund or a completed integration with external service providers.

Partnership invitation

StableYield is being developed as infrastructure connecting programmable vault ownership with the compliance, valuation, custody and settlement processes required by real world investment products.

We are interested in working with asset managers and issuers, fund administrators, custodians, compliance and attestation providers, stablecoin issuers and distribution partners to validate these workflows and define the requirements for a production pilot.