CCPEDIAby Unity Nodes
grants-discuss

Feedback wanted: open standards for tokenized funds and verifiable fund values (RFP 11 and 12)

2 messagesstarted 21-10-2026

Source on lists.sync.global (opens in a new tab)
Also mentionsCIP-0056
  1. Sebastian Borjas#1source ↗ (opens in a new tab)
    Hi all,

    I'm Sebastián Borjas from ETP Foundry (formerly CrossDesk). We are preparing two Development Fund proposals and would like feedback before filing: open workflows for funds and collateral on Canton (RFP 12), and tools to sign and verify a fund's value on-ledger (RFP 11). A working DevNet fund exists: a standard fund-share token, atomic create and redeem, and a daily value signed by the fund's own parties. The grant would fund the open, reusable parts. The hosted product is funded by fund sponsors.

    What I would like to hear:
    1. Is this the right scope for RFP 11 and 12, or should they be split differently?
    2. Which assets should a first fund hold?
    3. Would your firm use a signed fund value (as a lender, venue, market maker, sponsor or administrator)? A one-line "yes, we would pilot it" helps a lot.
    4. Is a Tech & Ops Committee member willing to Champion it?


    DevNet only, no outside party signs yet, not registered with any regulator, code not audited.

    Sebastián Borjas, ETP Foundry · sebastian@...
  2. Sebastian Borjas#2source ↗ (opens in a new tab)
    Hi all,

    A short follow-up with something to look at: a 1-minute walkthrough of the DevNet pilot.
    https://www.google.com/url?q=https://youtu.be/Jw22DPO6ovo&source=gmail&ust=1792696022884000&sa=E

    It shows two test funds on our own DevNet validator holding real DevNet cBTC, cETH and Canton Coin; creation and redemption settled in one transaction each, with ledger receipts; the 3-of-4 seat committee (sponsor, token issuers, administrator) that signs the daily NAV, where ETP Foundry proposes but can never sign; and the NAV computed from named price sources with a fallback order.

    Three specific questions where your view would shape the proposals:

    1. RFP 12: we implemented fund shares as CIP-0056 holdings with a registry API, plus create/redeem on top. Is a "fund share profile" on CIP-0056 the right layer, or would you rather see a separate standard?

    2. RFP 11: the K-of-N on-ledger signing by named, independent parties is built. What we propose to add is a checker kit each party runs on its own systems, and a signed public summary of a fund's or issuer's numbers with no individual transactions disclosed. Is that the kind of verifiability the RFP has in mind, or do you expect something closer to a proof anyone can check against Scan?

    3. Is anyone on Tech & Ops, or a Core Contributor, open to championing one or both? I'm happy to do a 20-minute call and show it live.

    Status, so nothing is overstated: DevNet only, no money value. No outside party holds a signing seat yet. Code not independently audited. ETP Foundry is not registered with any financial regulator.

    Thank you,
    Sebastián Borjas
    ETP Foundry · https://www.google.com/url?q=http://etpfoundry.com&source=gmail&ust=1792696022885000&sa=E · sebastian@...
Back to mailing lists