From ccd7aea1a7ca42a2bbd92806d922a040c2b9b855 Mon Sep 17 00:00:00 2001 From: Orest Tarasiuk <830847+OrestTa@users.noreply.github.com> Date: Tue, 22 Sep 2026 20:57:29 +0200 Subject: [PATCH 1/5] docs: reposition around undercollateralized lending for leverage The docs site still described t1 as cross-chain appchain infrastructure, while the relaunched landing page positions t1 as the permissionless credit protocol for DeFi. This brings the docs in line with it. New under Protocol Overview: Programmable Custody, Margin Accounts, Risk Engine and Liquidation, and Lending Pools. Introduction rewritten around permissionless credit; TEE and Real-Time Proving reframed as the infrastructure the credit protocol runs on; Network Architecture kept but retitled and labelled as the long-term network vision from the litepaper. New Ecosystem page for amplifi and juiced, and two new integration pages for venues and lenders. Glossary gains the credit vocabulary and loses two stale litepaper anchors. Co-Authored-By: Claude Opus 5 --- README.md | 4 +- docs/integration/7683/_category_.json | 2 +- docs/integration/docker/_category_.json | 2 +- docs/integration/integration.md | 24 ++++++- docs/integration/lending.md | 29 ++++++++ docs/integration/leverage.md | 32 +++++++++ docs/integration/xChainRead/_category_.json | 2 +- docs/intro/ecosystem.md | 23 ++++++ docs/intro/glossary.md | 54 ++++++++++++-- docs/intro/protocol/architecture.md | 10 ++- docs/intro/protocol/introduction.md | 44 +++++++++--- docs/intro/protocol/lending-pools.md | 33 +++++++++ docs/intro/protocol/margin-accounts.md | 40 +++++++++++ docs/intro/protocol/programmable-custody.md | 53 ++++++++++++++ docs/intro/protocol/risk-engine.md | 39 ++++++++++ docs/intro/protocol/rtp.md | 18 +++-- docs/intro/protocol/tee.md | 22 ++++-- docs/intro/research.md | 6 +- docs/intro/resources.md | 6 +- docusaurus.config.mjs | 2 +- src/pages/index.tsx | 80 ++++++++++++--------- 21 files changed, 449 insertions(+), 76 deletions(-) create mode 100644 docs/integration/lending.md create mode 100644 docs/integration/leverage.md create mode 100644 docs/intro/ecosystem.md create mode 100644 docs/intro/protocol/lending-pools.md create mode 100644 docs/intro/protocol/margin-accounts.md create mode 100644 docs/intro/protocol/programmable-custody.md create mode 100644 docs/intro/protocol/risk-engine.md diff --git a/README.md b/README.md index 3c3ea8213..56b5022b4 100644 --- a/README.md +++ b/README.md @@ -6,8 +6,8 @@ This web application contains all documentation for t1. It was forked from the [ ### t1 documentation currently has two sections: -- Intro - General t1 information or concepts useful for using t1 -- Integrations - e.g. xChainRead API documentation +- Intro - the credit protocol (programmable custody, margin accounts, the risk engine, lending pools), the TEE and Real-Time Proving infrastructure under it, the long-term network design, and the ecosystem +- Integrations - how to offer leverage on a venue, how to provide lending liquidity, and the underlying primitives (xChainRead, ERC-7683, Docker dApps) ### TODOs: diff --git a/docs/integration/7683/_category_.json b/docs/integration/7683/_category_.json index c9f0f2fec..79555fa7b 100644 --- a/docs/integration/7683/_category_.json +++ b/docs/integration/7683/_category_.json @@ -1,4 +1,4 @@ { "label": "ERC-7683", - "position": 2 + "position": 5 } diff --git a/docs/integration/docker/_category_.json b/docs/integration/docker/_category_.json index 97e26082f..4e4d34e1b 100644 --- a/docs/integration/docker/_category_.json +++ b/docs/integration/docker/_category_.json @@ -1,4 +1,4 @@ { "label": "Docker dApps", - "position": 3 + "position": 6 } diff --git a/docs/integration/integration.md b/docs/integration/integration.md index 941c464b5..a5a4b2374 100644 --- a/docs/integration/integration.md +++ b/docs/integration/integration.md @@ -4,4 +4,26 @@ sidebar_label: Integration Overview sidebar_position: 1 --- -Use the sidebar on the left to learn about using t1's infrastructure and integrate your app. +# Integration Overview + +There are three ways to build with t1, depending on what you bring to it. + +## Offer leverage to your users + +You operate a venue — an exchange, a prediction market, a trading app — and you want your users to trade with borrowed capital without your taking custody of it. t1 issues each of them a [margin account](../intro/protocol/margin-accounts.md) whose key enforces a policy you and your lenders agree on, and handles liquidation itself. + +→ [Offer Leverage on Your Venue](./leverage.md) + +## Provide lending liquidity + +You have capital and want it earning on undercollateralized loans without counterparty exposure, a legal agreement, or a KYC programme to administer. Set up a pool with your own parameters, or deposit into an existing one. + +→ [Provide Lending Liquidity](./lending.md) + +## Use the underlying primitives + +The credit protocol is built on primitives t1 exposes directly, and they are useful on their own: + +- **[xChainRead](./xChainRead/overview.md)** — call a view function on another chain and verify the result in your contract. This is how positions held on separate venues resolve into one margin account, and it works for anything else that needs proven cross-chain state. +- **[ERC-7683](./7683/solver-integration.md)** — t1's intent protocol, where real-time proof of a fill lets solvers be repaid in under ten seconds instead of waiting out a challenge window. +- **[Docker dApps](./docker/overview.md)** — run your own Docker-packaged code inside t1's TEE, co-located with `t1-core`, with access to TEE-controlled multi-chain identities. diff --git a/docs/integration/lending.md b/docs/integration/lending.md new file mode 100644 index 000000000..46740c83c --- /dev/null +++ b/docs/integration/lending.md @@ -0,0 +1,29 @@ +--- +title: Provide Lending Liquidity +sidebar_label: Provide Liquidity +sidebar_position: 3 +--- + +# Provide Lending Liquidity + +Deposit capital into a t1 [lending pool](../intro/protocol/lending-pools.md) and it is lent to borrowers on undercollateralized terms. Repayment is enforced by the borrower's [margin account](../intro/protocol/margin-accounts.md), not promised by the borrower. + +## What you are relying on + +- **Open-source risk engine.** The liquidation logic is published; you can read it rather than infer it from a term sheet. +- **Liquidations attested in real time.** Each decision is attested by the enclave that made it, so you can verify a close rather than receive a report of one. +- **Risk parameters customizable per pool.** Venues, assets, maximum position size, liquidation threshold, and interest terms are yours to set. +- **No counterparty legal exposure.** The margin account is the counterparty, so there is no agreement to draft and no debtor to pursue. +- **Permissionless borrowers, no KYC to administer.** Borrowers are anonymous by design; you run no identity programme and inherit no obligation from having run one. + +What you are still exposed to is market risk: a position can gap through its liquidation threshold, or the book behind it can be too thin to unwind at the modeled price. [Residual risk](../intro/protocol/risk-engine.md#residual-risk) covers this, and the maximum size and liquidation threshold you set are the levers over it. + +## Two ways in + +**Deposit into an existing pool.** Fastest path. You accept the pool's policy as written and start earning on its terms. + +**Set up your own pool.** You define the policy — which venues the capital may reach, how much exposure a single account may carry, where liquidation triggers, and what borrowing costs. Every margin account that borrows from your pool is bound to that policy at the moment its key is created, and the binding cannot be changed afterwards. + +## Get in touch + +Pool creation and institutional deposits are handled with us directly. Join the [Discord](https://discord.com/invite/qVEUA6jmGZ) or email [can@t1protocol.com](mailto:can@t1protocol.com). diff --git a/docs/integration/leverage.md b/docs/integration/leverage.md new file mode 100644 index 000000000..b6438d5da --- /dev/null +++ b/docs/integration/leverage.md @@ -0,0 +1,32 @@ +--- +title: Offer Leverage on Your Venue +sidebar_label: Offer Leverage +sidebar_position: 2 +--- + +# Offer Leverage on Your Venue + +Your users trade with borrowed capital on your venue, and you never hold it. t1 issues each of them a [margin account](../intro/protocol/margin-accounts.md) controlled by an encumbered key, extends credit into it from a [lending pool](../intro/protocol/lending-pools.md), and runs liquidation itself. + +## What you get + +- **Leverage on a venue you already operate.** Users trade with borrowed capital on your venue. You are never the custodian of it and never the lender of record. +- **Margin accounts.** Credit is issued against a policy you help define, with liquidation handled by the protocol rather than by your operations team. +- **Cross-venue and cross-chain collateralization.** One collateral base per user, positions across separate venues and chains. A user's margin on your venue is not stranded there. + +## What it means for your users + +They keep direction rights over the capital and never get withdrawal rights over it, which is the property that lets the loan be undercollateralized in the first place. They do not hand custody of their own deposit to you, and they do not pass KYC to borrow. See [Programmable Custody](../intro/protocol/programmable-custody.md) for the mechanism. + +## What integrating involves + +The shape of the work depends on whether your venue settles on-chain or runs an off-chain orderbook, but the pieces are the same in both cases: + +1. **Agree the policy.** Which venues and assets the account may touch, the maximum position size, and the liquidation threshold. This is what your lenders are pricing, and it is bound into the account's key at creation. +2. **Connect the venue.** t1's risk engine needs to read positions and prices from your venue, and the encumbered key needs to be able to place and cancel orders on it — both through your existing interfaces. +3. **Point your frontend at the account.** Your users deposit into their margin account and trade from it. The signature gate is transparent to them until it rejects something the policy forbids. +4. **Source the liquidity.** Either bring your own lenders or draw on existing pools. + +## Get in touch + +There is no self-serve onboarding yet; venue integrations are done with us directly. Join the [Discord](https://discord.com/invite/qVEUA6jmGZ) or email [can@t1protocol.com](mailto:can@t1protocol.com). diff --git a/docs/integration/xChainRead/_category_.json b/docs/integration/xChainRead/_category_.json index fb2c69df1..46d70b79f 100644 --- a/docs/integration/xChainRead/_category_.json +++ b/docs/integration/xChainRead/_category_.json @@ -1,4 +1,4 @@ { "label": "xChainRead", - "position": 1 + "position": 4 } diff --git a/docs/intro/ecosystem.md b/docs/intro/ecosystem.md new file mode 100644 index 000000000..d37b51e8f --- /dev/null +++ b/docs/intro/ecosystem.md @@ -0,0 +1,23 @@ +--- +id: ecosystem +title: Ecosystem +sidebar_position: 2 +--- + +t1's credit infrastructure already powers two live applications. Both use the same [margin accounts](./protocol/margin-accounts.md) and the same [risk engine](./protocol/risk-engine.md); they differ in the venue they lend against and the policy their pools run. + +## amplifi + +**Permissionless prime brokerage for prediction markets and perpDEXs.** Up to **10×** leverage on Polymarket, with no KYC and no custody transfer: a trader deposits margin, draws credit against it, and trades a Polymarket position from an account that cannot pay out to anyone but the pool and themselves. + +[amplifi.finance →](https://amplifi.finance/?utm_source=t1-docs&utm_medium=website&utm_campaign=t1docs-credit&utm_content=ecosystem-page&utm_term=10x-polymarket) + +## juiced + +**Leverage on memecoins before they list on perpDEXs.** Up to **5×** on Robinhood Chain. The interesting case for programmable custody, because these markets have no perpetual venue to borrow against and no on-chain lending market deep enough to collateralize them. + +[juiced.exchange →](https://juiced.exchange/?utm_source=t1-docs&utm_medium=website&utm_campaign=t1docs-credit&utm_content=ecosystem-page&utm_term=robinhood-chain) + +## Building on t1 + +The same infrastructure is available to other venues and applications. If you operate a venue and want your users to trade with borrowed capital you never hold, see [Offer Leverage on Your Venue](../integration/leverage.md). If you want to put capital behind a policy, see [Provide Lending Liquidity](../integration/lending.md). diff --git a/docs/intro/glossary.md b/docs/intro/glossary.md index 842d820ca..12a67252d 100644 --- a/docs/intro/glossary.md +++ b/docs/intro/glossary.md @@ -1,9 +1,45 @@ --- id: glossary title: Glossary -sidebar_position: 4 +sidebar_position: 5 --- +## Programmable custody + +t1's name for custody that is enforced by code rather than by an institution. A margin account's private key is held inside a [TEE](#tee) and bound to a [loan policy](#loan-policy) at creation, so the key signs a transaction only if the policy permits it. The borrower can direct the capital and can never withdraw it. See [Programmable Custody](/intro/protocol/programmable-custody). + +## Private key encumbrance + +The academic term for a key whose holder cannot use it freely, because the conditions under which it will sign are fixed outside their control. Programmable custody is an applied form of it. + +## Encumbered key + +The keypair controlling a [margin account](#margin-account). Generated inside the TEE, with the private half never leaving it, and bound to a loan policy at the moment of creation. The binding cannot be redone, so an account's policy is fixed for its whole life. + +## Margin account + +The account t1 lends into: one per borrower, holding their own deposit plus the credit drawn against it, and appearing as the trading address at every venue the policy permits. Positions held on separate venues resolve into this single account. See [Margin Accounts](/intro/protocol/margin-accounts). + +## Loan policy + +The rules an encumbered key enforces: the permitted venues and assets, the maximum position size, the liquidation threshold, and the interest terms. Set by the lender when a [lending pool](#lending-pool) is created, and immutable thereafter. + +## Signature gate + +The point at which a policy is applied. Every transaction an account would make — a borrower's trade, a withdrawal attempt, a liquidation — is presented to the encumbered key, which signs it or does not. + +## Lending pool + +Where credit comes from. Lenders deposit capital into a pool, the pool carries a loan policy, and every margin account borrowing from it is bound to that policy. A lender wanting different parameters creates a different pool. See [Lending Pools](/intro/protocol/lending-pools). + +## LTV + +_Loan-to-value_ is the ratio of the credit drawn against a margin account to the current value of what backs it. The policy's _liquidation threshold_ is the LTV at which the risk engine begins closing the position. + +## Liquidation + +Closing a position to protect the lender's principal when an account's LTV crosses its liquidation threshold. On t1 a liquidation is an ordinary transaction through the signature gate — it is permitted by the policy, so the key signs it, and the borrower has no way to block it. See [Risk Engine and Liquidation](/intro/protocol/risk-engine). + ## TEE _Trusted Execution Environments_ ([TEEs](https://tee.fyi/)) are specialized hardware-based environments that isolate sensitive computations and data from the rest of the system, ensuring that data is processed correctly and (optionally) privately. @@ -12,10 +48,18 @@ In particular, TEEs provide verifiable computation guarantees through a process Optionally, TEEs can preserve privacy by keeping sensitive data and execution logic concealed from the broader system and external observers. +## Remote attestation + +The proof a TEE produces of which code it is running. For a lender it is the load-bearing piece: it is what turns "the policy is enforced" from a claim about t1's behavior into a claim about a published binary with a verifiable measurement. + ## ZKP A _zero-knowledge (ZK) proof_ is a cryptographic protocol that enables one entity (the prover) to convince another one (the verifier) that a particular claim is true without disclosing any details about the claim itself. ZKPs used in blockchains are mostly used due to their succinctness property—meaning that the work required by the verifier to check the proof is substantially smaller than the work of re-running the computation required to reach the claim independently. +## RTP + +_Real-Time Proving_ is the ability to prove state transitions in a rollup within one base layer block, which is 12 seconds for Ethereum L1. For example, this allows previous rollup deposits to be withdrawn immediately (real-time settlement). In the credit protocol it is what lets positions on separate venues resolve into one margin account with proven, rather than reported, state. + ## Reth [_Reth_](https://github.com/paradigmxyz/reth) (aka _Rust Ethereum_) is an Ethereum execution node implementation focused on being user-friendly, modular, and efficient. Reth is an execution client compatible with all Ethereum consensus client implementations that support the Engine API. As a full Ethereum node, Reth will allow users to sync the complete Ethereum blockchain from genesis and interact with it (and its historical state, if in archive mode) once synced. @@ -24,14 +68,10 @@ A _zero-knowledge (ZK) proof_ is a cryptographic protocol that enables one entit [_Execution Extensions_](https://www.paradigm.xyz/2024/05/reth-exex) (aka _ExEx_) are a feature of Reth that allows developers to receive comprehensive data about a newly “mined” block in an observer-listener pattern. Thanks to this, developers can perform actions based on certain changes on the blockchain in an efficient and seamless way. -## RTP - -_Real-Time Proving_ is the ability to prove state transitions in a rollup within one base layer block, which is 12 seconds for Ethereum L1. For example, this allows previous rollup deposits to be withdrawn immediately (real-time settlement). - ## Sequencer -_Sequencers_ are a highly decentralized set of nodes tasked with blindly finalizing the ordering of partially-encrypted transactions in a t1 block. Since Sequencers only order transactions rather than executing them (meaning lower hardware and network requirements, in particular no TEE requirement), t1 can achieve high decentralization and censorship resistance. Sequencers provide proofs of _Sequencing Consensus_. For details, check t1's [litepaper](/intro/resources#t1-litepaper). +A term from t1's [long-term network design](/intro/protocol/architecture). _Sequencers_ are a highly decentralized set of nodes tasked with blindly finalizing the ordering of partially-encrypted transactions in a t1 block. Since Sequencers only order transactions rather than executing them (meaning lower hardware and network requirements, in particular no TEE requirement), t1 can achieve high decentralization and censorship resistance. Sequencers provide proofs of _Sequencing Consensus_. For details, check t1's [litepaper](/intro/resources#t1-vision-litepaper). ## Executor -_Executors_ are a network of TEE-enabled nodes tasked with executing state changes given the ordered sequences of transaction bundles determined by the Sequencers. Executors provide proofs of _Execution Consensus_. For details, check t1's [litepaper](/intro/resources#t1-litepaper). +A term from t1's [long-term network design](/intro/protocol/architecture). _Executors_ are a network of TEE-enabled nodes tasked with executing state changes given the ordered sequences of transaction bundles determined by the Sequencers. Executors provide proofs of _Execution Consensus_. For details, check t1's [litepaper](/intro/resources#t1-vision-litepaper). diff --git a/docs/intro/protocol/architecture.md b/docs/intro/protocol/architecture.md index d47a02f36..49679b66d 100644 --- a/docs/intro/protocol/architecture.md +++ b/docs/intro/protocol/architecture.md @@ -1,9 +1,15 @@ --- id: architecture -title: Architecture -sidebar_position: 4 +title: Network Architecture +sidebar_position: 8 --- +:::note + +This page describes t1's long-term design as a permissionless, decentralized network, as set out in the [Vision Litepaper](../resources.md). The credit protocol running today is built on the TEE infrastructure described in [Programmable Custody](./programmable-custody.md), [TEE](./tee.md), and [Real-Time Proving](./rtp.md), and does not depend on the network below having shipped. + +::: + t1 is a TEE-enabled cross-chain application infrastructure that leverages defense-in-depth to achieve real-time proving. In the near term (v1), we're building towards achieving RTP with TEE proofs. In the long term, t1 will become a permissionless and decentralized network that will complement TEE proofs with crypto-economic security and bespoke zero-knowledge proofs. You can read more about our long term architecture in our [litepaper](https://docs.t1protocol.com/intro/resources). ### Network Architecture v1 diff --git a/docs/intro/protocol/introduction.md b/docs/intro/protocol/introduction.md index 22a45721b..0cb3c0da6 100644 --- a/docs/intro/protocol/introduction.md +++ b/docs/intro/protocol/introduction.md @@ -4,20 +4,44 @@ title: Introduction sidebar_position: 1 --- -Our infrastructure allows developers to build composable appchains across the Ethereum rollup ecosystem, enabling fragmenation-free, interoperable scaling. This is possible thanks to: +t1 is the permissionless credit protocol for DeFi. It lets a lender extend an undercollateralized loan to a borrower they have never met and have no way to sue, and still be repaid — without a legal agreement, without taking custody, and without demanding that the borrower post more collateral than they want to borrow. -- **Real-Time Proving**: Using Trusted Execution Environments (TEEs), t1 instantly proves its execution integrity to Ethereum and rollups. -- **Programmability**: t1 dApps can host arbitrary logic and are able to read from as well as write to Ethereum and rollups. +The mechanism is **programmable custody**. t1 provisions a margin account for each borrower, controlled by a Trusted Execution Environment (TEE). Verifiable code inside the TEE holds the account's private key and enforces the loan policy the lender set. The key signs a transaction only if that transaction satisfies the policy. The margin account, not the borrower, becomes the counterparty to the loan. -This allows for seamless cross-chain applications and shared liquidity. +The borrower gets direction rights over the capital and never gets withdrawal rights over it. That asymmetry is the whole protocol. -Developers can use TEE applications and smart contracts on t1 to: +## Permissionless credit has not been possible before -1. Use inputs from other rollups (as t1 runs partner rollup full nodes to read their state) -2. Write to applications on other rollups to update their state. +On-chain lending has had three answers to the problem of trusting a borrower, and each one costs something: -These primitives can be used to enhance existing applications that are deployed on multiple chains or build a new generation of cross-chain applications. +| Approach | What it costs | +| --- | --- | +| **Overcollateralized lending** (Aave, Morpho) | Capital sits idle to buy trust. To borrow, you must already have more than you want to borrow. | +| **Permissioned credit** | Replicates the traditional rails on-chain: master loan agreements, KYC, and a counterparty the lender can take to court. | +| **Custodial leverage** | The borrower hands over their assets, and the venue's solvency becomes their risk. | -In order to achieve this, t1 runs full nodes for other chains inside its TEE node in order to read from and write to Ethereum and partner rollups. Moreover, t1 uses expressive deposit contracts which can interact with dApps on all such supported chains. The secured TEE architecture allows t1 to prove the respective state transitions to other chains instantly. +Each one is a tax on capital efficiency, and each one closes the door on permissionless users. Programmable custody removes the need to trust the borrower at all, so none of the three prices has to be paid. -Combined, t1 cross-chain reads and writes provide the needed infrastructure for cross-chain applications and liquidity hubs. So far, apps had to deploy on multiple rollups, fragmenting liquidity and user experience. t1 enables cross-chain application workflows such as cross-chain vaults that automate the movement of user funds across different rollups to ensure that the user gets the highest yield in a non-custodial way. With t1, apps can deploy once and serve users anywhere. +## Leverage on anything + +Because enforcement lives in the key rather than in a smart contract, a t1 margin account is not confined to one execution environment. Smart-contract collateral can only be policed where a smart contract runs. A TEE-held key can be presented with any transaction, for any venue, and simply refuse to sign it. + +That matters because most of the interesting leverage now lives off-chain or on chains of its own: + +- Prediction markets — Polymarket +- Perpetual futures — Hyperliquid, Lighter +- Spot and memecoins — Robinhood Chain, on-chain AMMs + +Positions opened on separate venues and separate chains resolve into one margin account, because t1 also proves state across chains in real time. [Real-Time Proving](./rtp.md) is what makes a single collateral base legible to venues that never talk to each other. + +## What runs on it today + +t1's credit infrastructure already powers two applications: **amplifi**, a permissionless prime brokerage for prediction markets and perpDEXs offering 10× leverage on Polymarket, and **juiced**, which offers 5× leverage on memecoins before they list on perpDEXs. See [Ecosystem](../ecosystem.md). + +## Where to go next + +- [Programmable Custody](./programmable-custody.md) — how an encumbered key enforces a loan policy, and why a smart contract cannot. +- [Margin Accounts](./margin-accounts.md) — what a loan policy contains and how cross-venue positions consolidate. +- [Risk Engine and Liquidation](./risk-engine.md) — how exposure is monitored and how a position is closed. +- [Lending Pools](./lending-pools.md) — how capital is put behind a policy. +- [Offer leverage on your venue](../../integration/leverage.md) — for builders. diff --git a/docs/intro/protocol/lending-pools.md b/docs/intro/protocol/lending-pools.md new file mode 100644 index 000000000..09fce318e --- /dev/null +++ b/docs/intro/protocol/lending-pools.md @@ -0,0 +1,33 @@ +--- +id: lending-pools +title: Lending Pools +sidebar_position: 5 +--- + +A lending pool is where credit comes from. Lenders deposit capital into a pool, the pool defines the [loan policy](./margin-accounts.md) that every margin account borrowing from it is bound to, and borrowers draw against that capital to take leveraged positions on the venues the policy allows. + +## What a lender sets + +A pool is defined by its policy, and the policy is where a lender expresses their risk appetite: + +- **Permitted venues and assets** — the surface the capital is allowed to touch. +- **Maximum position size** — the ceiling on notional exposure per account. +- **Liquidation threshold** — the loan-to-value ratio at which the [risk engine](./risk-engine.md) closes a position. +- **Interest terms** — what borrowing from this pool costs. + +A lender who wants different parameters creates a different pool. Policies are not renegotiated per borrower, which is what keeps borrowing permissionless: there is nothing to approve, because everything that would have been approved was decided when the pool was created. + +## What a lender is and is not exposed to + +- **No counterparty exposure.** The borrower is not the counterparty. The margin account is, and it is incapable of absconding with the principal. +- **No legal exposure.** There is no master loan agreement to draft, no jurisdiction to enforce it in, and no debtor to pursue. +- **No KYC to administer.** Borrowers are anonymous by design, so there is no identity programme to run and no obligation inherited from having run one. +- **Market risk remains.** A position can still gap through its liquidation threshold. See [Residual risk](./risk-engine.md#residual-risk). + +## Repayment + +Repayment is structural rather than behavioral. When a position closes — by the borrower's choice or by liquidation — the proceeds settle through the account, principal and accrued interest return to the pool, and only the remainder is released to the borrower. The encumbered key will not sign a transaction that sends the pool's capital anywhere else, so there is no sequence of borrower actions that results in the pool being shorted while the account is solvent. + +## Providing liquidity + +Set up your own pool with your own parameters, or deposit into an existing one. Both paths are covered in [Provide Lending Liquidity](../../integration/lending.md). diff --git a/docs/intro/protocol/margin-accounts.md b/docs/intro/protocol/margin-accounts.md new file mode 100644 index 000000000..5c9b69707 --- /dev/null +++ b/docs/intro/protocol/margin-accounts.md @@ -0,0 +1,40 @@ +--- +id: margin-accounts +title: Margin Accounts +sidebar_position: 3 +--- + +A margin account is the unit t1 lends into. Each borrower gets one, provisioned by the TEE and governed by an [encumbered key](./programmable-custody.md). It holds the borrower's own deposit and the credit drawn against it, and it is the address that appears at every venue the borrower trades on. + +## The loan policy + +The policy is the contract between lender and borrower, expressed as code the key obeys rather than as prose someone enforces afterwards. It is set before the key exists and bound to it at creation, so it is immutable for the life of the account. + +A policy specifies at minimum: + +| Field | Meaning | +| --- | --- | +| **Venues** | Where the capital may be deployed, for example Polymarket and Hyperliquid. A transaction addressed anywhere else is not signed. | +| **Assets** | Which assets may be held or traded, for example USDC. | +| **Maximum size** | The ceiling on notional exposure the account may carry. | +| **Liquidation threshold** | The loan-to-value ratio at which the [risk engine](./risk-engine.md) begins closing the position. | + +Policies are per-pool, so a lender who wants tighter venue restrictions or a more conservative threshold creates a pool with those parameters rather than negotiating an exception. + +## One account, many venues + +A borrower who is long a prediction market on Polymarket and short a perpetual on Hyperliquid has two positions in two systems that share no state and no settlement layer. Their collateral requirement, however, is one number. + +t1 resolves this by reading the positions where they live and consolidating them into the account. The TEE runs full nodes for the chains t1 supports and reads off-chain venues through their own interfaces, and [Real-Time Proving](./rtp.md) makes those reads provable rather than merely asserted — a lender can verify the state the account's exposure was computed from. + +The practical consequence is that collateral is not fragmented across venues. Margin posted once backs positions everywhere the policy allows, and a gain on one venue offsets a loss on another inside the same account. + +## Lifecycle + +1. **Provision.** The borrower is issued an account. The TEE generates the key and binds the pool's policy to it. +2. **Deposit.** The borrower funds the account with their own capital, which serves as the margin. +3. **Draw.** Credit is extended from the [lending pool](./lending-pools.md) against that margin, up to the policy's limits. +4. **Trade.** The borrower directs the combined balance across the permitted venues. Every transaction passes the signature gate. +5. **Settle.** Positions close, the loan and accrued interest are repaid to the pool, and the remainder is released to the borrower. If exposure crosses the liquidation threshold first, the [risk engine](./risk-engine.md) closes the position and repayment happens from the proceeds. + +At no point in that sequence does the borrower hold the pool's capital, and at no point does the lender hold the borrower's positions. diff --git a/docs/intro/protocol/programmable-custody.md b/docs/intro/protocol/programmable-custody.md new file mode 100644 index 000000000..4c3387ac4 --- /dev/null +++ b/docs/intro/protocol/programmable-custody.md @@ -0,0 +1,53 @@ +--- +id: programmable-custody +title: Programmable Custody +sidebar_position: 2 +--- + +Programmable custody is the primitive the rest of t1 is built on. A margin account's private key lives inside a Trusted Execution Environment, bound at the moment of its creation to a loan policy it can never escape. The key will sign a transaction that satisfies the policy and will not sign one that does not. Nobody — not the borrower, not the lender, not t1 — can make it do otherwise. + +The academic name for a key that cannot be used freely by the party holding it is **private key encumbrance**. We call the applied form of it programmable custody. + +## How an account is created + +### 1. The policy is set + +A lender agrees to a loan policy — the permitted uses of funds and the conditions under which a position is liquidated — and deposits capital into a [lending pool](./lending-pools.md). The policy lives inside the TEE, not in a document and not in a contract someone can upgrade. + +### 2. An encumbered key is created + +The TEE generates a fresh keypair and binds the policy to it at creation. The private half never leaves the enclave. The binding cannot be redone: there is no code path that re-points an existing key at a different policy, so the policy a borrower agreed to is the policy that governs the account for its whole life. + +[Remote attestation](./tee.md) proves which code is running inside the enclave. A lender does not have to take t1's word for what the enforcement logic does; they can verify the measurement of the binary that holds the key. + +### 3. The borrower trades, the key enforces + +Every transaction the borrower wants — opening a position, closing one, moving collateral between venues — is presented to the key. So is every liquidation. The key signs the ones the policy permits. + +## The signature gate + +This is the entire enforcement surface, and it is worth being concrete about it. Two transactions arrive at the same account holding the same funds: + +| Transaction | Outcome | +| --- | --- | +| Open 5× long on Polymarket | **Signed** — the venue, the asset, and the resulting exposure all satisfy the policy. | +| Transfer 250,000 USDC to an external address | **Rejected** — no signature is ever produced. | + +The first is a use of funds the lender priced and agreed to. The second is the borrower walking off with the loan, and there is no version of the account that produces a signature for it. + +This is why the borrower can be anonymous and unKYC'd. The lender is not extending trust to a person; they are extending capital into an account whose behavior is fixed in advance. + +## Why this cannot be a smart contract + +The obvious objection is that a smart contract could hold the funds and check the same conditions. It could — but only inside its own execution environment, and that is not where trading happens anymore. + +Polymarket, Hyperliquid, and Lighter all run off-chain orderbooks. A position on any of them is not a state change a contract on some other chain can inspect, gate, or unwind. A smart contract asked to collateralize such a position can do one of two things: take custody of the funds and hand them to the venue (which is custodial leverage, with all of its risk), or refuse. + +A key does not have this limitation. It sits in front of the transaction rather than inside the destination, so the same enforcement works for an on-chain AMM swap, an off-chain orderbook order, and a transfer to a venue on a chain t1 does not control. One account, one policy, every venue. + +## What the borrower gets, and does not get + +- **Direction rights.** The borrower decides what the capital does: which venue, which market, which side, when to close. +- **No withdrawal rights.** The borrower cannot move the capital to an address they control. Not by signing, not by asking, not by compromising their own credentials. + +Profit realized inside the account is theirs, and is released to them through the policy's own settlement path once the loan and its interest are covered. The principal is never at their disposal. diff --git a/docs/intro/protocol/risk-engine.md b/docs/intro/protocol/risk-engine.md new file mode 100644 index 000000000..baab51383 --- /dev/null +++ b/docs/intro/protocol/risk-engine.md @@ -0,0 +1,39 @@ +--- +id: risk-engine +title: Risk Engine and Liquidation +sidebar_position: 4 +--- + +Programmable custody guarantees that the borrower cannot take the money. It does not, on its own, guarantee that the money survives a bad trade. That is the risk engine's job: watch every open position continuously, and close one before its losses reach the lender's principal. + +## Why the risk engine runs in the TEE + +An institutional lender will not deploy against a liquidation model they cannot inspect, which argues for putting it on-chain. Four things make that impractical: + +- **Real-time position monitoring.** Exposure has to be re-evaluated on every price tick across every venue, not once per block. +- **Dynamic loan-to-value.** The safe leverage on a position depends on the depth of the book behind it, which moves continuously. +- **Cross-chain price feeds.** Prices come from venues on other chains and from off-chain orderbooks with no on-chain representation at all. +- **Liquidation execution.** Unwinding a position means placing orders at a venue, which a contract on another chain cannot do. + +Each of those is either impossible or ruinously gas-expensive inside a smart contract. The TEE resolves the tension: the logic runs off-chain at the speed the markets require, and its results are attested on-chain, so lenders get the auditability they would have had from a contract without the constraints. + +## How a liquidation happens + +A liquidation is not a separate mechanism bolted onto the account. It is a transaction like any other, and it goes through the same signature gate. + +1. The engine values every open position against current prices and computes the account's loan-to-value ratio. +2. When that ratio crosses the policy's liquidation threshold, the engine constructs the closing transactions. +3. Those transactions satisfy the policy — closing a position to protect the lender is exactly what the policy is for — so the encumbered key signs them. +4. Proceeds repay the pool's principal and accrued interest. Whatever remains belongs to the borrower. + +The borrower cannot block step 3, because the borrower was never the party holding the key. There is no "cooperation" step to fail, which is why the loan can be undercollateralized in the first place. + +## What lenders can verify + +The risk engine is open-source, so its behavior can be read rather than inferred. Liquidations are attested in real time, so a lender does not learn about a close after the fact from a report: the attestation is evidence that the enclave running the published logic produced that decision from that state. + +Combined with [Real-Time Proving](./rtp.md) on the cross-chain reads the engine consumes, that closes the loop from market state to liquidation decision to repayment, with no step where a lender is asked to take somebody's word for it. + +## Residual risk + +Undercollateralized lending is not risk-free lending, and t1 does not claim otherwise. A position can gap through its liquidation threshold faster than any engine can close it, and a book can be too thin to absorb the unwind at the price the model assumed. The engine's job is to make that outcome rare and bounded, not impossible; the policy's maximum size and liquidation threshold are the parameters that set how rare and how bounded, and they are the lender's to choose per pool. diff --git a/docs/intro/protocol/rtp.md b/docs/intro/protocol/rtp.md index ea62993fc..14059272a 100644 --- a/docs/intro/protocol/rtp.md +++ b/docs/intro/protocol/rtp.md @@ -1,11 +1,21 @@ --- id: rtp title: Real-Time Proving -sidebar_position: 2 +sidebar_position: 7 --- -Real-Time Proving (RTP) enables immediate validation of computations, allowing systems to verify correct execution with minimal latency. This capability is particularly impactful in in blockchain ecosystems such as Ethereum, where the proliferation of layer 2 rollups has led to liquidity fragmentation and overall user experience degredation. RTP enhances composability by allowing chains and rollups to securely and efficiently interact with one another in near real-time, facilitating cross-chain operations such as asset transfers, contract calls, and state updates. +Real-Time Proving (RTP) enables immediate validation of computations, allowing systems to verify correct execution with minimal latency. Within a Trusted Execution Environment, the computation of a state transition can be securely executed, producing cryptographic proofs that attest to its correctness. These proofs can be submitted to Ethereum or another chain immediately, without the delays associated with optimistic or zero-knowledge rollups. Proving via multisigs or proof-of-stake can also be fast, but multisig systems do not provide reliability and proof-of-stake systems are very expensive to run. -Within a Trusted Execution Environment (TEE), the computation of rollup state transitions can be securely executed, producing cryptographic proofs that attest to the correctness of these transitions. These proofs can be immediately submitted to other chains or Ethereum without requiring the delays associated with traditional mechanisms like ZK rollups or optimistic rollups. While proving via multisigs and proof-of-stake (PoS) can be fast, these methods face significant limitations. Multisig systems don'provide reliability and PoS systems are very expensive to run. +## Why credit needs it -By leveraging TEEs, t1 allows chains and rollups to have near-instantaneous interactions with other chains. This real-time interaction reduces friction for developers and users, unlocking advanced use cases such as dynamic liquidity provisioning and seamless multi-chain dApp experiences. +A margin account is only useful if its collateral can back positions wherever the borrower wants to trade, and that requires knowing what those positions are worth right now, on chains and venues that do not share a settlement layer. + +RTP is what makes that knowledge trustworthy rather than merely asserted: + +- **Cross-venue collateral.** Positions held on separate venues resolve into one [margin account](./margin-accounts.md) because the reads behind them are proven, not reported. +- **Risk decisions a lender can check.** The [risk engine](./risk-engine.md) acts on cross-chain state; proving that state is what lets a lender audit a liquidation rather than trust it. +- **Settlement without a delay window.** Repayments and withdrawals do not have to wait out a seven-day challenge period or an hours-long proving queue, so capital returns to the pool at the speed the position closed. + +## Beyond credit + +The same primitive is what enhances composability generally, letting chains and rollups interact securely in near real time for asset transfers, contract calls, and state updates. t1 exposes it directly to developers as [xChainRead](../../integration/xChainRead/overview.md), a cross-chain read verification primitive that any contract can call. diff --git a/docs/intro/protocol/tee.md b/docs/intro/protocol/tee.md index 9d1131201..7d10cc3d5 100644 --- a/docs/intro/protocol/tee.md +++ b/docs/intro/protocol/tee.md @@ -1,16 +1,26 @@ --- id: tee title: TEE -sidebar_position: 3 +sidebar_position: 6 --- Trusted Execution Environments (TEEs) are specialized hardware-based environments that isolate sensitive computations and data from the rest of the system, ensuring that data is processed correctly and privately. In particular, TEEs provide verifiable computation guarantees through a process called “Remote Attestation”, which proves to external parties that the TEE is running a specific, unmodified piece of software (bytecode) without any tampering. Verifiers can then use this proof to confirm that the TEE and its output is trustworthy. Additionally, TEEs can preserve privacy by keeping sensitive data and execution logic concealed from the system operator and external observers. In other words, TEEs are secure hardware areas that protect sensitive data and computations from tampering or unauthorized access. -At t1, we are using TEEs to enable Real-Time Proving. t1 architecture enables cross-chain composability by leveraging TEEs that: +## What t1 uses TEEs for -- reliably read data from partner rollups by running full nodes in t1 node infrastructure -- prove t1 dApp execution to Ethereum and supported rollups in real-time +Three of t1's four uses are what make undercollateralized credit possible, and the fourth is what makes the collateral legible across venues: -This architecture enables us to achieve a single-block-only asynchrony window with Ethereum (12 seconds) and supported rollup. This approach is a substantial improvement over the current seven-day window in Optimistic Rollups and hours-long window in Zero-Knowledge Rollups, anda also over synchronous composability approaches which require a form of shared sequencing across rollups. +- **Hold encumbered keys.** A margin account's private key is generated inside the enclave and never leaves it. The loan policy is bound to the key at creation, and the key signs only transactions that satisfy it. See [Programmable Custody](./programmable-custody.md). +- **Run the risk engine.** Position monitoring, dynamic loan-to-value, and liquidation execution run inside the enclave at market speed, and their results are attested on-chain. See [Risk Engine and Liquidation](./risk-engine.md). +- **Read other chains reliably.** t1 runs full nodes for supported chains inside its node infrastructure, so an account's exposure is computed from state that was actually read rather than reported. +- **Prove execution in real time.** State transitions are proven to Ethereum and supported rollups within a single block. See [Real-Time Proving](./rtp.md). -In addition to RTP and cross-chain communication, TEEs allow t1 to support encrypted inputs. An encrypted mempool prevents adversarial reordering, such as sandwich attacks, where an attacker observes a pending transaction and places trades before (front-running) and after (back-running) it, profiting at the expense of regular users. Sandwich attacks cost Ethereum users over [$100mn every year](https://eigenphi.io/mev/ethereum/sandwich). An encrypted mempool also facilitates use cases like sealed-bid auctions and information-incomplete games. +Remote attestation is what ties these together for a lender. It proves which binary is holding the key and running the risk engine, so "the policy is enforced" is a claim about published code with a verifiable measurement, not a claim about t1's good behavior. + +## Real-time settlement + +This architecture enables us to achieve a single-block-only asynchrony window with Ethereum (12 seconds) and supported rollups. This approach is a substantial improvement over the current seven-day window in Optimistic Rollups and hours-long window in Zero-Knowledge Rollups, and also over synchronous composability approaches which require a form of shared sequencing across rollups. + +## Encrypted inputs + +In addition to the above, TEEs allow t1 to support encrypted inputs. An encrypted mempool prevents adversarial reordering, such as sandwich attacks, where an attacker observes a pending transaction and places trades before (front-running) and after (back-running) it, profiting at the expense of regular users. Sandwich attacks cost Ethereum users over [$100mn every year](https://eigenphi.io/mev/ethereum/sandwich). An encrypted mempool also facilitates use cases like sealed-bid auctions and information-incomplete games. This capability belongs to the decentralized network described in [Network Architecture](./architecture.md). diff --git a/docs/intro/research.md b/docs/intro/research.md index ac20a21da..34ac482d4 100644 --- a/docs/intro/research.md +++ b/docs/intro/research.md @@ -1,12 +1,12 @@ --- id: research title: Research -sidebar_position: 2 +sidebar_position: 3 --- -## Research +Our current work is on permissionless credit: how a loan policy can be enforced by a key rather than by collateral or by a contract, and what that makes possible for leverage on venues no smart contract can reach. [Programmable Custody](/intro/protocol/programmable-custody) is the shortest account of it. -The rollup landscape is changing rapidly, and we at t1 strive to stay at the bleeding edge. Our research focuses on improving scalable composability among and between blockchains and rollups. +The articles below are the earlier body of work on rollup fragmentation and real-time proving, the infrastructure the credit protocol is built on. ## **t1** is the cross-chain application infra to enable better web3 UX diff --git a/docs/intro/resources.md b/docs/intro/resources.md index 640cf3568..e885cf779 100644 --- a/docs/intro/resources.md +++ b/docs/intro/resources.md @@ -1,13 +1,13 @@ --- id: resources title: Resources -sidebar_position: 3 +sidebar_position: 4 --- ## t1 Vision Litepaper -Read up on t1's aspired long-term design: [**t1 Vision Litepaper**](https://docs.t1protocol.com/t1-vision-litepaper.pdf). +t1's aspired long-term design as a decentralized network: [**t1 Vision Litepaper**](https://docs.t1protocol.com/t1-vision-litepaper.pdf). It describes the network set out in [Network Architecture](/intro/protocol/architecture), which the credit protocol running today does not depend on. ## t1's TEE Architecture -Read about t1's planned [**TEE Architecture and Remote Attestation**](https://docs.t1protocol.com/t1-tee-architecture.pdf). +Read about t1's planned [**TEE Architecture and Remote Attestation**](https://docs.t1protocol.com/t1-tee-architecture.pdf), the hardware trust model that [programmable custody](/intro/protocol/programmable-custody) rests on. diff --git a/docusaurus.config.mjs b/docusaurus.config.mjs index f64323b22..3f51d3d48 100644 --- a/docusaurus.config.mjs +++ b/docusaurus.config.mjs @@ -108,7 +108,7 @@ const config = { }, { label: 'Discord', - href: 'https://discord.com/invite/nbvyXZHgke', + href: 'https://discord.com/invite/qVEUA6jmGZ', }, ], }, diff --git a/src/pages/index.tsx b/src/pages/index.tsx index 6a454639d..f1e1008e5 100644 --- a/src/pages/index.tsx +++ b/src/pages/index.tsx @@ -27,16 +27,16 @@ export const actions = [ text: `Get familiar with the core concepts of the t1 Protocol.`, }, { - title: 't1 Beta Portal', - icon: Chain, - to: 'https://beta.t1protocol.com/', - text: `Experience real time cross-chain interactions with t1.`, + title: 'Programmable Custody', + icon: BookOpen, + to: '/intro/protocol/programmable-custody', + text: `How an encumbered key enforces a loan policy, and why a smart contract cannot.`, }, { - title: 't1 Smart Contracts', - icon: BookOpen, - to: 'https://github.com/t1protocol/t1/tree/canary/contracts', - text: `Learn about the architecture of t1 smart contracts.`, + title: 'Ecosystem', + icon: Chain, + to: '/intro/ecosystem', + text: `The applications already running on t1's credit infrastructure.`, }, ] @@ -48,20 +48,29 @@ export const developerSafeLinks = [ }, ] -export const dAppGuides = [ +export const ecosystemApps = [ { - title: 't1 RTP Intent Bridge', - text: 'Real-Time Proving for fast solver repayment and tight spreads.', - to: 'https://beta.t1protocol.com/swap', + title: 'amplifi', + text: 'Permissionless prime brokerage for prediction markets and perpDEXs. 10× leverage on Polymarket.', + to: '/intro/ecosystem#amplifi', }, { - title: 'More products coming soon', - text: 'Stay tuned for additional dApps built on t1.', - to: '', - disabled: true, + title: 'juiced', + text: 'Leverage on memecoins before they list on perpDEXs. 5× on Robinhood Chain.', + to: '/intro/ecosystem#juiced', }, ] -export const smartContractGuides = [ +export const integrationGuides = [ + { + title: 'Offer Leverage', + text: 'Let your users trade with borrowed capital on your venue without ever holding it yourself. t1 issues the margin accounts, enforces the loan policy, and runs liquidation.', + to: '/integration/leverage', + }, + { + title: 'Provide Liquidity', + text: 'Deposit into a lending pool, or set one up with your own venues, position limits, and liquidation threshold. Repayment is enforced by the account, not promised by the borrower.', + to: '/integration/lending', + }, { title: 'Cross-Chain Reads', text: "Request data to be read from other chains and proven by t1 back to your chain. You'll then be able to use the result in your contract. This primitive is useful in ERC-7683-enabled cross-chain intents, among others.", @@ -295,7 +304,7 @@ const SafeLinksContainer = styled.div` export default function Home() { return ( - + - Our infrastructure allows developers to build composable appchains across the Ethereum rollup ecosystem, - enabling fragmenation-free, interoperable scaling. This is possible thanks to: + t1 is the permissionless credit protocol for DeFi. Lenders extend undercollateralized loans to anyone, + and get repaid without a legal agreement, a custodian, or a pile of idle collateral. This is possible + thanks to: - Real-Time Proving: Using Trusted Execution Environments (TEEs), t1 instantly proves - its execution integrity to Ethereum and rollups. + Programmable custody: Each borrower gets a margin account whose private key lives in + a Trusted Execution Environment (TEE) and signs only the transactions their loan policy permits. The + borrower can direct the capital and can never take it. - Programmability: t1 dApps can host arbitrary logic and are able to read from as well - as write to Ethereum and rollups. + Real-Time Proving: Positions held on separate venues and chains resolve into one + margin account, from state that is proven rather than reported. - This allows for seamless cross-chain applications and shared liquidity. + + Together they put leverage on venues no smart contract can reach: prediction markets, off-chain + perpetual orderbooks, and memecoins. + @@ -358,10 +372,8 @@ export default function Home() { <> {/* Smart Contracts Section */} -
- Integrate Your Smart Contracts -
-

Build with t1's cross-chain capabilities

+
Integrate with t1
+

Three ways to build on the credit protocol

- {smartContractGuides.map((action) => ( + {integrationGuides.map((action) => ( @@ -391,8 +403,8 @@ export default function Home() { {/* Explore dApps Section */} -
Explore Showcase dApps
-

See what's possible with t1 infrastructure

+
Built on t1
+

Applications already running on t1's credit infrastructure

- {dAppGuides.map((action) => ( + {ecosystemApps.map((action) => ( - +
From 2bb943f0955e05593e064279a4532b20768d530e Mon Sep 17 00:00:00 2001 From: Orest Tarasiuk <830847+OrestTa@users.noreply.github.com> Date: Wed, 23 Sep 2026 10:10:11 +0200 Subject: [PATCH 2/5] docs: drop perpDEXs from the unreachable-venues line, and pull back overclaims Perpetual DEXs offer leverage natively, so listing them as venues that cannot get leverage without t1 was wrong. Removed from the homepage. An adversarial review of the rest of the PR found claims the docs made that the source material does not support, three of them checkable and false: - amplifi and juiced were described as running on the same TEE-held margin accounts and risk engine. amplifi keeps wallet keys in Postgres (003_polymarket.sql, owner_private_key, TODO: encrypt this later) and has no enclave code. The ecosystem page no longer asserts a mechanism for the two shipped apps. - "The risk engine is open-source" invited a reader to go read code that is not public; t1protocol/amplifi is private. Replaced with what attestation actually gives a lender. - Interest was listed inside the immutable loan policy. The shipped RateAdminLendingPool exposes setRateParams to owner and rateAdmin, and the curve is utilization-kinked, so the rate moves by design. Interest is now a pool parameter, separate from the bound policy. Also softened two absolute guarantees no TEE deployment supports, narrowed the legal and KYC claims back to what the landing page says, fixed a withdrawal-rights contradiction on the ecosystem page, scoped the present-tense rollup definition in architecture.md, dropped a rollup-exit latency bullet from rtp.md that does not apply to pool repayment, removed an invented integration promise, repointed the footer Integration link at the new overview, and corrected three British spellings. Co-Authored-By: Claude Opus 5 --- docs/integration/integration.md | 2 +- docs/integration/lending.md | 9 ++++----- docs/integration/leverage.md | 2 +- docs/intro/ecosystem.md | 6 +++--- docs/intro/glossary.md | 2 +- docs/intro/protocol/architecture.md | 2 +- docs/intro/protocol/lending-pools.md | 11 ++++++----- docs/intro/protocol/programmable-custody.md | 6 +++--- docs/intro/protocol/risk-engine.md | 2 +- docs/intro/protocol/rtp.md | 1 - docs/intro/protocol/tee.md | 4 ++-- docusaurus.config.mjs | 2 +- src/pages/index.tsx | 3 +-- 13 files changed, 25 insertions(+), 27 deletions(-) diff --git a/docs/integration/integration.md b/docs/integration/integration.md index a5a4b2374..98bba1174 100644 --- a/docs/integration/integration.md +++ b/docs/integration/integration.md @@ -16,7 +16,7 @@ You operate a venue — an exchange, a prediction market, a trading app — and ## Provide lending liquidity -You have capital and want it earning on undercollateralized loans without counterparty exposure, a legal agreement, or a KYC programme to administer. Set up a pool with your own parameters, or deposit into an existing one. +You have capital and want it earning on undercollateralized loans without counterparty exposure, a legal agreement, or a KYC program to administer. Set up a pool with your own parameters, or deposit into an existing one. → [Provide Lending Liquidity](./lending.md) diff --git a/docs/integration/lending.md b/docs/integration/lending.md index 46740c83c..374038f6d 100644 --- a/docs/integration/lending.md +++ b/docs/integration/lending.md @@ -10,11 +10,10 @@ Deposit capital into a t1 [lending pool](../intro/protocol/lending-pools.md) and ## What you are relying on -- **Open-source risk engine.** The liquidation logic is published; you can read it rather than infer it from a term sheet. -- **Liquidations attested in real time.** Each decision is attested by the enclave that made it, so you can verify a close rather than receive a report of one. -- **Risk parameters customizable per pool.** Venues, assets, maximum position size, liquidation threshold, and interest terms are yours to set. +- **Liquidations attested in real time.** Each decision is attested by the enclave that made it, so you can verify a close rather than infer it from a term sheet or take it on report. +- **Risk parameters customizable per pool.** Venues, assets, maximum position size, liquidation threshold, and interest are yours to set. - **No counterparty legal exposure.** The margin account is the counterparty, so there is no agreement to draft and no debtor to pursue. -- **Permissionless borrowers, no KYC to administer.** Borrowers are anonymous by design; you run no identity programme and inherit no obligation from having run one. +- **Permissionless borrowers, no KYC to administer.** Borrowers are anonymous by design, so you run no identity program. What you are still exposed to is market risk: a position can gap through its liquidation threshold, or the book behind it can be too thin to unwind at the modeled price. [Residual risk](../intro/protocol/risk-engine.md#residual-risk) covers this, and the maximum size and liquidation threshold you set are the levers over it. @@ -22,7 +21,7 @@ What you are still exposed to is market risk: a position can gap through its liq **Deposit into an existing pool.** Fastest path. You accept the pool's policy as written and start earning on its terms. -**Set up your own pool.** You define the policy — which venues the capital may reach, how much exposure a single account may carry, where liquidation triggers, and what borrowing costs. Every margin account that borrows from your pool is bound to that policy at the moment its key is created, and the binding cannot be changed afterwards. +**Set up your own pool.** You define the policy — which venues the capital may reach, how much exposure a single account may carry, and where liquidation triggers. Every margin account that borrows from your pool is bound to that policy at the moment its key is created, and the binding cannot be changed afterwards. You also set what borrowing costs, which is a pool parameter rather than part of that binding and can be retuned. ## Get in touch diff --git a/docs/integration/leverage.md b/docs/integration/leverage.md index b6438d5da..8b8ad8e4f 100644 --- a/docs/integration/leverage.md +++ b/docs/integration/leverage.md @@ -23,7 +23,7 @@ They keep direction rights over the capital and never get withdrawal rights over The shape of the work depends on whether your venue settles on-chain or runs an off-chain orderbook, but the pieces are the same in both cases: 1. **Agree the policy.** Which venues and assets the account may touch, the maximum position size, and the liquidation threshold. This is what your lenders are pricing, and it is bound into the account's key at creation. -2. **Connect the venue.** t1's risk engine needs to read positions and prices from your venue, and the encumbered key needs to be able to place and cancel orders on it — both through your existing interfaces. +2. **Connect the venue.** t1's risk engine needs to read positions and prices from your venue, and the encumbered key needs to be able to place and cancel orders on it. 3. **Point your frontend at the account.** Your users deposit into their margin account and trade from it. The signature gate is transparent to them until it rejects something the policy forbids. 4. **Source the liquidity.** Either bring your own lenders or draw on existing pools. diff --git a/docs/intro/ecosystem.md b/docs/intro/ecosystem.md index d37b51e8f..bb116199c 100644 --- a/docs/intro/ecosystem.md +++ b/docs/intro/ecosystem.md @@ -4,17 +4,17 @@ title: Ecosystem sidebar_position: 2 --- -t1's credit infrastructure already powers two live applications. Both use the same [margin accounts](./protocol/margin-accounts.md) and the same [risk engine](./protocol/risk-engine.md); they differ in the venue they lend against and the policy their pools run. +t1's credit infrastructure already powers two applications. They differ in the venue they lend against and the policy their pools run. ## amplifi -**Permissionless prime brokerage for prediction markets and perpDEXs.** Up to **10×** leverage on Polymarket, with no KYC and no custody transfer: a trader deposits margin, draws credit against it, and trades a Polymarket position from an account that cannot pay out to anyone but the pool and themselves. +**Permissionless prime brokerage for prediction markets and perpDEXs.** Up to **10×** leverage on Polymarket, with no KYC and no custody transfer: a trader deposits margin, draws credit against it, and trades a Polymarket position from an account that can only repay the pool and release what is left once the loan is covered. [amplifi.finance →](https://amplifi.finance/?utm_source=t1-docs&utm_medium=website&utm_campaign=t1docs-credit&utm_content=ecosystem-page&utm_term=10x-polymarket) ## juiced -**Leverage on memecoins before they list on perpDEXs.** Up to **5×** on Robinhood Chain. The interesting case for programmable custody, because these markets have no perpetual venue to borrow against and no on-chain lending market deep enough to collateralize them. +**Leverage on memecoins before they list on perpDEXs.** Up to **5×** on Robinhood Chain. The interesting case for programmable custody, because these markets have no perpetual venue to borrow against. [juiced.exchange →](https://juiced.exchange/?utm_source=t1-docs&utm_medium=website&utm_campaign=t1docs-credit&utm_content=ecosystem-page&utm_term=robinhood-chain) diff --git a/docs/intro/glossary.md b/docs/intro/glossary.md index 12a67252d..b6405b419 100644 --- a/docs/intro/glossary.md +++ b/docs/intro/glossary.md @@ -22,7 +22,7 @@ The account t1 lends into: one per borrower, holding their own deposit plus the ## Loan policy -The rules an encumbered key enforces: the permitted venues and assets, the maximum position size, the liquidation threshold, and the interest terms. Set by the lender when a [lending pool](#lending-pool) is created, and immutable thereafter. +The rules an encumbered key enforces: the permitted venues and assets, the maximum position size, and the liquidation threshold. Set by the lender when a [lending pool](#lending-pool) is created, and immutable thereafter. A pool's interest rate is a separate parameter and is not fixed this way. ## Signature gate diff --git a/docs/intro/protocol/architecture.md b/docs/intro/protocol/architecture.md index 49679b66d..d1718bbcc 100644 --- a/docs/intro/protocol/architecture.md +++ b/docs/intro/protocol/architecture.md @@ -10,7 +10,7 @@ This page describes t1's long-term design as a permissionless, decentralized net ::: -t1 is a TEE-enabled cross-chain application infrastructure that leverages defense-in-depth to achieve real-time proving. In the near term (v1), we're building towards achieving RTP with TEE proofs. In the long term, t1 will become a permissionless and decentralized network that will complement TEE proofs with crypto-economic security and bespoke zero-knowledge proofs. You can read more about our long term architecture in our [litepaper](https://docs.t1protocol.com/intro/resources). +As a network, t1 is a TEE-enabled cross-chain application infrastructure that leverages defense-in-depth to achieve real-time proving. In the near term (v1), we're building towards achieving RTP with TEE proofs. In the long term, t1 will become a permissionless and decentralized network that will complement TEE proofs with crypto-economic security and bespoke zero-knowledge proofs. You can read more about our long term architecture in our [litepaper](https://docs.t1protocol.com/intro/resources). ### Network Architecture v1 diff --git a/docs/intro/protocol/lending-pools.md b/docs/intro/protocol/lending-pools.md index 09fce318e..3413f1957 100644 --- a/docs/intro/protocol/lending-pools.md +++ b/docs/intro/protocol/lending-pools.md @@ -4,7 +4,7 @@ title: Lending Pools sidebar_position: 5 --- -A lending pool is where credit comes from. Lenders deposit capital into a pool, the pool defines the [loan policy](./margin-accounts.md) that every margin account borrowing from it is bound to, and borrowers draw against that capital to take leveraged positions on the venues the policy allows. +A lending pool is where credit comes from. Lenders deposit capital into a pool, the pool defines the [loan policy](./margin-accounts.md#the-loan-policy) that every margin account borrowing from it is bound to, and borrowers draw against that capital to take leveraged positions on the venues the policy allows. ## What a lender sets @@ -13,15 +13,16 @@ A pool is defined by its policy, and the policy is where a lender expresses thei - **Permitted venues and assets** — the surface the capital is allowed to touch. - **Maximum position size** — the ceiling on notional exposure per account. - **Liquidation threshold** — the loan-to-value ratio at which the [risk engine](./risk-engine.md) closes a position. -- **Interest terms** — what borrowing from this pool costs. -A lender who wants different parameters creates a different pool. Policies are not renegotiated per borrower, which is what keeps borrowing permissionless: there is nothing to approve, because everything that would have been approved was decided when the pool was created. +Separately, the lender sets what borrowing from the pool costs. Interest is a pool parameter rather than part of the bound policy: the rate curve responds to utilization and can be retuned, while the four fields above are fixed for the life of every account created under them. + +A lender who wants different policy parameters creates a different pool. Policies are not renegotiated per borrower, which is what keeps borrowing permissionless: there is nothing to approve, because everything that would have been approved was decided when the pool was created. ## What a lender is and is not exposed to - **No counterparty exposure.** The borrower is not the counterparty. The margin account is, and it is incapable of absconding with the principal. -- **No legal exposure.** There is no master loan agreement to draft, no jurisdiction to enforce it in, and no debtor to pursue. -- **No KYC to administer.** Borrowers are anonymous by design, so there is no identity programme to run and no obligation inherited from having run one. +- **No counterparty legal exposure.** There is no master loan agreement to draft and no debtor to pursue. +- **No KYC to administer.** Borrowers are anonymous by design, so there is no identity program to run. - **Market risk remains.** A position can still gap through its liquidation threshold. See [Residual risk](./risk-engine.md#residual-risk). ## Repayment diff --git a/docs/intro/protocol/programmable-custody.md b/docs/intro/protocol/programmable-custody.md index 4c3387ac4..bf67fad60 100644 --- a/docs/intro/protocol/programmable-custody.md +++ b/docs/intro/protocol/programmable-custody.md @@ -4,7 +4,7 @@ title: Programmable Custody sidebar_position: 2 --- -Programmable custody is the primitive the rest of t1 is built on. A margin account's private key lives inside a Trusted Execution Environment, bound at the moment of its creation to a loan policy it can never escape. The key will sign a transaction that satisfies the policy and will not sign one that does not. Nobody — not the borrower, not the lender, not t1 — can make it do otherwise. +Programmable custody is the primitive the rest of t1 is built on. A margin account's private key lives inside a Trusted Execution Environment, bound at the moment of its creation to a loan policy it can never escape. The key will sign a transaction that satisfies the policy and will not sign one that does not. No party, t1 included, can direct the key outside the policy without running different code inside the enclave, which changes the attestation measurement any lender can check. The academic name for a key that cannot be used freely by the party holding it is **private key encumbrance**. We call the applied form of it programmable custody. @@ -35,7 +35,7 @@ This is the entire enforcement surface, and it is worth being concrete about it. The first is a use of funds the lender priced and agreed to. The second is the borrower walking off with the loan, and there is no version of the account that produces a signature for it. -This is why the borrower can be anonymous and unKYC'd. The lender is not extending trust to a person; they are extending capital into an account whose behavior is fixed in advance. +This is why the borrower can be anonymous, with no KYC. The lender is not extending trust to a person; they are extending capital into an account whose behavior is fixed in advance. ## Why this cannot be a smart contract @@ -48,6 +48,6 @@ A key does not have this limitation. It sits in front of the transaction rather ## What the borrower gets, and does not get - **Direction rights.** The borrower decides what the capital does: which venue, which market, which side, when to close. -- **No withdrawal rights.** The borrower cannot move the capital to an address they control. Not by signing, not by asking, not by compromising their own credentials. +- **No withdrawal rights.** The borrower cannot move the capital to an address they control: there is no transaction they can submit, and no request they can make, that produces that signature. Profit realized inside the account is theirs, and is released to them through the policy's own settlement path once the loan and its interest are covered. The principal is never at their disposal. diff --git a/docs/intro/protocol/risk-engine.md b/docs/intro/protocol/risk-engine.md index baab51383..5dca50bb7 100644 --- a/docs/intro/protocol/risk-engine.md +++ b/docs/intro/protocol/risk-engine.md @@ -30,7 +30,7 @@ The borrower cannot block step 3, because the borrower was never the party holdi ## What lenders can verify -The risk engine is open-source, so its behavior can be read rather than inferred. Liquidations are attested in real time, so a lender does not learn about a close after the fact from a report: the attestation is evidence that the enclave running the published logic produced that decision from that state. +Liquidations are attested in real time, so a lender does not learn about a close after the fact from a report: the attestation is evidence that a specific, identified binary produced that decision from that state. That is what makes the engine checkable without the lender having to trust an operator's account of it. Combined with [Real-Time Proving](./rtp.md) on the cross-chain reads the engine consumes, that closes the loop from market state to liquidation decision to repayment, with no step where a lender is asked to take somebody's word for it. diff --git a/docs/intro/protocol/rtp.md b/docs/intro/protocol/rtp.md index 14059272a..dbac225a0 100644 --- a/docs/intro/protocol/rtp.md +++ b/docs/intro/protocol/rtp.md @@ -14,7 +14,6 @@ RTP is what makes that knowledge trustworthy rather than merely asserted: - **Cross-venue collateral.** Positions held on separate venues resolve into one [margin account](./margin-accounts.md) because the reads behind them are proven, not reported. - **Risk decisions a lender can check.** The [risk engine](./risk-engine.md) acts on cross-chain state; proving that state is what lets a lender audit a liquidation rather than trust it. -- **Settlement without a delay window.** Repayments and withdrawals do not have to wait out a seven-day challenge period or an hours-long proving queue, so capital returns to the pool at the speed the position closed. ## Beyond credit diff --git a/docs/intro/protocol/tee.md b/docs/intro/protocol/tee.md index 7d10cc3d5..087f0e7b9 100644 --- a/docs/intro/protocol/tee.md +++ b/docs/intro/protocol/tee.md @@ -8,14 +8,14 @@ Trusted Execution Environments (TEEs) are specialized hardware-based environment ## What t1 uses TEEs for -Three of t1's four uses are what make undercollateralized credit possible, and the fourth is what makes the collateral legible across venues: +t1 uses them to make undercollateralized credit possible, and to make the collateral legible across the venues a borrower trades on: - **Hold encumbered keys.** A margin account's private key is generated inside the enclave and never leaves it. The loan policy is bound to the key at creation, and the key signs only transactions that satisfy it. See [Programmable Custody](./programmable-custody.md). - **Run the risk engine.** Position monitoring, dynamic loan-to-value, and liquidation execution run inside the enclave at market speed, and their results are attested on-chain. See [Risk Engine and Liquidation](./risk-engine.md). - **Read other chains reliably.** t1 runs full nodes for supported chains inside its node infrastructure, so an account's exposure is computed from state that was actually read rather than reported. - **Prove execution in real time.** State transitions are proven to Ethereum and supported rollups within a single block. See [Real-Time Proving](./rtp.md). -Remote attestation is what ties these together for a lender. It proves which binary is holding the key and running the risk engine, so "the policy is enforced" is a claim about published code with a verifiable measurement, not a claim about t1's good behavior. +Remote attestation is what ties these together for a lender. It proves which binary is holding the key and running the risk engine, so "the policy is enforced" is a claim about a specific binary with a verifiable measurement, not a claim about t1's good behavior. ## Real-time settlement diff --git a/docusaurus.config.mjs b/docusaurus.config.mjs index 3f51d3d48..8140c18e6 100644 --- a/docusaurus.config.mjs +++ b/docusaurus.config.mjs @@ -78,7 +78,7 @@ const config = { }, { label: 'Integration', - to: '/integration/xChainRead/overview', + to: '/integration', }, ], }, diff --git a/src/pages/index.tsx b/src/pages/index.tsx index f1e1008e5..acf1434eb 100644 --- a/src/pages/index.tsx +++ b/src/pages/index.tsx @@ -345,8 +345,7 @@ export default function Home() { - Together they put leverage on venues no smart contract can reach: prediction markets, off-chain - perpetual orderbooks, and memecoins. + Together they put leverage on venues no smart contract can reach: prediction markets and memecoins. From 95b43d06b6884191e9574facbaf9139fd675fcac Mon Sep 17 00:00:00 2001 From: Orest Tarasiuk <830847+OrestTa@users.noreply.github.com> Date: Wed, 23 Sep 2026 10:12:57 +0200 Subject: [PATCH 3/5] docs: keep xChainRead out of the two central integration surfaces Cross-Chain Reads sat as a co-equal third card on the docs homepage and as a third H2 in the Integration overview, which put a developer primitive next to the two things the credit protocol is actually selling. The homepage deck is now Offer Leverage and Provide Liquidity only, and the overview leads with those two and points at xChainRead, ERC-7683 and Docker dApps in one trailing line instead. The pages themselves are untouched and still in the sidebar. Co-Authored-By: Claude Opus 5 --- docs/integration/integration.md | 10 +++------- src/pages/index.tsx | 7 +------ 2 files changed, 4 insertions(+), 13 deletions(-) diff --git a/docs/integration/integration.md b/docs/integration/integration.md index 98bba1174..cde7e005e 100644 --- a/docs/integration/integration.md +++ b/docs/integration/integration.md @@ -6,7 +6,7 @@ sidebar_position: 1 # Integration Overview -There are three ways to build with t1, depending on what you bring to it. +There are two ways to build with t1, depending on what you bring to it. ## Offer leverage to your users @@ -20,10 +20,6 @@ You have capital and want it earning on undercollateralized loans without counte → [Provide Lending Liquidity](./lending.md) -## Use the underlying primitives - -The credit protocol is built on primitives t1 exposes directly, and they are useful on their own: +--- -- **[xChainRead](./xChainRead/overview.md)** — call a view function on another chain and verify the result in your contract. This is how positions held on separate venues resolve into one margin account, and it works for anything else that needs proven cross-chain state. -- **[ERC-7683](./7683/solver-integration.md)** — t1's intent protocol, where real-time proof of a fill lets solvers be repaid in under ten seconds instead of waiting out a challenge window. -- **[Docker dApps](./docker/overview.md)** — run your own Docker-packaged code inside t1's TEE, co-located with `t1-core`, with access to TEE-controlled multi-chain identities. +t1 also exposes the primitives the credit protocol is built on — [xChainRead](./xChainRead/overview.md), [ERC-7683](./7683/solver-integration.md), and [Docker dApps](./docker/overview.md) — for developers integrating them directly. They are in the sidebar. diff --git a/src/pages/index.tsx b/src/pages/index.tsx index acf1434eb..fd2c70662 100644 --- a/src/pages/index.tsx +++ b/src/pages/index.tsx @@ -71,11 +71,6 @@ export const integrationGuides = [ text: 'Deposit into a lending pool, or set one up with your own venues, position limits, and liquidation threshold. Repayment is enforced by the account, not promised by the borrower.', to: '/integration/lending', }, - { - title: 'Cross-Chain Reads', - text: "Request data to be read from other chains and proven by t1 back to your chain. You'll then be able to use the result in your contract. This primitive is useful in ERC-7683-enabled cross-chain intents, among others.", - to: '/integration/xChainRead/overview', - }, ] const Container = styled.div` @@ -372,7 +367,7 @@ export default function Home() { {/* Smart Contracts Section */}
Integrate with t1
-

Three ways to build on the credit protocol

+

Two ways to build on the credit protocol

Date: Wed, 23 Sep 2026 10:26:09 +0200 Subject: [PATCH 4/5] docs: frame the full TEE architecture as the long-term design The previous commit removed the claim that the two shipped apps run on TEE-held margin accounts, which left the mechanism pages silent about how far the architecture is actually deployed. Rather than asserting a negative, this states the direction the way amplifi's terms of service already do: controlling keys are migrating into TEEs and in certain environments are already held that way, with the full TEE architecture across every environment as the long-term design. A Rollout section at the bottom of programmable-custody.md carries it, linking the terms as the authoritative account of where the migration stands. The risk engine's verifiability section and the ecosystem page point at it. Co-Authored-By: Claude Opus 5 --- docs/intro/ecosystem.md | 2 ++ docs/intro/protocol/programmable-custody.md | 4 ++++ docs/intro/protocol/risk-engine.md | 2 +- 3 files changed, 7 insertions(+), 1 deletion(-) diff --git a/docs/intro/ecosystem.md b/docs/intro/ecosystem.md index bb116199c..09c5c91f1 100644 --- a/docs/intro/ecosystem.md +++ b/docs/intro/ecosystem.md @@ -21,3 +21,5 @@ t1's credit infrastructure already powers two applications. They differ in the v ## Building on t1 The same infrastructure is available to other venues and applications. If you operate a venue and want your users to trade with borrowed capital you never hold, see [Offer Leverage on Your Venue](../integration/leverage.md). If you want to put capital behind a policy, see [Provide Lending Liquidity](../integration/lending.md). + +Both applications are moving onto the full architecture described in [Programmable Custody](./protocol/programmable-custody.md); [Rollout](./protocol/programmable-custody.md#rollout) covers where that stands. diff --git a/docs/intro/protocol/programmable-custody.md b/docs/intro/protocol/programmable-custody.md index bf67fad60..934ac9da9 100644 --- a/docs/intro/protocol/programmable-custody.md +++ b/docs/intro/protocol/programmable-custody.md @@ -51,3 +51,7 @@ A key does not have this limitation. It sits in front of the transaction rather - **No withdrawal rights.** The borrower cannot move the capital to an address they control: there is no transaction they can submit, and no request they can make, that produces that signature. Profit realized inside the account is theirs, and is released to them through the policy's own settlement path once the loan and its interest are covered. The principal is never at their disposal. + +## Rollout + +Programmable custody is being adopted progressively rather than all at once. Controlling keys are being migrated into Trusted Execution Environments, and in certain environments are already held that way; the full TEE architecture described above, across every environment, is the long-term design. For the applications live on t1 today, amplifi's [terms of service](https://amplifi.finance/terms) set out where that migration currently stands. diff --git a/docs/intro/protocol/risk-engine.md b/docs/intro/protocol/risk-engine.md index 5dca50bb7..ef2da6a17 100644 --- a/docs/intro/protocol/risk-engine.md +++ b/docs/intro/protocol/risk-engine.md @@ -32,7 +32,7 @@ The borrower cannot block step 3, because the borrower was never the party holdi Liquidations are attested in real time, so a lender does not learn about a close after the fact from a report: the attestation is evidence that a specific, identified binary produced that decision from that state. That is what makes the engine checkable without the lender having to trust an operator's account of it. -Combined with [Real-Time Proving](./rtp.md) on the cross-chain reads the engine consumes, that closes the loop from market state to liquidation decision to repayment, with no step where a lender is asked to take somebody's word for it. +Combined with [Real-Time Proving](./rtp.md) on the cross-chain reads the engine consumes, that closes the loop from market state to liquidation decision to repayment, with no step where a lender is asked to take somebody's word for it. See [Rollout](./programmable-custody.md#rollout) for how far this is deployed today. ## Residual risk From a98db96c3b388d53cd063e55e96ed5e68e6eaa34 Mon Sep 17 00:00:00 2001 From: Orest Tarasiuk <830847+OrestTa@users.noreply.github.com> Date: Wed, 23 Sep 2026 10:58:59 +0200 Subject: [PATCH 5/5] docs: state the TEE rollout at subsystem level The Rollout note described the migration in terms of controlling keys and environments, which is how amplifi's terms of service put it. The actual status quo is broader: some subsystems already run inside a TEE and others are in the process of being moved into one. Says that instead, and points the TEE page at the same note, since it lists four uses in the present tense. Co-Authored-By: Claude Opus 5 --- docs/intro/protocol/programmable-custody.md | 2 +- docs/intro/protocol/tee.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/intro/protocol/programmable-custody.md b/docs/intro/protocol/programmable-custody.md index 934ac9da9..99c959d48 100644 --- a/docs/intro/protocol/programmable-custody.md +++ b/docs/intro/protocol/programmable-custody.md @@ -54,4 +54,4 @@ Profit realized inside the account is theirs, and is released to them through th ## Rollout -Programmable custody is being adopted progressively rather than all at once. Controlling keys are being migrated into Trusted Execution Environments, and in certain environments are already held that way; the full TEE architecture described above, across every environment, is the long-term design. For the applications live on t1 today, amplifi's [terms of service](https://amplifi.finance/terms) set out where that migration currently stands. +Programmable custody is being adopted progressively rather than all at once. Some subsystems already run inside a Trusted Execution Environment, and others are in the process of being moved into one. The full TEE architecture described above is the long-term design. For the applications live on t1 today, amplifi's [terms of service](https://amplifi.finance/terms) set out where that migration currently stands. diff --git a/docs/intro/protocol/tee.md b/docs/intro/protocol/tee.md index 087f0e7b9..3cb0e3874 100644 --- a/docs/intro/protocol/tee.md +++ b/docs/intro/protocol/tee.md @@ -15,7 +15,7 @@ t1 uses them to make undercollateralized credit possible, and to make the collat - **Read other chains reliably.** t1 runs full nodes for supported chains inside its node infrastructure, so an account's exposure is computed from state that was actually read rather than reported. - **Prove execution in real time.** State transitions are proven to Ethereum and supported rollups within a single block. See [Real-Time Proving](./rtp.md). -Remote attestation is what ties these together for a lender. It proves which binary is holding the key and running the risk engine, so "the policy is enforced" is a claim about a specific binary with a verifiable measurement, not a claim about t1's good behavior. +Remote attestation is what ties these together for a lender. It proves which binary is holding the key and running the risk engine, so "the policy is enforced" is a claim about a specific binary with a verifiable measurement, not a claim about t1's good behavior. Some subsystems already run this way and others are being moved; see [Rollout](./programmable-custody.md#rollout). ## Real-time settlement