Private RWA Tokenization: Secure Token Sale Framework

[Proposal setup] Proposal title

Please provide your proposal title

Private RWA Tokenization: Secure Token Sale Framework

[Proposal Summary] Time

Please specify how many months you expect your project to last

3

[Proposal Summary] Translation Information

Please indicate if your proposal has been auto-translated

No

Original Language

en

[Proposal Summary] Problem Statement

What is the problem you want to solve?

Midnight will be excluded from a massive financial sector without a privacy-preserving framework for tokenizing real-world assets and distributing ownership through shielded native tokens.

[Proposal Summary] Supporting Documentation

Supporting links

• https://github.com/jshear
,
• https://github.com/mcvetyty
,
• https://github.com/YeppleInc/ts-result
,
• https://github.com/YeppleInc/discord-bot-appreciation
,
• https://github.com/jshear/rocketpool-beta-dashboard

[Proposal Summary] Project Dependencies

Does your project have any dependencies on other organizations, technical or otherwise?

No

Describe any dependencies or write 'No dependencies'

No dependencies

[Proposal Summary] Project Open Source

Will your project's outputs be fully open source?

Yes

Please provide here more information on the open source status of your project outputs

All outputs will be entirely open source under the MIT license.

[Theme Selection] Theme

Please choose the most relevant theme and tag related to the outcomes of your proposal

Tokenization

[Campaign Category] Category Questions

What is useful about your DApp within one of the specified industry or enterprise verticals?

While token ownership can vaguely be applied to all of the applicable industries (e.g. tokenized voting rights for governance), RWA tokenization in particular is a financial tool that introduces liquidity to illiquid assets while giving financial empowerment to investors that may not have sufficient funds or avenues to access the underlying asset(s).

In particular, this solution lays the groundwork for tokenizing any arbitrary RWA with the practical guardrails and utilities that are commonplace across instruments for financial raises; these include an initial configuration of the tokenization criteria, a minimum raise threshold, descriptive metadata, a refund and distribution mechanism, and transparency around the status of the raise.

The added value from Midnight in this solution is the built-in privacy that comes with shielded assets. Utilitizing shielded native tokens, in addition to ensuring privacy at the smart contract level for purchase and claim history, presents a unique opportunity for verifiable RWA tokenization without data leakage related to the owners of the tokens. However, certain collective information about RWAs may be essential to make public and transparent (such as the percentage of the asset that is tokenized), and Midnight's selective disclosure enables the best of both worlds for anyone looking to tokenize their RWA.

What exactly will you build? List the Compact contract(s) and key functions/proofs, the demo UI flow, Lace (Midnight) wallet integration, and your basic test plan.

We will build a Lace-integrated NextJS webserver UI alongside a Compact contract to facilitate the initialization, participation, and selective data access for the tokenization of an RWA.

The primary functions of the Compact contract will be as follows:

• Constructor supporting essential tokenization configurations: base metadata, total supply, available supply (if this is a partial tokenization of the asset), price per token, and minimum token distribution (if a threshold must be met).
• Function supporting the purchase, using $NIGHT as the payment currency, of a specified quantity of tokens from any wallet; the wallet making the purchase will not be disclosed. This function must implement and honor the configurations provided to the constructor.
• Function supporting key data access: token metadata, sale configurations, and collective sale data such as total purchasers and total quantity purchased (without disclosing any specific purchaser addresses).
• Function (requiring proof that the original creator is the caller) to conclude the sale and enable the distribution (note: claim-based distribution, see next function) of either the tokens or the refunds depending on whether or not the quantity purchased exceeds the configuration for the minimum raise quantity. If the quantity purchased is sufficient for token distribution, this function will also pay all proceeds from the sale to the caller.
• Function (requiring proof that you are a participant in the sale) to claim either the corresponding tokens or refund based on the funds you provided to the sale.

The primary functions of the NextJS webserver UI will be as follows (all requiring contract integrations):

• Provide form inputs to create a new asset sale for an RWA tokenization with the required configurations.
  • The deployed contract address will be stored locally to facilitate the PoC without requiring a backend database.
