Proposals/canton-foundation/canton-dev-fund/#99GitHub ↗

Declined#99 Pull request

Proposal: Curated Lending on Canton

Opened 17-03-2026 by Kelmat-ai, last activity 13d ago

Incoming99 days19-03-2026
In Review12 days26-06-2026
Ready for Vote1.3 days08-07-2026
Voting Live09-07-2026
Declineddate not recorded

Funding request: 1,266,665 CC
Champion named in file: Gabi Tuinaite, Bitsafe
Discussion: 22 messages; 6 people

Development Fund Proposal Submission

Proposal file:
/proposals/mystic.md

Summary

Mystic proposes to build a) an open-source vault standard and b) a curated lending market on Canton, which enables curators to create isolated lending vaults which allocate capital according to their risk preferences. This means isolated risk exposure for LPs and increased capital efficiency for borrowers, all under the privacy-preserving stack of Canton.

Checklist

Proposal file added under /proposals/
Milestones and funding amounts defined
Acceptance criteria included
Alignment with Canton priorities described

Notes for Reviewers

Champion: @gabitu7 (Bitsafe)
We're pretty much ready with the protocol's milestone 1. Audits (and thus, this proposal) are about to become our main blocker from going to market on Canton.

Milestones 3

Markets
Vaults
Mainnet Launch and Ecosystem Adoption3 months from completing Milestone 2

Discussion14 comments, 0 reviews, 8 inline comments

Showing automated messages too. Hide bot messages

Showing 1 to 23 of 23, oldest first.

Kelmat-aicontributorcommented04-05-2026 · 5mo agoGitHub ↗

AMMENDMENT TO PROPOSAL:

PROBLEM: As we're wrapping up development of our protocol's markets layer, we've begun focusing on the development of curated vaults on Canton. That's when we've realized that there is no standard CIP yet for vaults on Canton, similar to the ERC-4626 standard on the EVM. We've asked around and are seeing multiple players in the ecosystem working on their own version of ERC-4626-equivalent vaults at the same time, meaning the chain will have multiple vault standards in production. We are about to do the same thing, as we need vaults for our protocol. This will be very detrimental for Canton, as protocols will need to conform to many standards and implement their own adapters for each one, making it difficult for projects to integrate and collaborate with each other if they don't have a common vault standard to follow.

SOLUTION: As such, we hereby would like to ammend this proposal to add that we will, as part of this proposal, present a CIP proposing an open standard for ERC-4626-equivalent vaults on Canton, which can be used by anyone. This will highly benefit the ecosystem and prevent the fragmentation we're currently seeing that will be really negative for DeFi on Canton.

IMPLEMENTATION MECHANICS: What we're proposing is a uniform Daml interface that accepts a single CIP-0056 token as deposit and issues another CIP-0056 token as vault share. Redemptions are processed by burning vault shares and, in exchange, give users their initial deposit assets. The implementation we have in mind features 16 methods on a VaultFactory interface, modeled after the ERC-4626 standard. They are:

4 core methods - Vault_Deposit, Vault_Mint, Vault_Withdraw, Vault_Redeem. These change the state of the vault and add/subtract from existing assets.
4 "max" methods - Vault_MaxDeposit, Vault_MaxMint, Vault_MaxWithdraw, Vault_MaxRedeem. These check vault caps on every method being executed.
4 preview methods - Vault_PreviewDeposit, Vault_PreviewMint, Vault_PreviewWithdraw, Vault_PreviewRedeem. These allow the user to simulate the outcome of the method they are about execute.
2 oracle methods - Vault_ConvertToShares, Vault_ConvertToAssets. These price the exchange of vault shares to assets provided.
2 read methods - UnderLyingAssets and TotalAssets. These let others read vault-specific information. We assume every vault deployer will create an API that enables external parties to not only read information, but exercise the above methods when allowed to. This will enable parties that otherwise don't have visibility over the vault's contracts to interact with it. We will submit a template for this API also.

MOTIVATION: Ultimately, a thriving DeFi ecosystem lives on modularity and interoperability. Having multiple vault standards will seriously hinder both of these, introduce a lot of confusion and ultimately hurt the growth of the ecosystem. As someone that needs this CIP to exist and would have liked to have one now, we don't want to see this happen. As such, we instead propose we build one instead so that future developers don't face the same blocker.

RATIONALE: Mystic has to build curated lending vaults as part of doing curated lending on Canton. Meaning we will build part of this ourselves with or without doing the CIP. As such, we're in the perfect position to take this on, as it will represent less added work for us than anyone else in the ecosystem. In addition, we know exactly what a developer building a vault-related product would need to see in a CIP for it to be helpful for them, much like we're in contact with the other parties doing their own vault standards and can thus align on something that is good for everyone. We are thus in the "right place, right time" to be doing this vault standard.

