Kreditos

Kredito: The Interoperable Onchain Credit Standard

1. The Problem: Picture a business in Latin America — proven model, thriving local operations, but locked out of global capital. In developed markets, low-risk capital earns under 9%. In emerging markets like LATAM, working-capital loans cost over 20% APY. And the SME funding gap is $4.3 trillion globally — over $1 trillion in LATAM alone. Why? Traditional finance is too slow and expensive. And DeFi today only does overcollateralized lending — to borrow $10,000, you lock up $15,000. But growth doesn't come from hoarding assets; it comes from credit. The liquidity is already here: stablecoin volume has passed $33 trillion, with $320 billion clearing in LATAM. The infrastructure exists — the bridge is missing..

This creates several critical bottlenecks:

Incompatible Silos: A credit line with one institution cannot be natively recognized or utilized by another. Lack of Standardization: There is no universal, programmatic standard to express "how much credit an entity has" onchain. Inefficient Capital Allocation: Because credit isn't composable, capital sits idle or requires redundant underwriting across different platforms. Opaque Risk: Evaluating an entity's aggregate risk is nearly impossible when their credit lines are scattered across offchain, private relationships.

1. The Solution: Kredito Protocol Kredito is an open interface standard that transforms a credit line into a composable, universally readable, and writable financial primitive. We provide the missing infrastructure layer: a standardized ledger of available credit.

Instead of managing separate, siloed credit lines across different platforms, an entity receives a single, unified credit line that acts as a global financial passport.

How It Works: The Kredito Lifecycle Pluggable Issuance: A credit line is issued to an entity. The issuer can be flexible: Phase 1: An automated onchain engine that programmatically evaluate the docs offchain to assest the risk and a limit. Phase 2: Verified attestations (e.g., a traditional underwriter issuing a verified credential onchain). Portable Identity (ENS Integration): Each entity's credit profile is recorded under a standardized ENS subname (e.g., acme.ratings.eth). This makes the credit line highly portable and instantly resolvable by any smart contract or application in a single call. Universal Consumption: That single credit line is consumed by multiple, unrelated applications simultaneously. Example App A: A decentralized lending vault sizes an undercollateralized loan against the entity's limit. Example App B: A stablecoin merchant settlement protocol defers payment against the exact same line.

1. Core Architectural Pillars A. The Composable Credit Standard Unified Interface: We define a standard set of smart contract interfaces (similar to ERC-20 for tokens) for querying TotalCreditLimit(), AvailableCredit(), and CurrentDrawdowns(). Global State: A central registry or state-channel mechanism ensures that drawdowns in one protocol are instantly reflected globally, preventing double-spending of credit. B. The Risk & Rating Engine Algorithmic Underwriting: An onchain methodology that ingests real-time data (wallet balances, historical transaction behavior, protocol interaction history) to dynamically adjust credit limits. Modular Integrations: Designed to plug into external oracles and zero-knowledge proofs (ZKPs) for private off-chain data (e.g., KYC/KYB status, off-chain asset verification). C. The Identity Layer ENS Subname Registry: Leveraging *.ratings.eth as human-readable, easily resolvable pointers to the underlying credit contracts. Soulbound/Non-Transferable: Credit lines are tied to specific verified entities and cannot be traded or transferred, ensuring risk models remain accurate to the specific counterparty.
2. Ecosystem & Use Cases By standardizing available credit, Kredito unlocks a massive design space for DeFi:

1. High-Level Architecture & The Split The application divides responsibility cleanly between what must be trustless onchain, and what can be managed securely and cheaply off-chainOnchain (packages/foundry): Holds capital custody, verifies credit signatures, manages lending ledger states, and issues loans. Kept lean (only 1 core contract for the MVP) to save on deployment, complexity, and audit surfaces. Off-chain (packages/nextjs + Supabase + Railway): Houses user files, documents, profile metadata, indexing caches, and coordinates the credit-underwriting pipelines.
2. Gasless User Flow (ERC-4337 + Privy) A core premise of the app is that end-users pay no gas fees:

Onboarding: The user signs in using standard OAuth (Google/email). Privy instantly spins up an embedded EOA wallet (acting as a secure signer) and pairs it with an ERC-4337 Smart Wallet. Sponsored Writes: Frontend writes utilize the custom useSponsoredWrite() hook. Instead of a direct EVM transaction, it encodes the function data into a UserOperation and sends it to Privy's bundler and managed paymaster. App Pays Gas: Privy sponsors the gas using gas credits configured in the Privy Developer Dashboard. Contract Reads: Reads map through standard wagmi hooks but target the Smart Wallet address (where balances, shares, and positions live), rather than the embedded signer's EOA. 3. The Underwriting Pipeline (Chainlink Confidential AI) Borrowers must prove their creditworthiness before receiving undercollateralized capital. This is computed through a private AI pipeline:

MAP Phase: The user uploads financial PDF/text documents (e.g., bank statements, tax forms, accounts receivable, debt ledgers). The server sends each document to the Chainlink Confidential AI Attester, which processes it using LLMs (configured for gemma4) running within a secure Trusted Execution Environment (TEE) to yield section-specific JSON insights. REDUCE Phase: A final AI inference weighs the individual document summaries, yielding a structured underwriting report and a confidentialAiScore (0 to 1000). Blended Score: The system blends the confidentialAiScore (weighted at 70%) with a traditional bureau score (weighted at 30%) to get the final credit grade. 4. Cryptographic Trust Anchor (EIP-712 Attestations) To prevent borrowers from forging their own scores, Kredito uses off-chain signing with onchain verification:

Once the pipeline determines eligibility, the server uses the protocol's private key (ISSUER_PRIVATE_KEY) to sign an EIP-712 structured message: typescript struct CreditAttestation { address borrower; // Smart wallet address of the business uint256 score; // Combined credit score uint8 riskTier; // 0 = High, 1 = Medium, 2 = Low bytes32 evidenceDigest; // Hash of the document files analyzed uint256 issuedAt; // Timestamp of issuance uint256 expiresAt; // Freshness expiration uint256 maxPrincipal; // Maximum allowed loan amount } The EIP-712 domain binds the signature to the chainId and the verifyingContract address (the specific vault), neutralizing signature replay attacks across sibling deployments. The borrower is given this signature and relays it to the vault contract onchain when calling borrow. 5. Liquidity & Lending Vault (KreditoVault.sol) The heart of the smart contract layer is the KreditoVault contract, which blends tokenized LP pools with lending logic:

ERC-4626 LP Tokenized Pool LPs deposit assets (e.g. USDC) synchronously to provide the lending capital, receiving kvSHARE tokens in return. The contract uses a _decimalsOffset() of 6 (matching USDC) to harden against inflation share-attacks.

ERC-7540 Asynchronous Redemptions Because LP capital is lent out to business borrowers, the vault cannot guarantee instant liquidity for withdrawals.

Request: LPs call requestRedeem to register their intention to exit. Their shares are escrowed in the vault contract. Fulfill: As borrowers repay loans, the vault's idle liquidity grows. The owner/keeper calls fulfillRedeem, which locks the asset-exchange rate, burns the escrowed shares, and reserves the underlying assets. Claim: The LP calls redeem or withdraw to pull their reserved, rate-locked assets out of the vault. Attestation-Gated Borrowing A borrower executes borrow(CreditAttestation, signature, borrowAmount):

The contract hashes the struct and recovers the signer using ECDSA.recover. It asserts that: The signature is valid and recovered to the trusted issuer address. The caller is the designated borrower. The attestation is fresh (expiresAt > block.timestamp, with a maximum allowed TTL of 30 days). The score is above the vault's required minScore (minimum default 750) and the risk tier is not High (0). The borrowAmount is less than or equal to maxPrincipal. The attestation digest hasn't been used before (one-time-use replay guard). If checks pass, the digest is flagged as used, the loan is recorded, and the funds are sent to the borrower's smart wallet. 6. AI-Assisted Tooling Lab (Claude Code) The codebase has custom developer configurations in .claude/ and .mcp.json that allow AI agents to manage the app:

Custom Agents: Five agents (solidity-engineer, web3-frontend, onchain-security-reviewer, integrations-engineer, grumpy-carlos-code-reviewer) are pre-prompted with local patterns. Custom Commands: Commands like /ship-check run local verification flows (ensuring addresses, decimals, and gas policies are correct), while /verify-contract automates Forge verification on Etherscan. Model Context Protocol (MCP): Custom MCP servers let the development LLM read active data directly from Railway (hosting), Supabase (database), Vercel (frontend deployment), Blockscout (EVM explorer), and GitHub.