• Display the metadata and collective sale data made available by the contract
• Provide inputs to select the purchase quantity/payment amount and utilize Lace to submit a transaction to enact a purchase
• If the connected Lace wallet is the creator wallet, allow them to submit a transaction to conclude the sale.
• If the sale is concluded and the connected Lace wallet is a participant allow them to submit a transaction to claim their tokens or refund.

How will other developers learn from and reuse your repo? Describe repo structure, README contents, docs/tutorials, test instructions, and extension points. Which developer personas benefit, and how will you gauge impact (forks, stars, issues, remixes)?

From an educational perspective, developers may utilize this open source PoC in the traditional ways

• Review the source code to understand the implementation of the various mechanics involved in the contract: disclosing public configurations and token metadata, allowing payments to be made to and handled by a Compact contract, tracking the partipation of non-disclosed users, understanding the aspects of minting a native shielded token on Midnight, and utilizing proofs to allow for authorized interactions that include receiving funds from a Compact contract.
• Modify and run tests (both programatically and through the UI demonstration) to find edge cases and limitations of the PoC.
• Familiarize themselves with Midnight wallet (Lace) integrations and the user flow from a creator and participant perspective when engaging with tokenized RWAs.

From a business developent perspective, developers may utilize this open source PoC as a functionally sound implementation of the Compact contract required for a cookie cutter RWA tokenization. The UI and the other infrastructure required for a full-stack launch (APIs, database, webserver hosting) are either not production-ready or simply not available as part of this PoC, though we hope that the UI may provide inspiration for production implementations.

The repo will consist of a NextJS webserver (written with TypeScript) implementing the UI and Lace integration alongside the Compact contract with associated programmatic tests and outputs. The code will be documented as needed to facilitate a comprehensive understanding of the key functions of both the Compact contract and the UI as it pertains to the contract and Lace integration. A README will tie the developer experience together by providing both an instruction list for building & running the demo as well as informational context and justifications on the implementation decisions and any alternatives that were considered.

[Your Project and Solution] Solution

Please describe your proposed solution and how it addresses the problem

We will build a Lace-integrated NextJS webserver UI alongside a Compact contract to facilitate the initialization, participation, and selective data access for the tokenization of an RWA.

The primary functions of the Compact contract will be as follows:

• Constructor supporting essential tokenization configurations: base metadata, total supply, available supply (if this is a partial tokenization of the asset), price per token, and minimum token distribution (if a threshold must be met).
• Function supporting the purchase, using $NIGHT as the payment currency, of a specified quantity of tokens from any wallet; the wallet making the purchase will not be disclosed. This function must implement and honor the configurations provided to the constructor.
• Function supporting key data access: token metadata, sale configurations, and collective sale data such as total purchasers and total quantity purchased (without disclosing any specific purchaser addresses).
• Function (requiring proof that the original creator is the caller) to conclude the sale and enable the distribution (note: claim-based distribution, see next function) of either the tokens or the refunds depending on whether or not the quantity purchased exceeds the configuration for the minimum raise quantity. If the quantity purchased is sufficient for token distribution, this function will also pay all proceeds from the sale to the caller.
• Function (requiring proof that you are a participant in the sale) to claim either the corresponding tokens or refund based on the funds you provided to the sale.

The primary functions of the NextJS webserver UI will be as follows (all requiring contract integrations):

• Provide form inputs to create a new asset sale for an RWA tokenization with the required configurations.
  • The deployed contract address will be stored locally to facilitate the PoC without requiring a backend database.
• Display the metadata and collective sale data made available by the contract
• Provide inputs to select the purchase quantity/payment amount and utilize Lace to submit a transaction to enact a purchase
• If the connected Lace wallet is the creator wallet, allow them to submit a transaction to conclude the sale.
• If the sale is concluded and the connected Lace wallet is a participant allow them to submit a transaction to claim their tokens or refund.

