SyndicateLend

Demo

About

‼️ The Problem: When a company wants to borrow more money than a single bank is willing to lend, a group of banks will club together and lend it jointly. This is called a syndicated loan. This is one of the largest credit markets on earth, with over $1.4 trillion outstanding in the US leveraged segment alone. Loan “pieces” are bought and sold by funds, insurers and banks, with secondary trading reaching a record of nearly $1 trillion in 2025. However, in this market, although a trade is agreed on in seconds, settlements take weeks to complete: - Only 29% of par loan trades settled within T+7 - 44% between T+7 and T+20 - 27% took longer than T+20 (This means more than twenty business days after the trade). Why? Unlike a normal security, a loan piece is a private and bespoke contract. There is no shared infrastructure for recording who owns it or transferring it. Ownership records sit inside the administrative agent’s (usually the arranger bank, which is the lead bank of the syndicate) private database. Buying a loan piece means becoming a lender under the borrower’s shared credit agreement, and the agent must update the private loan register. Because that register is private and agent-controlled, the transfer of loan ownership is not natively linked to the movement of payment. They are handled as two separate processes. Existing platforms make the surrounding paperwork and communication faster, but they still do not make the loan position and the payment change hands together. The result is a settlement gap- the trade is agreed in seconds, but ownership and cash only reconcile weeks later. That gap is what SyndicateLend addresses. The weeks-long settlement exposes buyers and sellers to unnecessary credit and counterparty risk, locks up idle capital, and forces the market to run an elaborate compensation system just to apologise for its own slowness. Funds offering daily redemptions face an additional liquidity mismatch problem where LPs can request cash before loan-sale proceeds arrive. --- ✅ The Solution: SyndicateLend is a private institutional secondary-market RFQ exchange and tokenised syndicated loan registry. SyndicateLend reduces settlement from weeks to seconds. 🚀 - Each lender’s share of a loan is represented by tokens on a shared digital register. - A seller requests quotes from other institutions, accepts a buyer’s offer, and both institutions authorise the trade. - At settlement, the loan tokens move to the buyer and payment moves to the seller in the same atomic transaction, which means both legs settle together or neither happens. 🤝 --- 💼 We have 3 distinct workspaces for the following: 📎 Workspace 1 : You are the agent bank for a loan contract. You can manage the loan registry, interest calculations, approval, and transfer assets for secondary market trades. 📎 Workspace 2 : You make RFQ trades in the secondary market with other syndicate lenders and request the agent bank to settle the trade between our institution and the other. 📎 Workspace 3 : You monitor your own positions and interest accruals across all books, where you are either an agent arranger bank, part of a syndicate, or a secondary market buyer. ⚫️ An overview of the general workflow: 1. The agent bank issues loan tokens and allocates them to lenders. 2. The agent controls who can hold or receive the tokens. 3. A seller requests quotes from eligible institutions. 4. A buyer’s offer is accepted, subject to the institution’s internal approvals. 5. At settlement, loan tokens and payment tokens swap atomically. 6. Interest and other distributions are calculated and paid to current holders. --- ⚫️ Three technologies support this institutional workflow and privacy story: 🏦 Hedera Asset Tokenization Studio — Used to manage loan positions. The agent issues tokens, allocates them to lenders and controls who can hold or receive them. A settlement contract exchanges those positions against an HTS payment token, while Hedera records the trading events and executes scheduled settlements. The asset represented is a lender’s position in a specific loan tranche. Hedera combines a ready-made compliance framework in ATS, native payment tokens and network-executed scheduling. That lets us build the loan’s issuance, transfer controls and settlement together without building a security-token framework or running a separate settlement scheduler. 🫆Privy — Used for institutional identity and permissions. Staff sign in to an institutional wallet, where a quorum of authorised members (2 of 3 in demo) must approve an action. The trader’s decision is therefore subject to the institution’s internal approval policy before assets can move. Privy combines familiar staff login with user-bound wallet quorums, transaction policies and approval intents. That lets us enforce an institution’s signing mandate without holding its wallet keys or building a separate multisignature approval system. ⛓️ Chainlink CRE — Used to handle confidential interest calculations. It checks the agent’s private rate notice (a confidential message stating the interest rate for a particular period) against a previously published cryptographic commitment, combines the terms with lender balances and calculates each holder’s payment. The workflow releases the distribution amounts without publishing the underlying notice. CRE Confidential Workflows supports confidential computation, not just private API access. That lets us put notice retrieval, commitment verification and interest calculation inside one TEE handler, with explicit control over which results leave it. The MVP demonstrates token issuance, controls, settlement and payments using synthetic assets on Hedera testnet. The confidential calculation is demonstrated through CRE simulation; private institutional deployment on HashSphere (by Hedera) is intended for production. --- ⚫️ References: - https://www.lsta.org/university/operations/ - https://www.lsta.org/content/secondary-trading-settlement-study-first-quarter-2026/ - https://www.lsta.org/content/lsta-secondary-trading-monthly-executive-summary-2q25-secondary-loan-trading-volumes-spike-again-to-a-record-262-billion/

