The problem Trecc solves

What Problem Does TRECC Solve?

The Problem

Capital sits idle; borrowing is slow and opaque.

• Lenders struggle to earn meaningful yield without taking on unknown risk or navigating fragmented DeFi protocols. They lack a single, transparent place to deploy capital and earn returns from verified, on-chain activity.
• Borrowers face friction: lengthy KYC, slow underwriting, and rigid credit systems. Accessing liquidity often means forms, waiting, and middlemen—not programmable, reputation-based credit tied to a clear identity.
• DeFi and identity are disconnected. Liquidity exists on-chain, but there’s no standard way to link a borrowable identity (with reputation and limits) to that liquidity, or to execute borrowing through a simple interface.

The Solution: TRECCC

TRECC is a prime-brokerage-style protocol that connects liquidity with autonomous, identity-backed agents.

• For Capital Providers: Deposit USDC into a single high-yield vault. Your capital is deployed by mathematically verified AI agents; you earn passive, risk-adjusted returns without managing positions yourself.
• For Borrowers: Mint an ERC-8004 on-chain identity (agent), set your operational and credit parameters, and build reputation over time. Use Elsa—a TRECC-enabled DeFi agent—to request and execute operations (e.g. “Borrow 50 USDC”) via natural language; Elsa prepares and triggers the on-chain transaction for you.
• For the System: One infrastructure layer: a liquidity vault, an agent registry (identity + reputation), and a conversational execution layer (Elsa). Lenders get clarity and yield; borrowers get programmable credit and a simple, agent-driven experience.

In short: TRECC makes liquidity simple to provide and simple to use—through a secure connection to prime-brokerage-style infrastructure, where you either supply capital to the vault or mint an autonomous agent to execute operations on-chain.

Short Tagline (for UI or pitch)

“Liquidity made simple. Provide capital to the vault, or mint an autonomous agent to execute on-chain.”

One-Liner

TRECC connects lenders and borrowers through a single vault and identity-backed AI agents, so capital earns yield and borrowers access liquidity via a conversational agent (Elsa) that executes on-chain.

Challenges we ran into

Challenges We Ran Into

• Multi-chain coordination — The app uses Base Sepolia for the vault, collateral, and Elsa transactions; Sepolia for ENS subnames (trecc.eth); and mainnet for resolving .eth names in the navbar. Keeping three chains in sync (and explaining to users that subnames live on Sepolia, not mainnet) required careful UX and config (e.g. Reown default chain, chain switching in BorrowerGate).

• RPC reliability — Public RPCs often timed out (e.g. 522 from rpc.sepolia.org) or were rate-limited (Base Sepolia). We added fallback RPC lists and explicit timeouts in the ENS register-subname API, and custom RPC URLs in Reown so balance fetches and registrations succeed consistently.

• ENS server-side registration — Registering subnames under trecc.eth required a server-owned wallet with wrapped trecc.eth on Sepolia, funded for gas. We had to handle edge cases: subname already taken, insufficient funds on the server wallet, contract reverts, and RPC timeouts—with clear error codes and messages so the frontend could show useful feedback.

• Borrower gate flow (ENS → KYC → collateral) — Sequencing “claim subname → complete KYC form → pay collateral on Base Sepolia” with real wallet switching and transaction signing was tricky. We kept KYC as mock + local storage for the demo, and had to balance “demo mode” (e.g. ignoring collateral tx failure in one path) with a path that still feels production-ready.

• Elsa: natural language → on-chain execution — Turning chat into transactions meant building an intent layer (keyword-based for now instead of a full LLM), encoding the correct vault call (issueLoan(borrower, bitGoWallet, amount)), and deciding who signs: for the demo we use the user’s wallet (MetaMask) and “fake” the BitGo wallet as the user’s address so the vault call works; production would use BitGo MPC, which adds chain/env alignment (BitGo testnet vs Base Sepolia).

• BitGo vs frontend chain — The BitGo risk engine and MPC execution use testnet Ethereum (teth) and env-driven wallet/passphrase, while the frontend and contracts are on Base Sepolia. Full E2E execution through BitGo would require aligning chains or a separate production path (e.g. Base mainnet + BitGo production).

• Lender vault: two-step flow — Depositing USDC requires approve then depositLiquidity, plus optional stakeBond (payable). Coordinating approval state, token selection (USDC vs ETH), and success redirect to the lender dashboard without leaving the user in a half-finished state took careful state handling.

• Agent registry and ERC-8004 identity — Minting an agent (registerAgent(ensName)) and then reading back the profile (e.g. agentProfiles(0)) had to match the contract ABI and tie into the rest of the borrower journey (e.g. redirect after mint, then Elsa). Getting the “identity card” and credit parameters to feel consistent with the rest of the UI required iteration.

• Dashboard and yield data — Lender and borrower dashboards need portfolio value, APY, and protocol/agent lists. Without a full backend or subgraph, we used mock time-series and mock user/agent data so the UX is complete; replacing this with real on-chain or indexed data is a known follow-up.

• Oracle dependency (Sentinel) — The Sentinel route uses Chainlink ETH/USD on Base Sepolia for a “danger threshold” (e.g. 10% drop). Any RPC or oracle failure surfaces as a 500 and had to be handled so the rest of the app doesn’t depend on it for critical path.

Short Tagline (for UI or pitch)

“Liquidity made simple. Provide capital to the vault, or mint an autonomous agent to execute on-chain.”

One-Liner

TRECC connects lenders and borrowers through a single vault and identity-backed AI agents, so capital earns yield and borrowers access liquidity via a conversational agent (Elsa) that executes on-chain.