This solution not only provides inspiration and guidance for any Midnight developers utilizing sending/receiving funds from contracts and/or minting native shielded tokens on Midnight, but it also provides a practical and conceptually complete solution for tokenizing an RWA on Midnight in a way that has never been done before thanks to the selective disclosure available on Midnight.

[Your Project and Solution] Impact

Please define the positive impact your project will have on Midnight ecosystem

With compliance clarity and regulational guidance around RWA tokenization becoming more and more supportive, this solution provides a practical and effective solution for a growing need in this emerging market. With Midnight's advantages in regards to selective disclosure relating to the buyers of the tokenized asset, this PoC is uniquely positioned to serve as both an educational tool and a viable start to massive TVL deployment on Midnight via the tokenization of existing RWAs.

[Your Project and Solution] Capabilities & Feasibility

What is your capability to deliver your project with high levels of trust and accountability? How do you intend to validate if your approach is feasible?

The BankFi team, which also encompasses the Yepple development firm, have been a committed and dedicated Cardano development firm for over 4 years. We have delivered development solutions to hundreds of Cardano projects with a 100% satisfaction rate, with native asset sales (both NFT & FT) being our flagship and most popular service from day 1 through today.

We are eager to extend our expertise to Midnight from a technical perspective as well as a conceptual perspective on which configurations and attributes are most essential for RWA tokenization.

[Final Pitch] Budget & Costs

Please provide a cost breakdown of the proposed work and resources

In the spirit of complete transparency, the efforts committed to this proposal will likely exceed, in terms of market rates/value, the budget of this proposal. Our team consists of dedicated full-time Cardano developers and other supporting staff who are all eager to contribute to the foundation and growth of the Midnight network. With that in mind, we aimed to keep the requested budget lower than the market rate development for the expected amount of work.

To give an understanding of the proportional costs, this is a prorated budget to fit the requested funds:

• $1,200 for project management; defining objectives, enumerating the tasks for each milestone, planning timelines and tracking development progress
• $4,500 for development; Compact contract implementation, UI implementation, Lace integration, and programmatic test creation
• $1,800 for documentation and quality assurance; ensuring comprehensive documentation of both the code and installation/build/deployment of the solution, as well as ensuring that the documentation matches the observed behavior of the application

[Final Pitch] Value for Money

How does the cost of the project represent value for the Midnight ecosystem?

Enabling tokenized RWAs on Midnight opens the door to trillions of dollars in TVL. Of course it is hyperbolic to say that all assets in the world will be tokenized on Midnight, and it would also be embellishing this proposal to say it would be even remotely reponsible for that level of adoption -- however, this is the first piece of the puzzle in the foundation of tokenized RWAs on Midnight and having a Proof of Concept available may inspire and enable the first RWA projects willing to expand onto Midnight.

Our team will ensure that the quality of the implementation and documentation are more than sufficient for newly onboarded Midnight develpers to bootstrap their understanding of how RWAs can be tokenized in a privacy-preserving fashion.

This proposal provides value in two different aspects. Firstly, it functions as a reference application as requested by this Catalyst category, showing one possible application that can be built on Midnight. Secondly, it functions as a building block for any project on Midnight that wants to utilize shielded native tokens, accept user payments, or distribute $NIGHT and/or native tokens to users.

[Self-Assessment] Self-Assessment Checklist

I confirm that the proposal clearly provides a basic prototype reference application for one of the areas of interest.

Yes

I confirm that the proposal clearly defines which part of the developer journey it improves and how it makes building on Midnight easier and more productive.

Yes

I confirm that the proposal explicitly states the chosen permissive open-source license (e.g., MIT, Apache 2.0) and commits to a public code repository.

Yes

I confirm that the team provides evidence of their technical ability and experience in creating developer tools or high-quality technical content (e.g., GitHub, portfolio).

Yes

I confirm that a plan for creating and maintaining clear, comprehensive documentation is a core part of the proposal's scope.

Yes

I confirm that the budget and timeline (3 months) are realistic for delivering the proposed tool or resource.

Yes

[Required Acknowledgements] Consent & Confirmation

I Agree

Yes