How it's made

* Core stack: SyndicateLend is built with Next.js + TypeScript, Solidity contracts tested with Foundry, administrative scripts using the Hedera and ATS SDKs, Privy institutional wallets, and a TypeScript Chainlink CRE confidential workflow. * The workflow follows an actual syndicated-loan assignment: the administrative agent issues a loan tranche and allocates lender positions; a seller sends an RFQ; another institution quotes; the seller accepts; both institutions complete their internal approvals; and the trade settles Delivery-versus-Payment. The same lender register is then used for interest distributions. * Hedera ATS — tokenised loan register: Each loan tranche is represented by an Asset Tokenization Studio bond-type security, with 1 token representing $1 of par. ATS whitelist and internal KYC controls restrict who can hold the loan. Secondary transfers deliberately use transferFrom, not an administrative forced transfer, so the agent cannot bypass the same eligibility rules applied to other holders. * HTS — cash and compliance controls: The cash leg uses an HTS mock-USD token with KYC, freeze and pause controls. The same token is used for interest distributions. Larger lender sets are paid in batches to stay within Hedera’s transfer-entry limits. * Atomic settlement + HSS: A custom Solidity SettlementEngine exchanges the ATS loan position and HTS payment token atomically: if either the asset or cash leg fails because of eligibility, KYC, allowance, balance, freeze or pause controls, neither asset moves. When the second institution approves, the contract calls Hedera Schedule Service scheduleCall itself and funds its own scheduled execution, so there is no off-chain settlement keeper. Eligibility is effectively checked again when the ATS transfer executes. * HCS + Mirror Node — trading and audit data: RFQs, quotes, acceptances and approvals are written to Hedera Consensus Service in consensus order, so the trading blotter can be reconstructed from the ledger rather than a central database. Mirror Node event logs are also used to reconstruct historical assignments. HCS additionally stores cryptographic commitments to confidential rate notices and reconciliation reports rather than publishing the underlying private data. * Privy — institutional wallet controls: Each institution gets a server-provisioned Privy organisation wallet owned by a 2-of-3 key quorum across trader, compliance and portfolio-manager users. Wallet policies limit transactions to the permitted Hedera contracts and call types, while key export is disabled. Transactions are proposed as signing intents and only execute after the quorum threshold is reached. An automated liquidity desk uses a 2-of-2 quorum of server-held P-256 authorisation keys for programmatic workflows. * HIP-719 bridges Privy and Hedera: Privy wallets sign normal EVM transactions rather than Hedera-native TokenAssociateTransactions. I use the HIP-719 token facade to call associate() directly on the HTS token address, allowing an institutional Privy wallet to complete token association through an ordinary EVM intent. * Chainlink CRE — confidential interest calculation: Loan rate notices should remain private, but interest must be calculated against the current lender register. The agent therefore publishes only a salted commitment to the notice on HCS. A CRE Confidential Workflow, configured with handlerInTee for AWS Nitro, retrieves the authenticated private notice using a DON secret, verifies it against the public commitment, reads all lender balances through a RegisterSnapshot helper contract, and calculates each lender’s interest using integer arithmetic. Only the commitment, period, holder addresses and payment amounts leave the confidential workflow; the rate, day-count basis, nonce and API credential remain private. * A few intentionally hacky integrations: RegisterSnapshot returns every lender balance in one Mirror Node contract call instead of one HTTP request per lender. HCS messages larger than its message limit are reassembled using their shared initial_transaction_id. For backend ATS operations, I reused the SDK’s testing pattern by initialising its MetaMask adapter in debug mode and injecting an ethers.Wallet signer. * What is deployed and where: The loan token, HTS payment token, HCS topics, settlement engine and test trades run on Hedera Public Testnet, including successful atomic settlement and a failed settlement after buyer eligibility was revoked. The retail feeder is also demonstrated on public testnet. CRE is demonstrated through its simulator rather than a live DON deployment because beta deployment access was not available before the deadline. Private institutional deployment on HashSphere is the intended production architecture.