From fdd099351bcc8ed8e49ce49896f2d3b9a8b16f29 Mon Sep 17 00:00:00 2001 From: Can Kisagun Date: Sun, 11 Jan 2026 11:57:15 -0800 Subject: [PATCH] Update overview.md a few small changes. See my comments here as well https://www.notion.so/t1protocol/Docs-about-t1-permissionless-docker-composability-2e1231194dc38000be55f82a62b91f39?source=copy_link#2e5231194dc380689b36cf77b295be3c Signed-off-by: Can Kisagun --- docs/integration/docker/overview.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/integration/docker/overview.md b/docs/integration/docker/overview.md index 6bd8141a..f1e24663 100644 --- a/docs/integration/docker/overview.md +++ b/docs/integration/docker/overview.md @@ -6,21 +6,21 @@ sidebar_position: 1 # Docker dApps Overview -t1 lets developers run their own Docker-packaged code as a dApp and benefit from t1's secured TEE architecture as well as its dedicated cross-chain capabilities. +**t1 lets developers run their own Docker-packaged code as a dApp and benefit from t1's secured TEE architecture as well as its dedicated cross-chain capabilities.** _Warning: This is an early feature which is under heavy development and should not be used in production._ -Moreover, natively sharing liquidity and composing between such dApps will be possible soon. In the future, we'll also enable keeping the dApp logic (incl. source code) private-yet-verifiable, via a remotely-attested open-source enforcer. +Moreover, natively sharing liquidity and composing between such dApps will be possible soon. In the future, t1 will also enable private execution by keeping the dApp logic (incl. source code) private-yet-verifiable, via a remotely-attested open-source enforcer. ## How t1 Supports Docker -A t1 TEE node is always running a `t1-core` Docker image which exposes dedicated endpoints for cross-chain interactions. +t1 TEE node runs a `t1-core` Docker image which exposes dedicated endpoints for cross-chain interactions. -A third-party developer is able to have t1 pull a `t1-dapp` Docker image prepared by them and run it within the same TEE. +Third-party developers are able to have t1 pull a `t1-dapp` Docker image prepared by them and run it within the same TEE. -Therefore, such third-party dApp becomes co-located with `t1-core` and allowed to call its predefined methods via regular Docker-to-Docker communication between co-located containers. +Therefore, such third-party dApps become co-located with `t1-core` and are allowed to call `t1-core`'s predefined methods via regular Docker-to-Docker communication between co-located containers. -Moreover, a `t1-dapp` is allowed to issue conventional web2-style API calls, e.g. to fetch CEX price feeds etc. However, in order to benefit from t1's secured TEE architecture, it is the responsibility of the dApp developer to ensure that their logic yields a deterministic output—only then can it be verified via re-execution. +Moreover, `t1-dapp`s are allowed to issue conventional web2-style API calls, e.g. to fetch CEX price feeds etc. However, in order to benefit from t1's secured TEE architecture, it is the responsibility of the dApp developer to ensure that the application logic yields a deterministic output—only then can it be verified via re-execution. proprietary code - no ra - controller pattern