Mand(ate)

We have built an onchain intent layer for RWA debt markets to solve the fragmented discovery and matching problem in traditional debt marketplaces borrowers and lenders. Today, platforms like Chaser, Credgenics, Retrievables, Yubi, Indifi and the company where I work building such a product layer i.e. Recur Club, all marketplace models for debt lending operate on closed matching engines with limited lender partnerships and team-level preferences inside banks and institutions.
This is solely because borrower leads are valuable business assets, these platforms rarely forward deals outside their own networks. Because It is a low priority segment because of the investment in setting a up coordinating team and since these are low margin sector, for this industry. As a result, a large portion of viable deals (often ~3 out of 10) never move forward, not due to poor borrower quality, but due to mismatched risk appetite, geography, or product constraints across lenders.

Our protocol enables borrowers to publish non-sensitive financing intents (ticket size, product type, tenure, region, security type, and high-level financials) as ENS text records, while lenders publish their investment preferences and constraints in the same public, portable format.

This creates a shared, permissionless discovery layer across protocols and RWA platforms, allowing unfunded deals to surface to other suitable lenders in the ecosystem. Aswell open for public to get directly listed to the same onchain visibility pool.

And this moreover opens up a bridging layer between onchain protocols like Ondo Finance, Plume Network, Huma Finance and their underwriting partners like Qiro Finance , Parcl Labs , which have focuses on various segments but as still separate entities operating onchain but following their internal practices, and lacks an interoperability and a coordination layer for these protocols to interact.

We have our matching engine which fetch the ENS records for all the lenders, and borrowers and the borrowers can get instant match and show their interest, for the possible deal with the lenders Once intents are matched, borrowers can show their interest with the deal visible from the lenders and proceed with off chain KYC, AML, legal checks, and underwriting as required by the Lender institutions. Once this process is done, borrowers get shown The final TERM SHEET provided by the lender and If accepted by the borrower, Settlement of the total funds is handled onchain on Arc chain using USDC. Lenders transfer funds from their non-custodial wallets to an escrow contract that automatically routes 99% to the borrower and 1% as protocol fees. This 1% fee is deducted here as an invoice to the borrower itself as the process fee for handling all the processes and handing the processes and the coordination between both thelending and borrowing parties.

This model enables structured, multi-product debt financing (term loans, cashflow financing, asset-backed loans) while keeping compliance offchain and settlement onchain. Which is a practical way of onboarding the actual RWA , offchain heavy process and labour intensive layer, become a part and processing function using the onchain.

This also solves for the real problems web3 is facing i.e. products are being built but it still lacks how to get the actual revenue models implemented or onboarded, and this model signifies that every part of this puzzle have their revenue source and a fare share of fees , similar how traditional deal making works.

Here is our brainstorming and final workflow https://excalidraw.com/#room=3e71182359ad6e5a0f7c,RQJi2PQu0zhUaPeAN8cE0Q

We built this as a hybrid onchain + offchain system, where ENS is used as the public intent registry and Arc is used as the settlement layer for moving real funds. On the smart contract side, we wrote a small ENS controller contract that creates borrower subdomains under a root ENS name. Each borrower gets a subdomain (for example, xyz.borrowerlist.n4vnt.eth) and owns it. We then use the ENS Public Resolver to store borrower and lender intent data as text records (like ROI range, loan type, tenure, industry, location, etc.). This makes the intent data public, editable, and portable across the ecosystem instead of being locked inside one platform.

For settlement, we wrote a simple Arc controller contract that accepts USDC from lenders, routes the funds through an escrow-like flow, and automatically splits the amount: 99% goes to the borrower wallet and 1% goes to the protocol as a coordination and process fee. This models real-world deal flows, where lenders disburse funds only after terms are accepted, while the platform takes a facilitation fee. The contract is intentionally minimal so that it is easy to audit and reason about during a hackathon, while still demonstrating real fund movement onchain.

On the frontend, we built the borrower and lender profile flows using React 18 + TypeScript (Vite), with Tailwind CSS v4 and shadcn/ui for fast UI composition. Wallet connections and transactions are handled using wagmi, viem, and RainbowKit. Borrowers can create their ENS subdomain directly from the UI, and then write multiple intent fields to ENS using the resolver’s multicall function, so all text records are updated in a single transaction. This was a hacky but practical optimization to reduce transaction friction while setting multiple intent fields.

The matching logic runs offchain by indexing ENS text records and filtering them based on product type, ROI range, tenure, region, and industry. This allows us to iterate quickly on matching logic without redeploying contracts. The offchain KYC, AML, and underwriting steps are intentionally kept outside the chain, but we bridge them into the onchain flow by gating settlement behind final term sheet acceptance. Overall, the system shows a realistic way to combine messy, real-world debt workflows with clean onchain discovery and settlement primitives.