
Tenor
Tokenised securities lending on Hedera with atomic settlement and self executing maturity.
Demo
About
Tenor is a compliance gated lending desk for tokenised securities on Hedera. A borrower uses a tokenised bond as collateral and receives USDC from a lender. The lender first signs an EIP-712 quote off chain, defining the principal, repurchase price, maturity and haircut. The borrower accepts that quote and calls openRepo once. Cash and collateral are moved atomically, so the trade cannot settle only one side. The important part is what happens next. At the moment the repo opens, Tenor schedules its maturity settlement through Hedera's HIP-1215 Schedule Service. No keeper, cron job or liquidation bot is required. At maturity, Hedera calls closeRepo automatically. If the borrower has repaid, the collateral returns. If they have not, the lender receives the collateral. Early repayment is also supported. The collateral is a real ERC-1400 security issued through Hedera Asset Tokenization Studio, with identity and compliance modules implemented by us because ATS requires them but does not provide them. Transfers are therefore compliance gated by the token itself, not just by our frontend. The cash leg uses USDC through Hedera Token Service's ERC-20 facade. The complete lifecycle has been proven on Hedera testnet with real ATS collateral and real USDC: atomic opening, early repayment and a scheduled maturity execution have all succeeded. The scheduled maturity execution required nobody to be online and the settlement contract paid its own scheduling fee. Tenor also records lifecycle events through a Hedera Consensus Service audit trail. The frontend is built with Next.js, React and Tailwind, with wallet support through WalletConnect and Rabby or MetaMask, while Privy provides email based onboarding and wallet access for users who do not already have a wallet. The result is a complete on chain lifecycle for lending against regulated tokenised securities: RFQ based price discovery, atomic settlement, compliance enforced by the asset, and a maturity event that the network executes itself.
How it's made
Tenor is built as a Solidity settlement layer on the Hedera EVM, with a Next.js frontend and a small off chain service for indexing quotes and publishing the audit trail. The core contract, TenorSettlement.sol, handles the complete lifecycle: opening a repo, verifying the lender's EIP-712 quote, moving USDC, escrowing the security, scheduling maturity, early repayment and default settlement. The quote is signed off chain, so the lender does not need to submit a transaction just to make an offer. For collateral, we used Hedera Asset Tokenization Studio to issue our own ERC-1400 security on testnet. ATS requires an identity registry and compliance module but does not ship them, so we implemented minimal versions and wired them into the token. This means a non compliant counterparty cannot simply receive the security by bypassing our frontend. For cash, we use USDC through Hedera Token Service's ERC-20 facade. For maturity automation, Tenor calls Hedera's HIP-1215 Schedule Service directly from openRepo, creating the future close operation as part of opening the trade. The frontend is Next.js 16 with React 19 and Tailwind CSS. Wallet integration uses wagmi, viem and WalletConnect with Rabby and MetaMask. Privy is used for email based onboarding, allowing users without an existing wallet to reach the product while retaining access to their account. Quotes and repo data are indexed in SQLite, and lifecycle events are mirrored to a Hedera Consensus Service topic to create an independently timestamped audit trail. We used Foundry for Solidity development and testing. The repository contains hand written interfaces for the Hedera services and ATS, periphery contracts for the required compliance components, a HIP-1215 measurement probe, 29 contract tests and a step by step testnet flow. The hackiest part was integrating Hedera precompiles with Foundry. forge script --broadcast locally simulates the script before broadcasting, but its local EVM does not implement Hedera's 0x16b Schedule Service or 0x167 HTS facade. That made apparently valid scripts fail before reaching the network. We worked around this by constructing and signing the exact calldata separately and submitting it directly with cast, allowing the real Hedera network to execute the precompile calls. Another deliberate design choice is that closeRepo must never revert because a scheduled transaction executes only once. Settlement logic therefore treats default as a normal business outcome and uses a nested self call to keep the cash and collateral legs atomic while allowing the outer scheduled call to complete successfully. Everything important is therefore demonstrated against the actual Hedera testnet rather than only against mocks.