FINAL NOTES:

Please assume that the vault standard will be delivered and the corresponding CIP submitted as part of our first Milestone. Submitting the CIP can be an added acceptance criteria for the first milestone, should you accept this.
This is an add-on to the existing proposition, and we propose we do it in tandem with it.

We hope you will consider this and we reiterate the need for this standard for the DeFi ecosystem, as we're already seeing multiple people that would benefit from this and will only see more over time. CC'ing you in case you had already seen the initial proposal @hythloda @tkatrichenko @stas-sbi @waynecollier-da @isegall-da. Thanks!

waynecollier-dacontributorcommented04-05-2026 · 5mo agoGitHub ↗

It seems reasonable to add a CIP proposal for ERC-4626-comparable vaults. I'd encourage you to do that. It also strengthens your proposal, since it allows you to create some OSS artifacts for the community. And you might want to include an OSS reference implementation of that vault standard as part of your scope.

For the rest of the scope, I'd encourage you to more clearly call out the audits in your milestones and payment schedule: when will they be performed, what scope will they cover, and how the audit firm(s) will be paid (by you? by the Foundation directly via a rewards coupon?)

Kelmat-aicontributorcommented05-05-2026 · 5mo agoGitHub ↗

Thanks for the quick response @waynecollier-da , we appreciate the feedback.

We've gone ahead and done as you suggested: edited the proposal so it includes an Open-Source reference implementation as a deliverable, alongside the CIP proposal.

We've also simplified the proposed development project (we have more experience with DAML now and know better what the work involved for each Milestone is). In addition, also as you have suggested, we have introduced audit timelines, scopes and payment details. We've even added the auditors we'd like to work with. Hope all is clear, thanks again for reviewing.

VinyoDAinline comment on proposals/mystic.md:9417-07-2026 · 3mo agoGitHub ↗

What about ERC-7540?

VinyoDAinline comment on proposals/mystic.md:6317-07-2026 · 3mo agoGitHub ↗

Clear indication on what's going to be OSS and what is going to remain proprietary with Mystic.

VinyoDAinline comment on proposals/mystic.md:5617-07-2026 · 3mo agoGitHub ↗

Would be great to take token standard v2 into consideration already.

VinyoDAinline comment on proposals/mystic.md:17017-07-2026 · 3mo agoGitHub ↗

What about maintenance and code ownership?

Kelmat-aicontributorinline comment on proposals/mystic.md:9421-07-2026 · 3mo agoGitHub ↗

We wont use ERC-7540-equivalent logic on our lending market, nor is it part of canonical ERC-4626 on the EVM, so we weren't thinking of adding that to the OSS CIP either. That said, 100% it's crucial for stuff like strategy vaults to be possible, much like issuers will benefit of it.

Given how 112 already supports the 7540 behaviour up to a certain extent, a good way forward here could be adding that to the vault standard as an optional feature

Kelmat-aicontributorinline comment on proposals/mystic.md:6321-07-2026 · 3mo agoGitHub ↗

Good shout, I've added that in there under "Maintenance & Ownership".

In essence: vault standard is OSS, lending market layer and curated lending vault are proprietary.

Kelmat-aicontributorinline comment on proposals/mystic.md:5621-07-2026 · 3mo agoGitHub ↗

Yeah, 100%. It wasn't approved yet when we wrote this, but we're right on time to build the vault OSS standard on top of 112 straight away now. They'll go great together I think

Kelmat-aicontributorinline comment on proposals/mystic.md:17021-07-2026 · 3mo agoGitHub ↗

Yeah we neglected that bit in the proposal, sorry. Adding that under the same section we mentioned above, "Maintenance & Ownership".

TLDR we'll commit to actively maintain it for a minimum of 12 months after the end of milestone 2, funded by protocol operations. We won't request any funding for maintenance. Vault standard code will remain under MIT license so anyone can use it, Mystic code will not.

Thanks for all the questions @VinyoDA, appreciate you reading everything and going through the application!

Noosphere-314commented22-07-2026 · 3mo agoGitHub ↗

