#sxt $SXT @SpaceandTime An address borrowed three times on Ethereum and repaid on time; was liquidated once on another chain; and was a long-term depositor for two years in a third protocol. These records are scattered across different chains and contracts, and when a protocol issues a loan, it can only see the borrower's balance at that moment—every borrower is a stranger, and collateral ratios are one-size-fits-all.
On-chain credit isn't growing, and the problem isn't capital—it's credit history. Traditional finance sets prices using mortgage records, account activity, and repayment history. All this data actually exists on-chain, but no one can reliably piece it together, or prove that the assembled result hasn't been tampered with.
@SpaceandTime changes that starting point: it combines historical activity across multiple chains and protocols into a queryable, verifiable record—past borrowing, repayments, liquidations, recovery after liquidation, and long-term activity across protocols—then uses zero-knowledge proofs to put the results on-chain, so contracts can verify them themselves instead of trusting a backend API.
Technically, it stacks three layers: complete on-chain data ingestion (including transactions and contract event logs), direct SQL queries against EVM chain history, and Proof of SQL attestations for query results. Calling it from a protocol is much like an ordinary data read, but with an added layer of verifiability.
The change shows up in the parameters: collateral requirements, interest rates, credit limits, and whitelists can vary based on proven behavior, rather than being uniformly set by governance votes. Addresses with clean repayment records get lower collateral requirements; addresses liquidated multiple times must maintain a larger safety buffer; and long-term depositors get higher credit limits. The same principle applies to distribution: rewards are calculated based on actual behavior, turning Sybil resistance from “guesswork” into “calculation.”
The privacy aspect is just as important: queries don't need to reveal the real-world identity behind an address or disclose risk-control logic—the proof establishes that “the computation hasn't been tampered with,” not that “your data has been laid bare.” For institutional capital, the latter is often what determines whether it dares to go on-chain.
It's important to be clear about the limits: verifiability solves the problem of “data and computation not being tampered with”; it doesn't solve whether “the past can predict the future.” Risk controls still need to be designed, backtested, and iterated—it's just that they can finally be built on inputs that can't be quietly rewritten.
Credit has never been about balances; it's about time. For on-chain credit to truly grow, the first step is making “track records” trustworthy.
On-chain credit isn't growing, and the problem isn't capital—it's credit history. Traditional finance sets prices using mortgage records, account activity, and repayment history. All this data actually exists on-chain, but no one can reliably piece it together, or prove that the assembled result hasn't been tampered with.
@SpaceandTime changes that starting point: it combines historical activity across multiple chains and protocols into a queryable, verifiable record—past borrowing, repayments, liquidations, recovery after liquidation, and long-term activity across protocols—then uses zero-knowledge proofs to put the results on-chain, so contracts can verify them themselves instead of trusting a backend API.
Technically, it stacks three layers: complete on-chain data ingestion (including transactions and contract event logs), direct SQL queries against EVM chain history, and Proof of SQL attestations for query results. Calling it from a protocol is much like an ordinary data read, but with an added layer of verifiability.
The change shows up in the parameters: collateral requirements, interest rates, credit limits, and whitelists can vary based on proven behavior, rather than being uniformly set by governance votes. Addresses with clean repayment records get lower collateral requirements; addresses liquidated multiple times must maintain a larger safety buffer; and long-term depositors get higher credit limits. The same principle applies to distribution: rewards are calculated based on actual behavior, turning Sybil resistance from “guesswork” into “calculation.”
The privacy aspect is just as important: queries don't need to reveal the real-world identity behind an address or disclose risk-control logic—the proof establishes that “the computation hasn't been tampered with,” not that “your data has been laid bare.” For institutional capital, the latter is often what determines whether it dares to go on-chain.
It's important to be clear about the limits: verifiability solves the problem of “data and computation not being tampered with”; it doesn't solve whether “the past can predict the future.” Risk controls still need to be designed, backtested, and iterated—it's just that they can finally be built on inputs that can't be quietly rewritten.
Credit has never been about balances; it's about time. For on-chain credit to truly grow, the first step is making “track records” trustworthy.