Hi Mystic team! I`m Mykola Ilchuk, Head of R&D, Woof. We're preparing two Canton Dev Fund proposals, and Mystic's curated lending markets are exactly the kind of protocol they're built for.

The main one is a Canton Risk Engine: open-source on-chain risk parameter management - a registry with governance + timelock, an off-chain simulator, and a public risk dashboard. Today every lending team on Canton has to build collateral-factor / cap / liquidation-threshold management from scratch; we're making that a shared public good, free to use.

I'll be straight about the ask and why: what actually moves proposals through the committee isn't general support but named intent - a team saying "we'd use this, specifically for X." If (and only if) that's true for you after a look at the write-up, a short comment on our forum thread naming which piece you'd consume would genuinely change the picture: https://forum.canton.network/t/woof-two-dev-fund-proposals-evm-side-compliance-risk-infrastructure-for-canton-seeking-feedback-champion/8796

Second, smaller one: our Compliance Middleware SDK (EVM-side, for Zenith) handles per-party compliance gating at the application level - positions and pool access, the things instrument-level registry controls can't reach. If your markets are permissioned on the EVM side, you may be a natural consumer there too - happy to walk through it.

Either way, we'd want your input on the parameter set so it fits real lending needs - that offer stands regardless of the above.

cashenLukecontributorcommented29-07-2026 · 3mo agoGitHub ↗

We at Cashen have also been considering building a product incorporating vaults, and through our research have talked to multiple teams that are either scoping projects that use vaults, or already built production vault code. All desire a Canton vault standard for the reasons known and stated in this PR.
We believe that a collective narrow approach on vault standard requirements would yield the best result for the network. We would also look to leverage existing code from the ecosystem where possible to reduce duplicate work and increase speed to production.

Given this proposal commingles a> vault standard with b> a lending product, is there scope to narrow it to only consider the vault standard and move quickly on that so app teams can all use it to build their products on a unified foundation?

Kelmat-aicontributorcommented31-08-2026 · 1mo agoGitHub ↗

As an update on this - we are now in talks with 19+ parties building with vaults on Canton Network. We are building a working doc as a basis for the standard and running it by a tigh-knit group of close parties who will co-author the standard with us, and then a larger group that can share their insights of what the standard should look like to fit the multiple use cases being built on Canton at the moment before anything. More on this soon

Noosphere-314commented02-09-2026 · 1mo agoGitHub ↗

On the vault standard question, and the narrowing @cashenLuke raised, one observation from the EVM side that may save the CIP some scope.

ERC-4626 works as widely as it does because it standardizes accounting and share semantics only: deposit, mint, withdraw, redeem, and the conversion between assets and shares. It deliberately says nothing about risk. That omission is the reason a vault standard and a lending market with opinions about risk can coexist without one constraining the other.

In the curated-vault designs that came later, MetaMorpho-style, the curator's surface sits outside the token standard: a per-market supply cap, an allocation list the curator can reorder freely, and a timelock with a guardian veto on the changes that raise risk. Caps and the timelock are not part of the share accounting. They are a separate governed layer the vault reads from. Keeping them out of the standard is what let many curators with very different risk appetites ship on one interface.

Applied here, that suggests a split. The CIP covers accounting, share semantics, the deposit and withdrawal lifecycle, and the events an integrator needs to reconstruct vault state. Curator-set limits, the parameter surface, and the path by which a curator changes them stay outside it. A team that wants a curator with unilateral authority and a team that wants a timelock and a veto can then both conform to the same standard, which is what makes it adoptable across the ecosystem rather than only inside one protocol.

One question, since you have thought about this longer than we have: for the isolated vaults, do you expect the curator's parameter changes to take effect immediately, or do you plan a delay with an exit window for LPs? That answer tends to determine how much of the parameter surface can live inside the standard and how much has to sit next to it.

Kelmat-aicontributorcommented17-09-2026 · 1mo agoGitHub ↗

@Noosphere-314 We agree on the split, and that's our proposed design for the CIP too. The standard covers share accounting, the deposit and redemption lifecycle, and the events an integrator needs to reconstruct vault state. Valuation, strategy, fees, access and roles stay with the implementer, for the reason you give: a team that wants a curator with unilateral authority and a team that wants a timelock and a veto should both conform.

On our own implementation, we will be following Morpho curated vaults. Changes that raise risk go behind a timelock, changes that lower it take effect immediately, and the pending change is visible for the duration so an LP who doesn't like it can exit before it lands. The timelock length will be set per vault rather than fixed.

Worth saying that's an implementation choice rather than something the CIP will enforce. A vault with no timelock at all would still be conformant.

Kelmat-aicontributorcommented17-09-2026 · 1mo agoGitHub ↗

More broadly, and to keep this PR inline with CIP-100, here are the RFP's under which this proposal sits:

RFP 13 "Payments & DeFi", which specifically mentions standards for DeFi - exactly what we're doing here;
RFP 12 "RWA Standards", which openly calls for open standards around issuance and RWA workflows, which is also exactly, pretty much to a letter, what we're doing here with the introduction of a vault standard.

Think it's pretty clear we should assess this PR specifically as the introduction of the vault standard and nothing else @hythloda . Ok to keep as-is, or would you want us to introduce a new one?

Vault working doc in full flow now, we're working on it closely with @cashenLuke and the Cashen team and will soon share it for feedback with a dozen+ teams, including Obsidian , the Foundation itself and many more key players on Canton.

cashenLukecontributorcommented17-09-2026 · 1mo agoGitHub ↗

Thanks for the update to scope and plans @Kelmat-ai If acceptable for CF, I'd suggest revising this one (to focus just on the standard) to keep the comments and audit trail alive

github-actions[bot]commented22-09-2026 · 1mo agoGitHub ↗

The Canton Foundation Dev Fund is moving to Dev Fund 2.0

Thanks for making and opening a PR for your proposal. The Developer Fund is transitioning, which shifts toward RFP-scoped proposal system and clearer problem & adoption requirement framing.

Full details on Dev Fund 2.0: https://github.com/canton-foundation/canton-dev-fund/blob/main/2026-2028-strategic-roadmap.md#requests-for-proposals

To keep your proposal PR active, please update it by within the next 10 days with:

The relevant RFP category it maps to
Why the ecosystem needs it i.e. who benefits from it and how it drives adoption

Proposals not updated by then will get their PRs closed and will not be considered for the next Dev Fund cycle.

Noosphere-314commented22-09-2026 · 1mo agoGitHub ↗

@Kelmat-ai, thanks for clarifying both the CIP boundary and your implementation choices. Keeping the core compatible with different risk policies and governance models is the right call.

If it is useful, we could contribute a small set of integration review cases for implementations that do timelock parameter changes. They would sit in implementation guidance or an optional extension rather than in the core, so a vault with no timelock stays conformant.

The first case is a change whose delay has elapsed but for which no follow-up transaction has run. Implementations differ here in a way integrators feel. In our Daml prototype the effective value is derived from the scheduled activation time, so a reader that takes only the stored base value can return a limit that is no longer in force. An implementation that requires an explicit acceptance transaction behaves the other way round. Neither is wrong, but an integrator has to know which one they are reading.

The second is the notice period itself. Two things have to hold for it to do its job. The intended LP or monitoring party needs a way to obtain the pending change and its activation time, which on Canton is a question of how that information is exposed rather than something that follows automatically. And being able to request redemption is not the same as being able to complete an exit before the change lands, which depends on available liquidity and, where a vault supports asynchronous redemption, on how requests already in flight are treated. How a pending parameter change interacts with a redemption request that is already open looks like a reviewable case to us.

We have an executable Daml prototype with tests around scheduled changes, grouped parameter updates and consumer reads. It is not a deployed product, but the review cases would come from that work rather than from theory.

Could you include us in the wider feedback round you are preparing with @cashenLuke and the Cashen team?

Kelmat-aicontributorcommented28-09-2026 · 29d agoGitHub ↗

Given it was introducing some confusion that this PR contemplated both our curated lending market and us doing the tokenized vault standard, we've completely separated both scopes into separate Dev Fund requests. As such:

this PR # 99 now only addresses the workload of us building curated lending on Canton
PR #863 now has all the work related to us doing the tokenized vault standard in more detail.

Hope this makes the process more clear. Cheers!

hythlodacontributorcommented30-09-2026 · 27d agoGitHub ↗

says should close and will make new proposal

hythlodacontributorcommented14-10-2026 · 13d agoGitHub ↗

This is replaced by https://github.com/canton-foundation/canton-dev-fund/pull/863

Proposal file proposals/mystic.md, 22 KB

Development Fund Proposal

Author: Mystic Finance Status: Submitted Created: 2026-03-17 Champion: Gabi Tuinaite, Bitsafe Label: defi-protocols RFPs: RFP 13 "Payments & DeFi"

Why the ecosystem needs it

Onboarding new issuers on Canton is heavily dependant on the utility we can give those assets, of which lending is usually a key driver. Within lending, curated lending has proven to be the most scalable model, as it can onboard a much larger amount of collateral assets than the shared model via isolating risk. We will drive adoption by sharing rewards with curators and lenders, bring over dominant Morpho and Kamino curators that want Canton exposure and that can port over TVL, and work closely with ecosystem players to drive adoption across Earn and borrow respectively.

Abstract

Mystic is building a modular lending market on Canton, which enables curators to create isolated lending vaults which allocate capital according to different risk preferences. This means isolated risk exposure for LPs and increased capital efficiency for borrowers, all under the privacy-preserving stack of Canton.

This work expands on what we’ve been doing over the past 12 months, where we’ve been managing the Morpho deployment on Plume, an RWA-focused L2 where we’ve achieved $80M TVL and 33k+ active users. It is our thesis that isolated lending and the ability to onboard better and more diversified collateral, RWAs in particular, is the future of on-chain lending. That thesis has led us right to Canton, where we now plan to build it in the Daml language with native Canton privacy and functionality baked in.

Serves this proposal to request the Committee for assistance mainly with audit costs, so we may take Mystic to market on Canton. We’re confident in our ability to operate and manage this business, as we have done so over the past year and have the relationships and expertise necessary to see it thrive.

Specification

1. Objective

Within this grant, Mystic delivers a production-ready modular and curated lending market for Canton that enables the permissionless creation of isolated markets where risks are contained to each market. This will enable:

Curation and creation of privacy-preserving, isolated lending vaults curated by institutions for institutions and retail alike;
Lending, borrowing and leveraging crypto and RWAs alike in an isolated environment, permissioned or permissionless;
Reusable and open infrastructure for anyone to create their own lending markets on Canton, for internal or external purposes;

2. Implementation Mechanics

The app is constituted by a set of lending markets and a set of curated vaults connected to the markets, as well as a frontend for user interactions and a backend for data management. Here we will outline how each of these work.

Each Mystic Market is a contract which accepts two assets, the collateral asset and the borrow asset (designed to align with the Canton Token Standard introduced in CIP-56). Each market has a) an oracle price feed, b) an interest rate model (IRM), c) an LLTV (liquidation loan-to-value) and d) a Custodian Party (can be a Party or a DecParty). For price verification, we integrate official Chainlink Data Streams through the ChainlinkPriceOracle template, whereas the LLTV is a parameter set by the curator upon market creation and the IRM is its own standalone contract. The Custodian Party is the one who holds the market's assets and is set by the market’s creator. As for the loan process itself, we first confirm that the assets deposited are correct by checking that the holding's instrument and registrar fields match what the market is configured to accept. Furthermore, any action on the protocol requires signatures from both the user and the protocol provider as co-signatories. The actions considered are supplying collateral, supplying the loan asset, repaying debt, withdrawing supplies, borrowing and liquidating. The protocol uses a keyless template design optimized for Daml 3.x and Daml-LF 2.2, removing traditional contract keys and maintainers to avoid per-key maintainer-uniqueness confirmation overhead and reduce per-transaction latency on the Canton Domain.

Each Mystic Vault is a contract which receives user deposits, allocates them to markets and does share accounting. Each vault also has its own Vault Registrar (can be a Party or a DecParty), who mints vaults shares to the depositor and holds idle assets until they’re lent to a market. As for the deposit and allocation logic itself - when a user supplies to the vault, they receive vault shares (tokens which represent their stake in the vault). Their assets are then lent out to market via an Adapter connecting each vault to its markets. Each vault is connected to the AdapterRegistry, which lets vaults support other types of markets to be added later on (e.g. fixed-rate). When a user supplies to the vault, funds are kept idle until the Adapter sends assets to the markets by calling Market.Supply with the Vault Registrar Party as the depositor, creating a LendingPosition owned by the Registrar Party. The Adapter stores the position reference so it can later withdraw funds when users redeem shares or when liquidity needs to be rebalanced. This design allows vault allocations to be executed automatically by the Allocator while custody of assets remains secured by Vault Registrar.

Our frontend is a React + Vite interface built with Typescript and styled with Tailwind CSS which provides a fast, responsive way to interact with markets and vaults. User interaction with the blockchain is handled directly in our frontend. The app integrates with third-party Canton wallets on the UI (e.g. Loop, Console Wallet) and the Canton Identity Provider (IdP) for wallet mapping.

Our backend is NestJS with TypeScript and it is mostly for data collection and caching. This is done by using MongoDB, Redis, and BullMQ for queues. We run most of our infrastructure on Azure, including blockchain indexers for data collection.

3. Architectural Alignment

This work directly aligns with Canton’s architecture of having multiple Subnets connected to the Global Synchronizer, as Mystic’s architecture itself is one of having multiple isolated lending markets that can trade with each other and benefit from all Mystic liquidity. It is also in line with the objectives of promoting privacy and RWA support, as our model enables both permissioned and permissionless markets, fit for crypto and RWAs alike.

The proposal also aligns with ecosystem priorities to further interoperability and broaden participation, as Mystic advances Canton DeFi modularity and increases DeFi addressable market dramatically by enabling many more issuers to be onboarded as lending collateral and supply assets, as well as enabling anyone to build private and isolated lending experiences on top of Mystic. The proposed introduction of a unified vault standard as a new CIP is also fully in alignment with these objectives.

More specifically, in terms of alignment with existing ecosystem initiatives and CIPs:

The lending vaults we've proposed building are in direct alignment and will be integrated with the Decentralization Manager proposed by Bitsafe in PR 298 to the Dev Fund, as vaults will be able to choose having centralized custody or use the Decentralization Manager for decentralized custody.
We're building everything based on CIP-56 and CIP-112 for asset standards at both vault and market level and the oracle template at the market level.

4. Backward Compatibility

No backward compatibility impact.

Milestones and Deliverables

Milestone 1: Markets

Focus:

Development of the markets layer of Mystic, each a contract with 2 assets (collateral and borrow asset), a Liquidation LTV, an Interest Rate Model (IRM), a custodian and an oracle price feed.
Front-end, backend integration.
Internal testing and internal auditing.

We have finished this already and are currently blocked by approval of this proposal to audit and thus launch on Canton.

Estimated delivery: It took us two months to do this milestone. It will take us an additional 1.5 months from the approval of this proposal to launch, during which we will be conducting audit reviews.

Regarding how the audits will be conducted: we have already gotten quotes from several auditors, so we know what to expect. We intend to do two audits on the markets codebase, in which case the process will be:

First audit: 1 week (Chain Defenders is the auditor)
Remediation of first audit: 2 weeks
Second audit: 2 weeks (Quantstamp is the auditor)
Remediation of second audit: 2 weeks Total time elapsed: 1.5 months

Some further comments:

Audits would start within a week of approval of this proposal or otherwise at the auditing firms’ earliest convenience.
Their scope would be the 3 files that make up Mystic Markets: base.dar, curator.dar, oracle.dar. Together they total 1079 NSLOC.
We will pay the audits ourselves from the funding received from this milestone. Meaning, we are here assuming that the funding is disbursed after the acceptance criteria is confirmed and it has been validated that the code is ready for auditing.

Deliverables:

3 MysticMarket Daml smart contracts - base.dar, curator.dar and oracle.dar
Market functionality on Devnet- supply, withdraw, borrow, repay, liquidate. IRM, LTV/LLTV and custodian implementations all working flawlessly;
Pass end-to-end testing of all edge cases and internal testing;
Internal audit and internal review;
UI and backend integrations so markets are functional and available on Devnet in the Mystic UI.

Milestone 2: Vaults

Focus: *Develop a lending vault on Canton, custom-made for our own use case of curated lending - this includes yield calculations, vault roles, fees, allocation, adding/removing markets, vault reallocation.

Factory contract for vault creation.
Vault and market permissioning - enabling whitelisting borrowers, lenders and liquidators per market and vault.
Curator UI development, where curators can create and manage their vaults.
Front-end, backend integrations.
Internal testing and internal auditing.

Estimated delivery: Three months from Milestone 1, including audit reviews.

We propose doing the same as above: funds are disbursed after acceptance criteria for this milestone has been confirmed, so we can then audit the vaults' code.

Deliverables:

Mystic vault Daml smart contracts.
Mystic curator UI, fully integrated with vault smart contracts
Vault functionality - deposit, withdraw, allocate, fee distribution, yield distribution, role enforcement, permissioning enforcement, share accounting.
Pass end-to-end testing and internal review of all edge cases for vaults;
UI and backend integrations so vaults are functional and available on Devnet in the Mystic UI and the curator UI.

Milestone 3: Mainnet Launch and Ecosystem Adoption

Focus: Drive traction on Mystic Markets and vaults, as well as onboard 2-3 curators for different assets. Milestone disbursement happens progressively as we gain traction.

Estimated delivery: 3 months from completing Milestone 2

Deliverables:

First markets live on Mainnet featuring with key assets in the ecosystem - CBTC, USDCx and CC as examples. Reach $1M 30-day average deposits in markets;
Launch first curated vaults on Canton in collaboration with 2-3 different curators. Reach $2.5M 30-day average deposits in vaults;
Scale vault adoption by onboarding more assets and integrating with wallets and distribution partners. Reach $10M 30-day average deposits in vaults. Deposits are here counted as the sum of collateral + supply asset deposits.

Acceptance Criteria

Milestone 1: Markets

Demonstration of markets fully working on Devnet, with all functions working well. This includes users able to withdraw, supply, borrow, repay, liquidate on markets.
Demonstration of markets whitelisting feature fully working on Devnet.
Demonstration of full codebase working and audit-readiness of markets on Devnet, including public allocation, and IRMs. Since the code is already at this level, the time we need for this milestone is just the time needed to audit it and review the audits.

Timeline: 1.5 months

Milestone 2: Vaults

Completion of audits on the market smart contracts with audit reports and remediation;
Demonstration of Mystic’s vault implementation of curated lending vaults fully working on Devnet, where users can supply/withdraw an asset and where assets deposited are split amongst the chosen markets and earn a blended supply APY;
Demonstration of vaults being able to add/remove markets, allocate to markets and rebalance across added markets as triggered by the curator;
Demonstration of owners of vaults being able to set fees, fee recipients, add/remove roles and manage access control via the curator UI. Public allocation, adapter registry and vault adapters also working as intended;
Demonstration of full codebase working on Devnet.

Timeline: 3 months from Milestone 1 completion

Milestone 3: Mainnet Launch and Ecosystem Adoption

First markets live on Mainnet - reach $1M 30-day average deposits in markets;
Launch first curated vaults - reach $2.5M 30-day average deposits in vaults;
Scale vault adoption - reach $10M 30-day average deposits in vaults. Supporting evidence will be made available publicly of the deposits in both vaults and markets, so that the Foundation can verify this information independently at any moment. Otherwise, if you require it, a Foundation-designated party can be added as an observer on the vault and market contracts so you can verify for yourself.

Timeline: 3 months from Milestone 2 completion.

From a distribution perspective, we plan to have two curators initially: one for CC and one for stablecoins, each with their own distribution advantage in the respective assets. We will work with curators and issuers on the chain to set up markets which can enable CC-denominated and stablecoin-denominated leverage loops. To add that a third vault targeting a CBTC-denominated loop is already in the works as well.

We will bootstrap supply-side TVL with CC rewards and a CEX integration we have closed which will direct users to supply their assets on Mystic. From there, we will work with issuers and curators to attract borrowers, effectively getting the flywheel to start turning. After that, our focus will be on onboarding more issuers, curators, Canton validators and distribution partners to scale the number of and size of vaults available on Canton.

Funding

Total Funding Request:

Total funding request: 1,266,665 CC (190K USD at 0.15 CC/USD rate)

Payment breakdown by Milestone:

Milestone 1 — Markets: 316,666 CC (47.5K USD at 0.15 CC/USD rate) upon committee acceptance of the criteria.
Milestone 2 — Vaults: 316,666 CC (47.5K USD at 0.15 CC/USD rate) upon committee acceptance of the criteria.
Milestone 3 — Mainnet Launch and Ecosystem Adoption: 633,333 CC (95K USD at 0.15 CC/USD rate), disbursed over three tranches are traction builds:
Markets reach $1M 30-day average deposits - 211,111 CC (31.67K USD at 0.15 CC/USD rate)
Vaults reach $2.5M 30-day average deposits - 211,111 CC (31.67K USD at 0.15 CC/USD rate)
Vaults reach $10M 30-day average deposits - 211,111 CC (31.67K USD at 0.15 CC/USD rate)

Volatility handling

The milestone amounts are denominated in Canton Coin (CC) using a baseline reference price of 0.15 USD per CC. To account for volatility, we propose to reassess the 30-day moving average of CC/USD price when each milestone ends. The proposed approach:

If moving average price at the end of a milestone is within 25% of 0.15 USD per CC, nothing changes in the amount of CC disbursed. So, within 0.1125 and 0.1875, the same amount of CC is disbursed.
If the moving average falls outside this interval, we propose the USD amount is recalculated according to the new price. So, for example, if CC moving average is at 0.1 USD at the end of a milestone, the amount disbursed is the milestone’s USD amount expressed in 0.1 CC prices.

This way, Mystic is flexible on CC volatility and we can execute the project without excessive complexity whilst also accounting for extreme volatility.

Co-Marketing

Upon each milestone release, Mystic will collaborate with the Canton Foundation on:

Joint announcements of each new functionality on Canton;
Joint blog posts and technical deep dives of what Mystic enables on Canton;
Upon Mainnet launch, LP and borrower business development to move TVL over to Canton;
Upon Mainnet launch, ecosystem development by partnering with distribution channels (e.g. wallets and neobanks, both of which we’re already in discussions with).

Motivation

Canton’s vision for interoperability of private, autonomous applications is a perfect fit for the isolated lending model and vice-versa. Mystic enables anyone to do their own underwriting whilst also being exposed to the overall market, meaning each autonomous application can have its private curated lending market but also lend/borrow against each other and benefit from ecosystem-wide liquidity, a value proposition that is almost custom-fit to what Canton is building. In that sense, Mystic brings to credit exactly what the Global Synchronizer is bringing to the Subnets: the ability for independent parties to create independent credit markets that can interact with each other. Mystic on Canton enables:

Subnets to have their own isolated, private lending market on the Global Synchronizer. We believe this can be a crucial stepping stone to make Canton’s vision a reality.
Attracting new curators, LPs, builders and participants by bringing composability to new assets.
Onboarding a plethora of asset issuers from other ecosystems and TradFi alike to the Global Synchronizer, which would be invaluable for Canton DeFi.

Rationale

Here’s why Mystic is uniquely well-positioned to deliver this project:

Existing infrastructure and user-base: We have a fully battle-tested app with 13k MAU for curated lending, with a functional curator dashboard at curator.mysticfinance.xyz and app at app.mysticfinance.xyz. We can bring our user base over to Canton.
Deep operational expertise: The Mystic team has been operating a curated lending market built on Morpho for a year now, where we’ve been working closely with curators, foundations, LPs and borrowers to build curated lending markets for different assets. We understand the nuances of operating this business, much like we have a lot of relationships we can bring over to Canton to make this project a success (for example, with curators and asset issuers). Our work has seen us reach $80M+ TVL and 33k+ users over the past year, numbers we hope to now eclipse on Canton.
Proven accountability and delivery: We’ve been in the space for a while now and are happy to introduce you to any number of partners and clients that can vouch for our professionalism and ability to deliver.

As for why this is the right design - there are two main models which dominate DeFi lending, the shared model (e.g. Aave) and the isolated model (e.g. Morpho). We will here briefly compare them in efficiency and risk:

The shared model is more efficient because it enables rehypothecation, but it doesn’t scale as well because it struggles to onboard long-tail collateral (as all assets share risk, the protocol’s risk increases with any additional collateral onboarded). Isolated lending, on the other hand, can onboard assets with much more flexibility because it isolates their risk (proven by how many more collateral assets Morpho supports over Aave). However, since this model doesn’t usually enable rehypothecation, it is less efficient on a per-dollar-supplied basis. Mystic solves this by introducing a “rehypothecation rate” for the first time in DeFi, set by curators at the vault level.
Shared models are usually more user-friendly and less complex, as there’s less to understand. That is better for retail and less nuanced players. Isolated models, on the other hand, tend to be preferred by institutions and more nuanced players, as it enables them to better manage their risk. An interesting corollary effect of this is that supply rates in isolated models tend to be higher than those of shared models, although the exact cause of this is arguable.

We believe the ability to give the best rates on the best collateral will win in lending. That is only possible by isolating it. In addition, isolating risk is key in providing an institutional-grade experience, as that is what most sophisticated players prefer. And to top it all off, the flexibility in onboarding more collateral is better primed for RWAs, which have different permissioning requirements. Taking all of these into account, it seems clear to us that curated lending is the right model for Canton - better adjusted to an institutional-user base, better adjusted to the assets the chain wants to service, and even better adjusted to how the Canton ecosystem is structured (i.e. it fits the Subnets model very well, as each Subnet can have its own curated vault(s)). We’re thus very confident in this design decision and that it is right for Canton.

All in all, Mystic is uniquely positioned to deliver a curated lending market of Canton, which is actually something we’ve wanted to do for a while now - we reached out to the Digital Asset team back in 2024 to build this, but had to pay a starting fee at the time to do so which ultimately led to us not moving forward with the project. The circumstances having now changed, we would love to make our original vision a reality with your help, and work together to bring Canton DeFi to the next level. Thank you for reading and for your consideration!

← Back to Proposals Open on GitHub ↗

Proposal: Curated Lending on Canton

Development Fund Proposal Submission

Summary

Checklist

Notes for Reviewers

Milestones 3

Discussion14 comments, 0 reviews, 8 inline comments

Proposal file proposals/mystic.md, 22 KB

Development Fund Proposal

Why the ecosystem needs it

Abstract

Specification

1. Objective

2. Implementation Mechanics

3. Architectural Alignment

4. Backward Compatibility

Milestones and Deliverables

Milestone 1: Markets

Milestone 2: Vaults

Milestone 3: Mainnet Launch and Ecosystem Adoption

Acceptance Criteria

Acceptance Criteria

Funding

Co-Marketing

Motivation

Rationale

Journey on the board 4 moves

Timeline 19 events